1. מדוע ל-BGP אין אימות מקור מקורי
BGP תוכנן עבור אינטרנט שיתופי שבו כל המשתתפים נתנו אמון. נתב מקבל הודעת UPDATE ומפיץ אותה ללא אימות קריפטוגרפי ש-AS המקור אכן מורשה להכריז על קידומות IP אלה. המשמעות היא שכל AS - באמצעות תצורה שגויה או זדון - יכול להכריז על קידומות של מישהו אחר, וההודעה הזו עשויה להתפשט ברחבי העולם תוך דקות.
אירועים בולטים שהאיצו את אימוץ RPKI:
- 2008 - פקיסטן טלקום:PTCL הכריזה בטעות על קידומת ספציפית יותר למרחב הכתובות של YouTube (208.65.153.0/24), והרסה את YouTube ברחבי העולם במשך כ-2 שעות לפני שספקי הרשת הסירו את המסלול.
- 2010 - צ'יינה טלקום:China Telecom יצרה ~50,000 קידומות השייכות לרשתות הצבא, הממשל והמסחר של ארה"ב במשך ~18 דקות. מעולם לא אושרה בשוגג או בכוונה.
- 2018 - חטיפת DNS של Amazon Route 53:תוקף השתמש ב-BGP כדי לחטוף את 205.251.196.0/24 (Amazon DNS), והפנה מחדש את תעבורת ארנק מטבעות קריפטוגרפיים כדי לגנוב כספים. המתקפה השתמשה ב-BGP UPDATE מ-eNet (AS10297).
- 2019 - התעבורה האירופית מנותבת מחדש דרך China Telecom:תעבורת סלולר אירופית (כולל Vodafone ו- Swisscom השוויצרית) נותבה מחדש דרך China Telecom למשך כשעתיים עקב דליפת נתיב BGP.
2. היררכיית אמון RPKI
RPKI (RFC 6480) בונה היררכיה של אישורי X.509 המשקפת את אופן האצלה של שטח כתובות IP:
- IANAמחזיק בעוגן אמון השורש. היא מנפיקה אישורי משאבים לחמשת ה-RIR (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), כל אחד מכסה את מרחב הכתובות שלו.
- RIRsלהנפיק אישורים לחבריהם (ספקי שירותי אינטרנט, ארגונים) עבור שטח הכתובות שאותם חברים מחזיקים.
- חבריםלהנפיק אישורי ישות קצה (EE) ולחתוםהרשאות מוצא מסלול(ROA) - אישורים חתומים המאשרים ל-ASN ספציפי ליצור קידומות ספציפיות.
המאמתים מורידים את היררכיית האובייקטים החתומים הזו מחמישה מאגרי RIR (בתוספת כל מאגרים מואצלים), מאמתים את שרשרת האישורים ובונים טבלת מטען ROA מאומתת (VRP). לאחר מכן נתבים מבצעים שאילתה למטמון RPKI מקומי באמצעות הפרוטוקול RTR (RFC 8210) כדי לקבל טבלה זו ולבצע אימות מקור בעדכוני BGP נכנסים.
3. הרשאות מוצא (ROA)
ROA (RFC 6482) הוא אובייקט חתום המכיל שלושה שדות:
- ASN: המערכת האוטונומית המוסמכת ליצור את הקידומת.
- קידומת: קידומת ה-IP (IPv4 או IPv6) מאושרת.
- maxLength: אורך הקידומת המקסימלי שה-ASN מורשה להכריז. אם לא צוין, רק הקידומת המדויקת מורשית. אם מוגדר, נניח, 24 עבור קידומת /20, ה-ASN עשוי גם להכריז על כל ספציפי יותר בין /20 ל- /24.
ROA יחיד יכול לאשר קידומות מרובות עבור אותו ASN, אך ROA אחד לא יכול לאשר מספר ASNs עבור קידומת אחת. כדי לאפשר ל-ASN משני (למשל, ספק תחבורה ציבורית או CDN) ליצור את הקידומת שלך, צור ROA נפרד עבור אותו ASN.
4. מדינות אימות
כאשר נתב מקבל עדכון BGP, הוא מבצע אימות מקור (RFC 6811) כנגד טבלת ה-VRP המקומית שלו:
| מְדִינָה | מַצָב | טיפול אופייני להעדפה מקומית |
|---|---|---|
| תָקֵף | לפחות ROA אחד מכסה את הקידומת (קידומת ⊆ קידומת ROA AND prefix-length ≤ maxLength) וה-ASN של ה-ROA תואם למקור ASN של BGP UPDATE | +20 או מועדף (נפוץ) |
| לֹא בְּתוֹקֶף | לפחות ROA אחד מכסה את הקידומת, אך לאף ROA מכסה אין ASN תואם ו-maxLength ≥ אורך הקידומת המוכרז | הגדר מקומי העדפה 0 או שחרור (בחירת מפעיל; RFC 6811 ממליץ לאפשר אך לסמן) |
| לא נמצא | לא קיים ROA שמכסה את הקידומת שהוכרזה | ללא שינוי (טופל כמו לפני קיים RPKI) |
התובנה המרכזית:לֹא בְּתוֹקֶףמהווה עדות חזקה יותר לבעיה מאשרלא נמצא. NotFound פשוט אומר שבעל הקידומת עדיין לא יצר ROA. לא חוקי פירושו שקיים ROA שאומר שה-ASN הזה הואלֹאמורשה - אות חזק של תצורה שגויה או חטיפה.
5. פרוטוקול RTR
נתבים אינם מאמתים בעצמם שרשראות תעודות X.509 - זה יהיה יקר מבחינה חישובית ודורש שמירת מטמון RPKI מלא. במקום זאת, ייעודימאמת RPKI(Routinator, OctoRPKI, Fort, rpki-client) מוריד ומאמת את מאגר ה-RPKI המלא ומייצא רק את עומסי ה-ROA המאומתים (VRPs) המתקבלים לנתבים באמצעות פרוטוקול RTR (RFC 8210).
RTR משתמש ב-TCP (יציאה 323 שהוקצה ל-IANA; מאמתים כגון Routinator כברירת מחדל ליציאה 3323 כדי להימנע מדרישת הרשאות שורש) עם מנגנון סנכרון מצטבר: האימות שולח מספרים סידוריים, ונתבים מבקשים רק את הדלתא מאז הסנכרון האחרון שלהם. זה שומר על רוחב פס נמוך אפילו עבור טבלאות VRP גדולות (כרגע ~400,000+ כניסות IPv4 ברחבי העולם).
6. פריסה וסטטיסטיקה
החל מתחילת 2026, פריסת RPKI הגיעה להיקף משמעותי:
- ליותר מ-50% מקידומות IPv4 המנותבות ברחבי העולם יש לפחות ROA אחת המכסה (עלייה מ-10% בערך ב-2019).
- רוב ספקי שירותי האינטרנט Tier-1 ו-Tier-2 מבצעים כעת אימות מקור מסלול ומבטלים או מבטלים סדר עדיפויות של מסלולים לא חוקיים.
- MANRS (נורמות מוסכמות הדדית לאבטחת ניתוב) דורשת יצירת RPKI ROA כתנאי מוקדם לחברות ומפרסמת לוח מחוונים של התאמה ל-AS.
סטטיסטיקה חיה:צג NIST RPKI, ROV++, סטטיסטיקות APNIC RPKI.
7. מעבר ל-ROV: ASPA ו-BGPsec
אימות מקור RPKI נתיב מוודא רק שה-מקור ASNמוסמך להכריז על הקידומת. זה לא מאמת את ה-AS_PATH - תוקף עדיין יכול לבנות AS_PATH שקרי עם מקור AS לגיטימי בסוף. שני תקני IETF מתייחסים לכך:
- BGPsec (RFC 8205): כל AS בנתיב חותם באופן קריפטוגרפי על UPDATE, ויוצר שרשרת משמורת בלתי ניתנת לשבירה. מחייב את כל ה-Transit ASes לתמוך ב-BGPsec - מחסום פריסה משמעותי. נפרס לעתים רחוקות נכון לשנת 2026.
- ASPA(הרשאת ספק מערכת אוטונומית,טיוטה-ietf-sidrops-aspa-profile): AS חותם על אובייקט המפרט את הספקים המורשים שלו במעלה הזרם. מאמתים יכולים לזהות נתיבים לא חוקיים ללא עמק (למשל, לקוח שמודיע על מסלולים כאילו היה ספק). פשוט יותר לפריסה מאשר BGPsec וצובר אחיזה החל מ-2025-2026.
הפניות
- RFC 6480- תשתית לתמיכה בניתוב אינטרנט מאובטח (סקירת RPKI)
- RFC 6482- פרופיל להרשאות מוצא (ROA)
- RFC 6811— אימות מקור קידומת BGP
- RFC 8210- פרוטוקול RPKI לנתב, גרסה 1 (RTR)
- RFC 8416- ניהול משאבי מספר אינטרנט מקומי פשוט עם ה-RPKI (SLURM - עקיפות מקומיות)
- RFC 9286- מניפסטים עבור תשתית המפתח הציבורי של משאבים (RPKI)
- RFC 8205— מפרט פרוטוקול BGPsec
- MANRS- נורמות מוסכמות הדדית לניתוב אבטחה
- פורטל Cloudflare RPKI- חיפוש ROA חי