.. τίτλος: RPKI και BGP Route Origin Validation
.. γυμνοσάλιαγκας: rpki-bgp-route-origin-validation
.. ημερομηνία: 2026-04-07 12:00:00 UTC
.. ετικέτες: rpki, bgp, ασφάλεια, δρομολόγηση, πειρατεία διαδρομής, roa
.. κατηγορία: Άρθρα
.. σύνδεσμος:
.. περιγραφή: Πώς το RPKI και η επικύρωση προέλευσης διαδρομής προστατεύουν το BGP από παραβιάσεις και διαρροές διαδρομής — καλύπτοντας ROA, καταστάσεις επικύρωσης, το πρωτόκολλο RTR και στατιστικά ανάπτυξης.
.. τύπος: κείμενο
<style>
.calc-container { max-width: 860px; margin: 20px auto; padding: 20px; }
.calc-header { margin-bottom: 30px; padding: 25px; background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); border-radius: 12px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); color: white; }
.calc-header h2 { margin-top: 0; color: white; font-size: 28px; margin-bottom: 10px; }
.calc-header p  { margin: 10px 0; opacity: 0.95; font-size: 15px; }
.result-section { background: white; border: 1px solid #e0e0e0; border-radius: 8px; margin-top: 20px; overflow: hidden; box-shadow: 0 2px 4px rgba(0,0,0,0.05); }
.section-content { padding: 20px; background: #fafafa; }
@media (max-width: 768px) { .calc-header h2 { font-size: 22px; } .calc-container { padding: 10px; } }
.article-body { padding: 24px; background: white; line-height: 1.8; font-size: 15px; color: #333; }
.article-body h3 { color: #2d6a2d; border-bottom: 2px solid #4CAF50; padding-bottom: 6px; }
.article-body a { color: #2d6a2d; }
.article-body a:hover { color: #4CAF50; }
.callout { background: #e8f5e9; border-left: 4px solid #4CAF50; padding: 12px 16px; border-radius: 6px; margin: 16px 0; font-size: 14px; }
.callout.warn { background: #fff8e0; border-color: #f0a500; }
pre, .code-block { background: #1e1e2e; color: #cdd6f4; padding: 14px 18px; border-radius: 8px; font-family: 'Courier New', monospace; font-size: 13px; overflow-x: auto; line-height: 1.5; margin: 12px 0; white-space: pre; }
table { width: 100%; border-collapse: collapse; margin: 16px 0; font-size: 14px; }
th { background: #2d6a2d; color: white; padding: 10px 12px; text-align: left; }
td { padding: 8px 12px; border-bottom: 1px solid #e0e0e0; vertical-align: top; }
tr:nth-child(even) td { background: #f5f5f5; }
.state-valid   { color: #276227; font-weight: 600; }
.state-invalid { color: #b91c1c; font-weight: 600; }
.state-unknown { color: #92400e; font-weight: 600; }
</style>
<div class="calc-container">
<div class="calc-header">
<h2>Επικύρωση προέλευσης διαδρομής RPKI και BGP</h2>
<p>Πώς η Υποδομή Δημόσιου Κλειδιού Πόρων αποτρέπει τις παραβιάσεις διαδρομής — καλύπτοντας την αλυσίδα αξιοπιστίας ROA, τις καταστάσεις επικύρωσης, το πρωτόκολλο RTR και τη θέση της ανάπτυξης σήμερα.</p>
</div>
<div class="result-section">
<div class="section-content article-body">
<h3 id="problem">1. Γιατί το BGP δεν έχει επικύρωση εγγενούς προέλευσης</h3>
<p>Το BGP σχεδιάστηκε για ένα συνεργατικό Διαδίκτυο όπου όλοι οι συμμετέχοντες είχαν εμπιστοσύνη. Ένας δρομολογητής δέχεται ένα μήνυμα UPDATE και το διαδίδει χωρίς κρυπτογραφική επαλήθευση ότι το αρχικό AS είναι πράγματι εξουσιοδοτημένο να ανακοινώνει αυτά τα προθέματα IP. Αυτό σημαίνει ότι κάθε AS — μέσω εσφαλμένης διαμόρφωσης ή κακόβουλης λειτουργίας — μπορεί να ανακοινώσει τα προθέματα κάποιου άλλου και αυτή η ανακοίνωση μπορεί να διαδοθεί παγκοσμίως μέσα σε λίγα λεπτά.</p>
<p>Αξιοσημείωτα περιστατικά που επιτάχυναν την υιοθέτηση του RPKI:</p>
<ul>
<li><strong>2008 — Pakistan Telecom:</strong>Η PTCL ανακοίνωσε κατά λάθος ένα πιο συγκεκριμένο πρόθεμα για τον χώρο διευθύνσεων του YouTube (208.65.153.0/24), κάνοντας blackholing το YouTube παγκοσμίως για ~2 ώρες προτού οι πάροχοι ανάντη αποσύρουν τη διαδρομή.</li>
<li><strong>2010 — China Telecom:</strong>Η China Telecom δημιούργησε περίπου 50.000 προθέματα που ανήκαν σε στρατιωτικά, κυβερνητικά και εμπορικά δίκτυα των ΗΠΑ για ~18 λεπτά. Το αν ήταν τυχαίο ή εσκεμμένο δεν επιβεβαιώθηκε ποτέ.</li>
<li><strong>2018 — Παραβίαση DNS Amazon Route 53:</strong>Ένας εισβολέας χρησιμοποίησε το BGP για να κλέψει το 205.251.196.0/24 (Amazon DNS), ανακατευθύνοντας την κίνηση πορτοφολιού κρυπτονομισμάτων για να κλέψει χρήματα. Η επίθεση χρησιμοποίησε μια ΕΝΗΜΕΡΩΣΗ BGP από την eNet (AS10297).</li>
<li><strong>2019 — Η ευρωπαϊκή κυκλοφορία αναδρομολογήθηκε μέσω της China Telecom:</strong>Η ευρωπαϊκή κίνηση κινητής τηλεφωνίας (συμπεριλαμβανομένης της Vodafone και της Swisscom της Ελβετίας) επαναδρομολογήθηκε μέσω της China Telecom για περίπου 2 ώρες λόγω διαρροής διαδρομής BGP.</li>
</ul>
<h3 id="rpki-trust">2. Η RPKI Trust Hierarchy</h3>
<p>RPKI (<a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>) δημιουργεί μια ιεραρχία πιστοποιητικών X.509 που αντικατοπτρίζει τον τρόπο ανάθεσης του χώρου διευθύνσεων IP:</p>
<ol>
<li><strong>ΙΑΝΑ</strong>κρατά την άγκυρα εμπιστοσύνης ρίζας. Εκδίδει πιστοποιητικά πόρων στα πέντε RIR (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), το καθένα καλύπτοντας το χώρο διευθύνσεών του.</li>
<li><strong>RIR</strong>εκδίδουν πιστοποιητικά στα μέλη τους (ISP, επιχειρήσεις) για τον χώρο διευθύνσεων που διαθέτουν αυτά τα μέλη.</li>
<li><strong>Μέλη</strong>έκδοση πιστοποιητικών τελικής οντότητας (EE) και υπογραφή<em>Εξουσιοδοτήσεις προέλευσης διαδρομής</em>(ROAs) — υπογεγραμμένες βεβαιώσεις που εξουσιοδοτούν ένα συγκεκριμένο ASN να δημιουργεί συγκεκριμένα προθέματα.</li>
</ol>
<p>Οι επαληθευτές πραγματοποιούν λήψη αυτής της ιεραρχίας υπογεγραμμένων αντικειμένων από πέντε αποθετήρια RIR (συν τυχόν εκχωρημένους χώρους αποθήκευσης), επικυρώνουν την αλυσίδα πιστοποιητικών και δημιουργούν έναν επικυρωμένο πίνακα ωφέλιμου φορτίου ROA (VRP). Στη συνέχεια, οι δρομολογητές ρωτούν μια τοπική κρυφή μνήμη RPKI μέσω του<em>Πρωτόκολλο RTR</em> (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>) για να λάβετε αυτόν τον πίνακα και να εκτελέσετε επικύρωση προέλευσης στις εισερχόμενες ΕΝΗΜΕΡΩΣΕΙΣ BGP.</p>
<h3 id="roa">3. Εξουσιοδοτήσεις προέλευσης διαδρομής (ROA)</h3>
<p>Α ROA (<a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>) είναι ένα υπογεγραμμένο αντικείμενο που περιέχει τρία πεδία:</p>
<ul>
<li><strong>ASN</strong>: Το Αυτόνομο Σύστημα εξουσιοδοτημένο να δημιουργεί το πρόθεμα.</li>
<li><strong>Πρόθεμα</strong>: Το πρόθεμα IP (IPv4 ή IPv6) είναι εξουσιοδοτημένο.</li>
<li><strong>μέγιστο μήκος</strong>: Το μέγιστο μήκος προθέματος που είναι εξουσιοδοτημένο να ανακοινώνει το ASN. Εάν δεν προσδιορίζεται, επιτρέπεται μόνο το ακριβές πρόθεμα. Εάν οριστεί σε, ας πούμε, 24 για ένα πρόθεμα /20, το ASN μπορεί επίσης να ανακοινώσει οποιοδήποτε πιο συγκεκριμένο μεταξύ /20 και /24.</li>
</ul>
<div class="callout warn">
<strong>Το maxLength είναι ένα κοινό διάνυσμα εσφαλμένης διαμόρφωσης.</strong>Η ρύθμιση maxLength = 32 (IPv4) ή maxLength = 128 (IPv6) σε ένα ROA επιτρέπει στο ASN να ανακοινώνει οποιοδήποτε πιο συγκεκριμένο υποδίκτυο, συμπεριλαμβανομένων των διαδρομών κεντρικού υπολογιστή /32 που θα μπορούσαν να χρησιμοποιηθούν σε μια πειρατεία. Βέλτιστη πρακτική: ορίστε το maxLength στο μεγαλύτερο πρόθεμα που πραγματικά ανακοινώνετε (συχνά το ίδιο με το μήκος του προθέματος).</div>
<p>Ένα μόνο ROA μπορεί να εξουσιοδοτήσει πολλά προθέματα για το ίδιο ASN, αλλά ένα ROA δεν μπορεί να εξουσιοδοτήσει πολλά ASN για ένα μόνο πρόθεμα. Για να επιτρέψετε σε ένα δευτερεύον ASN (π.χ. έναν πάροχο δημόσιας συγκοινωνίας ή CDN) να δημιουργήσει το πρόθεμά σας, δημιουργήστε ένα ξεχωριστό ROA για αυτό το ASN.</p>
<h3 id="validation-states">4. Κράτη επικύρωσης</h3>
<p>Όταν ένας δρομολογητής λαμβάνει μια ΕΝΗΜΕΡΩΣΗ BGP, εκτελεί επικύρωση προέλευσης (<a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>) σε σχέση με τον τοπικό πίνακα VRP:</p>
<table>
<tr><th>Κατάσταση</th><th>Κατάσταση</th><th>Τυπική θεραπεία τοπικής προτίμησης</th></tr>
<tr><td><span class="state-valid">Εγκυρος</span></td><td>Τουλάχιστον μία ROA καλύπτει το πρόθεμα (πρόθεμα ⊆ πρόθεμα ROA AND prefix-length ≤ maxLength) ΚΑΙ το ASN του ROA ταιριάζει με το ASN προέλευσης του BGP UPDATE</td><td>+20 ή προτιμώμενο (κοινό)</td></tr>
<tr><td><span class="state-invalid">Ακυρος</span></td><td>Τουλάχιστον μία ROA καλύπτει το πρόθεμα, αλλά καμία κάλυψη ROA δεν έχει αντίστοιχο ASN και μέγιστο μήκος ≥ το ανακοινωμένο μήκος προθέματος</td><td>Ρύθμιση τοπικής προτίμησης 0 ή πτώση (επιλογή χειριστή, RFC 6811 συνιστά να επιτρέπεται αλλά να επισημαίνεται)</td></tr>
<tr><td><span class="state-unknown">Δεν βρέθηκε</span></td><td>Δεν υπάρχει ROA που να καλύπτει το ανακοινωθέν πρόθεμα</td><td>Αμετάβλητο (μεταχείριση όπως πριν από την ύπαρξη του RPKI)</td></tr>
</table>
<p>Η βασική γνώση:<em>Ακυρος</em>είναι ισχυρότερη απόδειξη ενός προβλήματος από<em>Δεν βρέθηκε</em>. Το NotFound σημαίνει απλώς ότι ο κάτοχος του προθέματος δεν έχει δημιουργήσει ακόμη ROA. Μη έγκυρο σημαίνει ότι υπάρχει ROA λέγοντας ότι αυτό το ASN είναι<em>δεν</em>εξουσιοδοτημένο — ένα ισχυρό σήμα είτε εσφαλμένης διαμόρφωσης είτε αεροπειρατείας.</p>
<h3 id="rtr">5. Το Πρωτόκολλο RTR</h3>
<p>Οι δρομολογητές δεν επικυρώνουν οι ίδιοι τις αλυσίδες πιστοποιητικών X.509 — αυτό θα ήταν υπολογιστικά ακριβό και θα απαιτούσε τη διατήρηση μιας πλήρους κρυφής μνήμης RPKI. Αντίθετα, ένα αφιερωμένο<em>Επαληθευτής RPKI</em>(Routinator, OctoRPKI, Fort, rpki-client) κατεβάζει και επικυρώνει το πλήρες αποθετήριο RPKI και εξάγει μόνο τα επικυρωμένα ωφέλιμα φορτία ROA (VRPs) που προκύπτουν σε δρομολογητές μέσω του πρωτοκόλλου RTR (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>).</p>
<p>Το RTR χρησιμοποιεί το TCP (θύρα 323 που έχει εκχωρηθεί από το IANA· επικυρωτές όπως ο Routinator προεπιλογή στη θύρα 3323 για να αποφευχθεί η απαίτηση δικαιωμάτων ρίζας) με μηχανισμό αυξητικού συγχρονισμού: το πρόγραμμα επικύρωσης στέλνει σειριακούς αριθμούς και οι δρομολογητές ζητούν μόνο το δέλτα από τον τελευταίο συγχρονισμό τους. Αυτό διατηρεί το εύρος ζώνης χαμηλό ακόμη και για μεγάλους πίνακες VRP (επί του παρόντος ~400.000+ καταχωρήσεις IPv4 παγκοσμίως).</p>
<h3 id="deployment">6. Ανάπτυξη και στατιστικές</h3>
<p>Από τις αρχές του 2026, η ανάπτυξη του RPKI έχει φτάσει σε σημαντική κλίμακα:</p>
<ul>
<li>Πάνω από το 50% των προθεμάτων IPv4 που δρομολογούνται παγκοσμίως έχουν τουλάχιστον ένα που καλύπτει το ROA (από ~10% το 2019).</li>
<li>Η πλειονότητα των ISP Tier-1 και Tier-2 εκτελούν πλέον Επικύρωση προέλευσης διαδρομής και απορρίπτουν ή καταργούν τις μη έγκυρες διαδρομές.</li>
<li>Το MANRS (Αμοιβαία συμφωνημένα πρότυπα για την ασφάλεια δρομολόγησης) απαιτεί τη δημιουργία RPKI ROA ως προϋπόθεση για τη συμμετοχή και δημοσιεύει έναν πίνακα ελέγχου συμμόρφωσης ανά AS.</li>
</ul>
<p>Ζωντανά στατιστικά:<a href="https://rpki-monitor.antd.nist.gov/" target="_blank">Οθόνη NIST RPKI</a>, <a href="https://www.rov.rpki.net/" target="_blank">ROV++</a>, <a href="https://stats.labs.apnic.net/rpki" target="_blank">Στατιστικά APNIC RPKI</a>.</p>
<h3 id="beyond-rov">7. Πέρα από ROV: ASPA και BGPsec</h3>
<p>Το RPKI Route Origin Validation επαληθεύει μόνο ότι το<em>προέλευσης ASN</em>εξουσιοδοτείται να ανακοινώνει το πρόθεμα. Δεν επικυρώνει το AS_PATH — ένας εισβολέας μπορεί ακόμα να κατασκευάσει ένα ψευδές AS_PATH με νόμιμη προέλευση AS στο τέλος. Δύο πρότυπα IETF αντιμετωπίζουν αυτό:</p>
<ul>
<li><strong>BGPsec</strong> (<a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>): Κάθε AS στη διαδρομή υπογράφει κρυπτογραφικά την ΕΝΗΜΕΡΩΣΗ, δημιουργώντας μια άθραυστη αλυσίδα φύλαξης. Απαιτεί όλα τα AS διέλευσης να υποστηρίζουν το BGPsec — ένα σημαντικό εμπόδιο ανάπτυξης. Σπάνια αναπτύχθηκε από το 2026.</li>
<li><strong>ΑΣΠΑ</strong>(Αυτόνομη Εξουσιοδότηση Παρόχου Συστήματος,<a href="https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/" target="_blank">draft-ietf-sidrops-aspa-profile</a>): Ένα AS υπογράφει ένα αντικείμενο που περιλαμβάνει τους εξουσιοδοτημένους παρόχους του upstream. Οι επαληθευτές μπορούν να εντοπίσουν μη έγκυρες διαδρομές χωρίς κοιλάδες (π.χ. ένας πελάτης που ανακοινώνει διαδρομές σαν να ήταν πάροχος). Πιο απλό στην ανάπτυξη από το BGPsec και κερδίζοντας έλξη από το 2025–2026.</li>
</ul>
<h3 id="references">Αναφορές</h3>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>— Μια υποδομή για την υποστήριξη ασφαλούς δρομολόγησης στο Διαδίκτυο (επισκόπηση RPKI)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>— Προφίλ για εξουσιοδοτήσεις προέλευσης διαδρομής (ROA)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>— Επικύρωση προέλευσης προθέματος BGP</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>— Το πρωτόκολλο RPKI προς δρομολογητή, έκδοση 1 (RTR)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8416" target="_blank">RFC 8416</a>— Απλοποιημένη διαχείριση πόρων τοπικών αριθμών Διαδικτύου με το RPKI (SLURM — τοπικές παρακάμψεις)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc9286" target="_blank">RFC 9286</a>— Manifests for the Resource Public Key Infrastructure (RPKI)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>— Προδιαγραφή πρωτοκόλλου BGPsec</li>
<li><a href="https://www.manrs.org/" target="_blank">MANRS</a>— Αμοιβαία αποδεκτά πρότυπα για την ασφάλεια δρομολόγησης</li>
<li><a href="https://rpki.cloudflare.com/" target="_blank">Πύλη Cloudflare RPKI</a>— Ζωντανή αναζήτηση ROA</li>
</ul>
</div>
</div>
</div>