RPKI και ROA: τι πρέπει πραγματικά να κάνουν αγοραστές και μισθωτές

Γιατί αυτό έπαψε να είναι προαιρετικό

Για χρόνια το RPKI ήταν κάτι που οι φορείς δικτύων συμφωνούσαν ότι ήταν καλή ιδέα και δεν προλάβαιναν να εφαρμόσουν. Αυτό άλλαξε όταν τα μεγάλα δίκτυα άρχισαν πραγματικά να το επιβάλλουν. Μεγάλοι πάροχοι transit, οι μεγάλες πλατφόρμες cloud και αρκετά μεγάλα δίκτυα περιεχομένου εκτελούν πλέον Route Origin Validation και απορρίπτουν τις διαδρομές που επιστρέφουν invalid.

Η πρακτική συνέπεια είναι ωμή. Ένα prefix με χαλασμένο ROA δεν είναι απλώς απροστάτευτο, είναι απρόσιτο από ένα αυξανόμενο μέρος του διαδικτύου. Και η αποτυχία είναι μερική και συγκεχυμένη: ορισμένοι χρήστες σας φτάνουν, άλλοι όχι, και τα traceroutes φαίνονται εντάξει από όπου κι αν τύχει να κάνετε τη δοκιμή.

Αν αγοράζετε ή μισθώνετε χώρο διευθύνσεων, αυτή είναι η μία λεπτομέρεια ρύθμισης που είναι πιθανότερο να σας κοστίσει μια ημέρα.

Τι είναι στην πράξη ένα ROA

Το RPKI είναι ένα σύστημα κρυπτογραφικών βεβαιώσεων συνδεδεμένο με το μητρώο διευθύνσεων. Το αντικείμενο που μετρά στην καθημερινότητα είναι το Route Origin Authorization, ή ROA, και περιέχει ακριβώς τρία πράγματα:

• Το prefix. Για παράδειγμα 192.0.2.0/24.
• Το AS προέλευσης. Τον αριθμό αυτόνομου συστήματος που επιτρέπεται να το ανακοινώνει.
• Ένα μέγιστο μήκος. Το μακρύτερο prefix που μπορεί να ανακοινωθεί μέσα σε αυτό το μπλοκ.

Αυτό είναι όλο το αντικείμενο. Είναι μια υπογεγραμμένη δήλωση του κατόχου των διευθύνσεων που λέει «αυτό το AS επιτρέπεται να ανακοινώνει αυτόν τον χώρο ως προέλευση, έως αυτό το συγκεκριμένο μέγεθος». Οι routers δεν το διαβάζουν απευθείας. Οι validators ανακτούν και επαληθεύουν τα δεδομένα RPKI και τροφοδοτούν το αποτέλεσμα στους routers, οι οποίοι στη συνέχεια κατατάσσουν κάθε διαδρομή ως valid, invalid ή not-found.

Κάθε διαδρομή καταλήγει σε μία από τρεις καταστάσεις. Valid: ένα ROA καλύπτει το prefix και η ανακοίνωση αντιστοιχεί σε αυτό. NotFound, που πολλά εργαλεία εμφανίζουν ως Unknown: κανένα ROA δεν καλύπτει το prefix. Invalid: ένα ROA καλύπτει το prefix, αλλά η ανακοίνωση έρχεται σε αντίθεση με αυτό, είτε από λάθος AS είτε με prefix μακρύτερο από όσο επιτρέπει το μέγιστο μήκος.

Η σειρά αυτών των καταστάσεων μετρά περισσότερο απ' ό,τι περιμένουν οι περισσότεροι. Μια διαδρομή χωρίς ROA γίνεται ακόμη δεκτή σχεδόν παντού: είναι απροστάτευτη, αλλά περνά. Μια διαδρομή που επιστρέφει Invalid απορρίπτεται από κάθε δίκτυο που επιβάλλει επικύρωση. Κανένα ROA είναι καλύτερο από ένα λάθος ROA. Ο στόχος είναι ένα σωστό, αλλά αν οι λεπτομέρειες δεν έχουν οριστικοποιηθεί την ημέρα που ανακοινώνετε, η ανακοίνωση χωρίς ROA και η προσθήκη του μόλις οριστικοποιηθούν είναι πολύ ασφαλέστερη από τη δημοσίευση ενός ROA που αντιφάσκει με όσα στέλνετε.

Ποιος το δημιουργεί εξαρτάται από το πώς αποκτήσατε τον χώρο

Αυτό μπερδεύει συνεχώς, οπότε αξίζει να το πούμε ρητά.

Αν αγοράσατε το μπλοκ, είναι καταχωρισμένο σε εσάς και δημιουργείτε μόνοι σας το ROA στην πύλη του μητρώου σας, ή ζητάτε από τον χορηγό LIR σας να το δημιουργήσει αν διατηρεί αυτός τη σχέση με το μητρώο για λογαριασμό σας. Κάντε το μετά την ολοκλήρωση της μεταβίβασης, όχι πριν, επειδή το αντικείμενο πρέπει να δημιουργηθεί υπό τον νέο κάτοχο. Ο αγορασμένος χώρος legacy στην περιοχή του RIPE NCC χρειάζεται σύμβαση με το RIPE NCC ή με χορηγό LIR πριν μπορέσει να έχει ROA (το RIPE NCC).

Αν μισθώνετε, το μπλοκ δεν είναι καταχωρισμένο σε εσάς και δεν μπορείτε να δημιουργήσετε το ROA. Το κάνει ο κάτοχος, για το ASN σας. Αυτό σημαίνει ότι πρέπει να του πείτε δύο πράγματα από την αρχή: το ASN από το οποίο θα ανακοινώνετε, και αν σκοπεύετε να ανακοινώνετε κάτι πιο συγκεκριμένο από ολόκληρο το μπλοκ. Μια μίσθωση όπου το ROA δεν έχει δημιουργηθεί για το ASN σας θα επικυρωθεί ως invalid τη στιγμή που θα την ανακοινώσετε.

Αν ανακοινώνετε μέσω παρόχου cloud με BYOIP, το ROA συνήθως πρέπει να αναφέρει το ASN του παρόχου και όχι το δικό σας, επειδή το δίκτυό του είναι η προέλευση της διαδρομής: AS16509 και AS14618 στο AWS, AS8075 στο Azure, AS396982 στο Google Cloud στο Premium tier του. Ορισμένοι πάροχοι σας επιτρέπουν να ανακοινώνετε με το δικό σας ASN ως προέλευση, είτε μέσω δικής σας συνεδρίας BGP (Vultr, Cherry Servers) είτε ως επιλογή «bring your own ASN» πάνω από το BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Τότε ένα ROA αναφέρει το ASN σας, και το AWS και το Oracle Cloud θέλουν και ένα που αναφέρει το δικό τους. Οι περισσότεροι πάροχοι τεκμηριώνουν το ASN που πρέπει να αναφέρει το ROA, και λίγοι, μεταξύ αυτών η Gcore, το δίνουν μόνο όταν το ζητήσετε, οπότε ελέγξτε πριν δημιουργήσετε οτιδήποτε. Οι οδηγοί ανά πάροχο μας τα απαριθμούν.

Τα δύο λάθη που προκαλούν διακοπές

Σχεδόν κάθε πραγματική βλάβη RPKI καταλήγει στο μέγιστο μήκος.

Υπερβολικά ελαστική ρύθμιση. Ένα ROA για το 192.0.2.0/24 με μέγιστο μήκος /32 σημαίνει ότι κάθε ανακοίνωση οποιουδήποτε μεγέθους μέσα σε αυτό το μπλοκ επικυρώνεται. Αυτό ακυρώνει μεγάλο μέρος του σκοπού: ένας υποκλοπέας που ανακοινώνει μια πιο συγκεκριμένη διαδρομή από τον αριθμό AS σας επιστρέφει και πάλι valid, και οι πιο συγκεκριμένες διαδρομές κερδίζουν στο BGP. Η ασφαλής προεπιλογή είναι να ορίσετε το μέγιστο μήκος ίσο με το μήκος του prefix, εκτός αν έχετε συγκεκριμένο λόγο να μην το κάνετε.

Υπερβολικά αυστηρή ρύθμιση. Αν ανακοινώνετε ένα /24 που καλύπτεται από ROA, και αργότερα χρειαστεί να το διασπάσετε σε δύο /25 για traffic engineering, αυτά τα /25 γίνονται αμέσως invalid και εξαφανίζονται από μεγάλο μέρος του διαδικτύου. Αν σκοπεύετε να ανακοινώνετε πιο συγκεκριμένα prefixes, το ROA πρέπει να το επιτρέπει πριν ξεκινήσετε.

Ο κανόνας που αποτρέπει και τα δύο: κάντε το ROA να περιγράφει ακριβώς αυτό που πραγματικά ανακοινώνετε, και ενημερώστε το στο ίδιο παράθυρο αλλαγών με κάθε αλλαγή δρομολόγησης, όχι μετά.

ASPA: το επόμενο επίπεδο

Ένα ROA προστατεύει τον πρώτο κρίκο μιας διαδρομής: ποιος μπορεί να είναι η προέλευσή της. Δεν λέει τίποτα για τη διαδρομή μετά από αυτό, όπου συμβαίνουν οι διαρροές διαδρομών (route leaks), όταν ένα δίκτυο προωθεί διαδρομές που θα έπρεπε να είχε κρατήσει για τον εαυτό του. Το ASPA, Autonomous System Provider Authorization, καλύπτει μέρος αυτού του κενού.

Ένα αντικείμενο ASPA υπογράφεται από τον κάτοχο ενός αριθμού AS και απαριθμεί τα AS που είναι οι upstream πάροχοί του. Τα δίκτυα που το επικυρώνουν μπορούν να απορρίψουν μια διαδρομή στην οποία το AS σας φαίνεται να φτάνει στο διαδίκτυο μέσω κάποιου που δεν είναι πάροχός σας. Είναι ένα αναδυόμενο πρότυπο της IETF. Το RIPE NCC το περιγράφει ως έτοιμο για χρήση στην υπογραφή, και το ARIN και το APNIC επιτρέπουν επίσης στους κατόχους να υπογράφουν ASPA (σύγκριση των μητρώων).

• Αν έχετε δικό σας ASN, δημοσιεύστε ένα ASPA που απαριθμεί κάθε upstream που μεταφέρει τις διαδρομές σας στο διαδίκτυο. Αφήστε έξω τους peers και τους δικούς σας πελάτες.
• Κρατήστε το επίκαιρο. Ένας πάροχος που λείπει από το αντικείμενο μπορεί να οδηγήσει στην απόρριψη των διαδρομών σας μέσω αυτού του παρόχου από δίκτυα που επιβάλλουν ASPA, οπότε προσθέστε ένα νέο transit πριν το ενεργοποιήσετε και αφαιρέστε ένα παλιό αφού το απενεργοποιήσετε.
• Φέρνετε το δικό σας ASN σε ένα cloud; Το AWS συνιστά ένα ASPA που απαριθμεί τα AS16509 και AS14618 ως παρόχους του ASN σας. Χωρίς αυτά, οι διαδρομές που ανακοινώνει ξανά για εσάς αποτυγχάνουν στην επικύρωση ASPA.
• Μισθώνετε; Το ASPA ανήκει στο ASN σας, όχι στο prefix, οπότε τη δημοσίευσή του την κάνετε εσείς, όχι εμείς.

Η λίστα ελέγχου

Πριν ο χώρος μεταφέρει κίνηση παραγωγής:

• Υπάρχει ROA για το σωστό prefix και το σωστό AS προέλευσης.
• Το μέγιστο μήκος αντιστοιχεί στο πραγματικό σχέδιο ανακοινώσεών σας.
• Υπάρχουν επίσης route objects IRR. Το RPKI δεν τα έχει αντικαταστήσει. Πολλοί upstreams δημιουργούν ακόμη φίλτρα prefixes από δεδομένα IRR, οπότε ένα έγκυρο ROA χωρίς αντίστοιχο route object εξακολουθεί να σας φιλτράρει.
• Το ASPA απαριθμεί κάθε upstream, αν δημοσιεύετε ένα, και κανέναν peer ή πελάτη.
• Επικυρώστε εξωτερικά. Ελέγξτε από ένα εξωτερικό looking glass ή έναν RPKI validator, όχι από το δικό σας δίκτυο, που θα δεχτεί πρόθυμα τις δικές σας διαδρομές.
• Τακτοποιήστε φεύγοντας. Όταν λήγει μια μίσθωση ή σταματάτε να ανακοινώνετε ένα μπλοκ, το ROA πρέπει να αποσυρθεί ή να ενημερωθεί. Ένα παρωχημένο ROA που δείχνει σε ένα ASN που δεν ανακοινώνει πια τον χώρο είναι πρόβλημα για όποιον τον πάρει στη συνέχεια.

Πού ταιριάζει η RTM Networks

Δημιουργούμε και συντηρούμε τα ROA ως μέρος τόσο της μίσθωσης όσο και της χορηγίας, όχι ως πρόσθετο (μίσθωση IPv4, χορηγία PI και ASN). Για μίσθωση, πείτε μας το ASN από το οποίο θα ανακοινώνετε, ή τον πάροχο cloud στον οποίο φέρνετε τον χώρο, και αν χρειάζεστε πιο συγκεκριμένα prefixes, και το ROA ρυθμίζεται πριν από την παράδοση. Για πόρους με χορηγία, διαχειριζόμαστε τη ρύθμιση RPKI μαζί με τα άλλα αντικείμενα μητρώου.

Αν αναλαμβάνετε χώρο από αλλού, ποιος ρυθμίζει το RPKI εξαρτάται από τον δρόμο: ένας αγοραστής το κάνει για το ίδιο το μπλοκ, και σε μια μίσθωση το κάνει ο εκμισθωτής. Μπορούμε να ελέγξουμε αν υπάρχει ROA για το μπλοκ και, αν υπάρχει, αν είναι έγκυρο.