Bir Rota Köken Yetkilendirmesi, dijital olarak imzalanmış RPKI BGP'de bir IP ön ekini kökenlendirmesine izin verilen ASN'yi belirten kayıt. İlgili İnternet numara kaynağına sahip olan kuruluş tarafından veya onun adına oluşturulur. Bir ROA genellikle üç temel öğe içerir: IP ön eki, yetkili köken ASN'si ve ASN'nin duyurabileceği maksimum ön ek uzunluğu. Örneğin, bir kuruluş IPv4 ön eki 203.0.113.0/24'ü kontrol edebilir ve bunu AS64500 ile duyurabilir. Buna karşılık gelen bir ROA, AS64500'nün bu /24'ü kökenlendirmesine izin verebilir. Basit bir ifadeyle, kayıt yönlendirme ekosistemine şu talimatı iletir: “Bu ASN, bu ön eki duyurmaya yetkilidir.” RPKI doğrulaması yapan ağlar daha sonra kaydı BGP'de gözlemledikleri bilgilerle karşılaştırabilir. Bir ROA, bir IP adres bloğunun mülkiyetini devretmez. Sözleşmeyi, kayıt defteri girişini, tahsis kaydını veya IPv4 transfer anlaşmasını yerine geçmez. Yalnızca bir yolun kökeniyle ilgili bir yetkilendirmeyi yayımlar. Yasal denetim ile yönlendirme yetkilendirmesi bağlantılıdır ancak aynı şey değildir. ROA'lar hem IPv4 hem de IPv6 kaynakları için oluşturulabilir. Biçim benzerdir; ancak ön ek uzunlukları ve operasyonel tasarım farklılık gösterebilir. IPv4 ağları genellikle /24 gibi ön eklerle çalışırken, IPv6 ağları tahsislerine ve yönlendirme planlarına uygun olarak /32, /36, /48 veya başka bir uzunlukta agregeler sıkça duyurur.
Neden bir ROA'ya ihtiyaç duyulur?
Bir ROA olmadığında, diğer ağların BGP köken ASN'sinin bir ön eki duyurmasına izin verildiğini doğrulamak için RPKI tabanlı yetkilendirmesi yoktur. Yol hâlâ meşru olabilir, ancak eşleşen bir yetkilendirme bulunmadığından RPKI doğrulaması sırasında genellikle "Bulunamadı" sonucu üretecektir. "Bulunamadı" sonucu otomatik olarak bir yönlendirme sorunu değildir. İnternet üzerindeki birçok geçerli yolun ROA'sı yoktur. Ancak bir kuruluş doğru bir ROA yayımladığında, beklenen kökeni yetkisiz veya yanlış yapılandırılmış bir kökenden ayırt etmek için kullanılabilecek daha güçlü bir sinyal sağlar. Bir önük değerli, iş açısından kritik veya geniş çapta duyurulduğunda bir ROA özellikle faydalı hale gelir. Bir işletme kendi adres uzayını halka açık hizmetler için kullanabilir, bir bulut platformu müşteri altyapısını duyurabilir veya bir barındırma sağlayıcısı birden fazla konumdan büyük adres aralıklarını ilan edebilir. Bu durumlarda, hatalı bir köken birçok kullanıcı ve hizmeti etkileyebilir. ROA'lar ayrıca olay müdahalesi sırasında da yardımcı olur. Bir önük aniden beklenmeyen bir ASN'den ortaya çıkarsa, bir ağ operatörü RPKI durumunu kontrol edebilir ve duyurunun kaynak tutarının yayımladığı niyetle çelişip çelişmediğini hızla belirleyebilir. Bu, olayın her detayını açıklamaz, ancak araştırma için önemli bir başlangıç noktası sağlar. Birden fazla üst düzey sağlayıcı kullanan kuruluşlar için bir ROA, yolu hangi sağlayıcının taşıdığından bağımsız olarak tutarlı bir yetkilendirme sağlayabilir. Sağlayıcı değişebilir, ancak köken ASN aynı kalabilir. Bu durumda, transit yolu değiştiği için ROA'nın yalnızca bu nedenle değiştirilmesi gerekmez.
Bir ROA, BGP ile Nasıl Çalışır?
BGP, otonom sistemler arasında rota duyurularını dağıtır. Bir rota duyurusu genellikle bir IP ön ekini ve bir köken ASN'sini (otonom sistem numarası) ile diğer yol ve politika bilgilerini içerir. Köken ASN'si, rotanın kaynağı olduğunu iddia eden otonom sistemdir. RPKI doğrulaması BGP ile birlikte çalışır. Bir doğrulayıcı, RPKI sisteminden imzalı yetkilendirme verilerini alır ve kayıtların özgün ve güncel olup olmadığını kontrol eder. Ardından, yönlendiriciler, rota sunucuları veya yönlendirme politika sistemleri tarafından kullanılabilecek doğrulanmış bir veri kümesi oluşturur. Bir ağ bir BGP duyurusu aldığında, duyurulan ön eki ve köken ASN'sini doğrulanmış ROA (Route Origin Authorization) bilgileriyle karşılaştırır. Üç temel sonuç vardır: Duyuru Valid (Geçerli), Invalid (Geçersiz) veya Not Found (Bulunamadı) olarak sınıflandırılabilir. Valid sonucu, duyurunun bir ROA tarafından kapsandığını ve köken ASN'sinin yetkili olduğunu gösterir. Invalid sonucu, ilgili bir ROA'nın mevcut olduğunu ancak duyurunun bu ROA ile çeliştiğini ifade eder. Not Found sonucu ise uygulanabilir bir ROA bulunamadığını belirtir. Alan ağı, bu sonuçlarla ne yapılacağına karar verir. Bazı operatörler Invalid rotaları reddeder. Diğerleri onlara daha düşük öncelik atar, uyarı oluşturur veya kaynağa bağlı olarak farklı politikalar uygular. Her ağ için tek bir evrensel politika yoktur, ancak birçok sağlayıcı Invalid duyuruları ciddi bir yönlendirme güvenlik sorunu olarak değerlendirir. Önemli nokta şudur: ROA doğrudan global İnternet'i kontrol etmez. Yetkilendirme bilgilerini yayımlar. Pratik etki, diğer ağların bu bilgileri alıp almadığına, doğrulayıp doğrulamadıklarına ve yönlendirme kararlarında bu bilgileri kullanıp kullanmadıklarına bağlıdır.
Bir ROA'nın Üç Ana Bölümü
Bir ROA'nın ilk kısmı, yetkilendirilen IP ön ekidir ve bu, köken ASN'nin duyurabileceği adres aralığını tanımlar. IPv4 için bir ön ek 198.51.100.0/24 olabilir; IPv6 için ise 2001:db8:1234::/48 olabilir. Ön ek, ilgili kayıt defteri veya sponsorluk ilişkisi aracılığıyla kuruluşun yönetmekle yetkili olduğu bir kaynağa karşılık gelmelidir. Ön ek doğru girilmelidir çünkü yazım hatası, yanlış ağ sınırı veya hatalı ön ek uzunluğu, ROA'yı geçersiz kılabilir veya amaçlanan aralıktan farklı bir aralığı yetkilendirebilir.
İkinci kısım, ön eki köken alan yetkilendirilmiş ASN'dir ve BGP duyurusunun kaynağı olarak görünen ASN ile eşleşmelidir. Bir şirket bir adres bloğuna sahip olsa bile, bunu bir transit sağlayıcının ASN'si üzerinden duyuruyorsa, doğru kaynak asıl yönlendirme tasarımına bağlıdır. ROA'daki ASN, genellikle yukarı taşıyıcının ASN'si değil, rotayı köken alan ASN olmalıdır. Bu ayrım önemlidir çünkü bir transit sağlayıcı, köken olmaktan bağımsız olarak bir rotayı taşıyabilir; eğer müşterinin ASN'si ön eki köken alıyorsa ve sağlayıcı yalnızca onu taşıyorsa, yetkilendirilmesi gereken değer genellikle müşterinin ASN'sidir.
Üçüncü kısım, genellikle maxLength olarak adlandırılan maksimum ön ek uzunluğudur ve bir duyurunun ROA tarafından kapsanırken ne kadar spesifik olabileceğini tanımlar. Bir ROA'nın 198.51.100.0/24'ü /24 maksimum uzunluğuyla yetkilendirdiği varsayılırsa, yetkilendirilmiş ASN tam /24'ü duyurabilir, ancak /25 veya /26 gibi daha küçük alt ön ekleri duyurmaya yetkili değildir. Aynı ön ek /26 maksimum uzunluğuyla yetkilendirilirse, /24, /25 ve /26 için yapılan duyurular, belirli rota ve doğrulama kurallarına bağlı olarak kapsandığı kabul edilebilir. Bu durum esneklik sağlar, ancak aynı zamanda daha spesifik duyurulara da izin verir. Bu nedenle maksimum uzunluk, gerçek yönlendirme planını yansıtmalıdır; çok kısa ayarlanması meşru daha spesifik rotaların Geçersiz hale gelmesine neden olabilirken, çok uzun ayarlanması kuruluşun asla izin vermeyi amaçlamadığı duyuruları yetkilendirebilir.
Neden maxLength Önemlidir?
Maksimum ön ek uzunluğu, yetkili ASN'nin kaynağı ilan ederken kullanabileceği özgüllük düzeyini kontrol eden en önemli ve en sık yanlış anlaşılan ROA ayarlarından biridir. Çoğu ağ operatörü, yönlendirme tablosu büyümesini azaltmak için bir önek topluluğunu (aggregate prefix) ilan eder; örneğin, bir kuruluş /20'lik bir bloğa sahip olabilir ancak bunu tek bir önek olarak ilan edebilir. Bazı durumlarda, kuruluş trafik mühendisliği, bölgesel bağlantı veya hizmet ayrımı için daha küçük önekleri de ilan etmesi gerekebilir. Eğer ROA yalnızca önek topluluğunu kapsıyor ve ağ daha spesifik yolları ilan ediyorsa, bu yollar "Geçersiz" olarak sınıflandırılabilir. BGP ilanı, kuruluşun perspektifinden teknik olarak doğru olsa da RPKI'de yayımlanan yetkilendirmeyle eşleşmez. Öte yandan, her olası daha spesifik yolu yetkilendirmek, politikanın hassasiyetini zayıflatabilir; çünkü aşırı geniş bir maksimum uzunlukla yetkilendirilen bir /20, kastedilen tasarımdan dışta olsa bile çok daha küçük bir alt önekin yetkilendirilmiş gibi görünmesine izin verebilir. Pratik bir yaklaşım, adresleme planına, sağlayıcı gereksinimlerine, devre dışı kalma tasarımı ve trafik mühendisliği stratejisine dayanarak ağın gerçekten ilan etmeyi beklediği önek uzunluklarını yalnızca yetkilendirmektir. Maksimum uzunluktaki değişiklikler dikkatlice test edilmeli, katı filtrelemeyi uygulamadan önce tüm üretim ilanlarının beklenen doğrulama sonucunu döndürdüğü onaylanmalıdır.
ROAs for IPv4 and IPv6
ROA'lar hem IPv4 hem de IPv6 ağları için oluşturulabilir ve temel güvenlik ilkesi aynıdır: bir ön eki yetkili köken ASN'si ile ilişkilendirmek. Başlıca operasyonel fark, adresleme yapısıdır. IPv4 kaynakları kıtadır ve genellikle nispeten küçük ön eklerde duyurulur; /24, genel İnternet'te yaygın olan minimum duyuru boyutudur. IPv6 ağları genellikle daha büyük tahsisler alır ve bunları site, hizmet veya coğrafi segmentlere bölebilir, bir agregat duyururken birden fazla dahili ön ek kullanır. ROA, kamuya açık olarak duyurulan ön eklerle uyumlu olmalıdır. IPv6 operatörleri, büyük bir adres uzayının yönlendirme riskini ortadan kaldırdığını varsaymamalıdır; çünkü yetkisiz bir IPv6 duyurusu hala erişilebilirlik sorunlarına, trafik yeniden yönlendirmesine veya tutarsız küresel yönlendirmeye neden olabilir. RPKI, IPv6 operatörlerine IPv4 operatörlerinin yaptığı gibi köken yetkilendirmesini yayınlama aynı fırsatı verir. IPv6 ROA'larını oluşturmadan önce, ağ ekibi hangi agregat ön eklerin duyurulacağını, daha spesifik duyuruların beklenip beklenmediğini ve bunları hangi ASN'nin kökenleyeceğini belgelemeli; bu sayede ya çok kısıtlayıcı ya da gereğinden fazla geniş kayıtlardan kaçınılmalıdır.
Ne Zaman Bir ROA Oluşturmalısınız?
Bir prefix üretim ortamında duyurulmadan önce, kaynak sahibi net bir yönlendirme planına sahipse bir ROA oluşturulmalıdır; bu, doğrulama ağlarının rota geniş çapta görünmeden önce bilgiyi almasına zaman tanır. Örgütler ayrıca yeni bir tahsilat aldıklarında, IPv4 bloğu edindiklerinde, adres transferi tamamladıklarında, köken ASN'sini değiştirdiklerinde veya yeni bir IPv6 tahsisatı kullanmaya başladıklarında ROA'ları gözden geçirmelidir; çünkü bu olaylar prefix ile köken ağı arasındaki ilişkiyi değiştirir. Bir sağlayıcı migrasyonu da yaygın bir tetikleyicidir: Örgüt aynı köken ASN'sini korur ve yalnızca üst düzey taşıyıcıyı değiştirirse, ROA geçerliliğini koruyabilir; ancak migrasyon köken ASN'sini değiştiriyorsa, kayıt yönlendirme değişikliğinden önce veya eş zamanlı olarak güncellenmelidir. ROA'lar, halka açık yetkilendirmenin operasyonel gerçeklikle uyumlu olduğundan emin olmak için birleşmeler, satın almalar, veri merkezi taşıma işlemleri, ASN sponsorluğu değişiklikleri ve büyük ağ yeniden tasarımları sırasında gözden geçirilmelidir. Bilinen hiçbir değişiklik gerçekleşmemiş olsa bile periyodik bir gözden geçirme faydalıdır; çünkü ağ dokümantasyonu güncelliğini yitirebilir, personel sorumlulukları değişebilir ve eski yetkilendirmeler orijinal yönlendirme tasarımı çok uzun süre önce değiştirilmiş olsa dahi aktif kalabilir.
Yaygın ROA Yapılandırma Hataları
En yaygın hatalardan biri, yanlış köken ASN’sinin girilmesidir; bu durum, mühendislerin müşteri ASN’sini transit sağlayıcı ASN’si ile karıştırması veya bir taşıma işleminden sonra yapılandırmada eski bir ASN’in kalmasıyla gerçekleşir. Başka bir yaygın hata ise IPv4 transferinden sonra ROA’nın güncellenmemesidir; yeni sahip, prefix’i kendi ASN’sinden ilan ederken eski yetkilendirme hala önceki kökene işaret ettiği için rota Geçersiz (Invalid) haline gelir. Yanlış maksimum uzunluk da benzer sorunlara yol açar: bir kuruluş yalnızca /24’ü yetkilendirirken, daha sonra trafik mühendisliği amacıyla /25’i ilan ederse. Bazı kuruluşlar amaçlarını belgelendirmeden birden fazla örtüşen ROA oluşturur; bazı tasarımlarda geçerli olsalar da beklenmedik sonuçlar üretebilir ve sorunu gidermeyi zorlaştırabilir. Eski kayıtların kaldırılmaması, ağ tasarımı değiştiği çok uzun süre sonra bile bir ASN’in prefix’i köken almasına neden olur. Son olarak, kuruluşlar bazen kendi ilanlarını önceden test etmeden Geçersiz rotaların kesin reddini etkinleştirir; üretimdeki prefix’ler, maksimum uzunluklar ve köken ASN’leri, otomatik filtrelemeye güvenilmeden önce her zaman doğrulanmalıdır.
ROA and IPv4 Transfer Planning
IPv4 transferleri, idari sahibi, sponsorluk düzeni ve yönlendirme kökeni sürecin farklı aşamalarında değişebileceğinden özel dikkat gerektirir. Transferden önce mevcut sahip, mevcut ROA’ları belgelemeli ve prefix'i şu anda hangi ASN'nin orijin ettiğini doğrulamalı; alıcı ise amaçlanan orijin bilgilerini hazırlamalı ve transit sağlayıcılarla koordinasyon kurmalıdır. Geçiş sırasında her iki taraf da yetkilendirme kayıtlarının güncellenmesi veya değiştirilmesi için net bir plana ihtiyaç duyar: Önceki ROA’nın transferden sonra çok uzun süre aktif bırakılması, eski orijini transfer sonrası da yetkilendirmeye neden olurken; erken kaldırılması, yeni rota hazır olmadan mevcut rotanın Invalid (Geçersiz) durumuna düşmesine yol açar. Süreç tam olarak kayıt defteri türüne, kaynak türüne, transfer anlaşmasına ve operasyonel tasarıma bağlı olduğundan RPKI, kayıt defteri doğrulaması, sözleşmesel inceleme, BGP duyuruları, route nesneleri, ters DNS ve itibar taraması ile birlikte temel bir kontrol listesi öğesi haline gelir. Bir halka açık hazırlık denetleyicisi, teknik ön kontroller için bir prefix'in mevcut orijin ASN'sini, RPKI durumunu, kayıt defteri bilgilerini ve BGP görünürlüğünü belirlemeye yardımcı olur; ancak yasal sahipliği onaylamaz veya transfer uygunluğunu garanti etmez.
ROA ve ASN Değişiklikleri
Bir ASN değişikliği, RPKI doğrulamasını doğrudan etkiler. Daha önce AS64500 tarafından ilan edilen bir ön ek artık AS64510 tarafından ilan edilecekse, BGP ilanı "Geçerli" olarak kabul edilmeden önce ROA'nın yeni kökeni yetkilendirmesi gerekir. Bu durum, özellikle bir kuruluş sağlayıcı yönetimli bir ASN'den kendi ASN'sine geçtiğinde veya destekleyen LIR düzenlemesini değiştirdiğinde, kayıt ilişkisi ve yönlendirme yetkilendirmesinin birlikte gözden geçirilmesini gerektirdiğinden son derece önemlidir. Dikkatlice planlanmış bir geçiş, belgelenmiş olması ve tamamlanır da eski yetkilendirme kaldırılmak kaydıyla, kontrol göç penceresi oluşturmak için geçici olarak hem eski hem de yeni kökenlerin yetkilendirilmesini içerebilir. Ağ ekibi, üretim değişikliklerini yapmadan önce işlemlerin sırasını test etmeli ve yeni BGP rotasının ilan edilmesinden önce yeni yetkilendirmenin yayınlandığını ve doğrulandığını sağlamalıdır.
Bir ROA'nın çalışıp çalışmadığını nasıl kontrol edersiniz?
İlk kontrol, ilgili RIR portalı, sponsor LIR arayüzü veya RPKI yönetim sistemi aracılığıyla ROA'nın amaçlanan prefix'i, köken ASN'sini ve maksimum prefix uzunluğunu içerdiğini doğrulamaktır. Ardından, yetkilendirme ile gerçek BGP duyurusunu karşılaştırarak, duyurulan prefix uzunluğunun kapsandığını ve köken ASN'nin ROA ile eşleştiğini doğrulayın. Daha sonra harici bir RPKI doğrulayıcısı, doğru yapılandırılmış bir duyurunun "Valid" (Geçerli) döndürdüğü kamu durumunu onaylayabilir. Sonuç "Invalid" (Geçersiz) ise, önce köken ASN'sini ve prefix uzunluğunu inceleyin; "Not Found" (Bulunamadı) ise, ROA'nın yayımlandığını ve doğrulayıcıların onu alması için yeterli zaman geçip geçmediğini doğrulayın. Sonuçlar anında güncellenmez çünkü depolar, doğrulayıcılar ve yönlendirme sistemleri yenileme aralıklarına bağlıdır; bu nedenle yayılma sırasında kısa gecikmeler normaldir. Birden fazla kamu kaynağını—kayıt defteri verileri, doğrulayıcı sonuçları ve mevcut BGP gözlemleri dahil—karşılaştırmak, önbelleğe alınmış bilgilere güvenmekten kaçınır ve eksiksiz bir resim sağlar.
Bir ROA Geçersiz Olduğunda Ne Olur?
Bir BGP duyurusu mevcut bir ROA ile çakıştığında, RPKI doğrulayıcıları bunu Geçersiz olarak sınıflandırır. Yol, küresel İnternet'ten otomatik olarak kaldırılmaz; ancak RPKI tabanlı politikaları uygulayan ağlar bu yolu reddedebilir veya daha düşük öncelik atayabilir. Operasyonel etki, uygulama kapsamına bağlıdır: bazı ağlar sıkı filtreleme yaparken, diğerleri durumu izlemek için kullanır; bu nedenle bir Geçersiz yol, İnternet'in bazı bölümlerinde görünür kalırken diğerlerinden erişilemez hale gelebilir. Meşru bir yol Geçersiz olduğunda, kuruluş bunu acil bir yapılandırma sorunu olarak ele almalı ve köken ASN'si, duyurulan ön ek uzunluğu ile ROA maksimum uzunluğunun gözden geçirilmesini önceliklendirmelidir. Yol kötü amaçlı olduğu varsayılmamalıdır; çoğu Geçersiz sonuç, eksik geçişler, eski kayıtlar, hatalı sağlayıcı bilgileri veya yanlışlıkla yapılan daha spesifik duyurular gibi rutin hatalardan kaynaklanır. Düzeltildikten sonra sistemlerin yenilenmesi için zaman gerekir ve ağ ekimi, yol tüm gözlem noktalarında kararlılığa ulaşana kadar izlemeye devam etmelidir.
Kuruluşlar ROA'ları Nasıl Yötmelidir?
ROA yönetimi, ağ mühendisliği ekibi, güvenlik ekibi, sponsor LIR, yönetilen hizmet sağlayıcısı veya İnternet numara kaynaklarından sorumlu başka bir grup gibi açık bir sahipliği gerektirir. Kuruluş, değişiklik incelemelerini ve olay yanıtlarını kolaylaştırmak amacıyla her ön ek için detaylı bir envanteri korumalıdır; bu envanterde köken ASN'si, maksimum uzunluk, duyuru konumları ve sorumlu kişiler yer almalıdır. ROA değişiklikleri, standart ağ değişiklik prosedürlerine entegre edilmeli; RPKI, ASN geçişleri, sağlayıcı değişimleri, IPv4 transferleri veya IPv6 dağıtımları sırasında açık bir gereklilik olarak ele alınmalıdır. Geçersiz sonuçlar, beklenmeyen kökenler, kaldırılan yetkilendirmeler veya BGP görünürlüğündeki kaymalar için izleme ve uyarı yapılandırılmalıdır. Kritik olarak, kuruluşlar aşırı geniş yetkilendirmelerden kaçınmalıdır: hassas ROA'lar daha kolay anlaşılır, denetimi daha basit ve istenmeyen duyurulara izin verme olasılığı çok daha düşüktür.
Sıkça Sorulan Sorular
Bir ROA, bir IP sahiplik belgesi ile aynı mıdır?
Hayır. Bir ROA, BGP'de bir prefix'i hangi ASN'nin köken alabileceğini belirten bir yönlendirme yetkilendirmesidir. Kayıt defteri kayıtlarını, sözleşmeleri, devir belgelerini veya yasal mülkiyet kanıtlarının yerine geçmez.
Bir ön ek birden fazla ROA'ya sahip olabilir mi?
Evet. Bir ön ek, kasıtlı olarak birden fazla ASN tarafından kökenlendirildiğinde veya kontrollü bir geçiş sürecinde birden fazla köken için geçici yetkilendirme gerektiğinde birden fazla ROA uygun olabilir; ancak örtüşen kayıtlar dikkatlice belgelenmelidir.
Bir ROA, BGP'de ön ekimi (prefix) ilan eder mi?
Hayır. Bir ROA oluşturmak, bir BGP duyurusu oluşturmaz; ağın hala yönlendiricileri ve yukarı tedarikçileri üzerinden BGP yapılandırması yapması gerekir.
Bir transit sağlayıcının ROA'da listelenmesi gerekiyor mu?
Genellikle ROA, rotayı başlatan ASN'yi belirtmelidir. Sadece rotayı taşıyan bir sağlayıcı, başlangıç ASN'si olmak zorunda değildir ve doğru değer, gerçek yönlendirme mimarisine bağlıdır.
Bir ROA'nın görünür hale gelmesi ne kadar sürer?
Zamanlama, RIR sistemi, yayın deposu, doğrulayıcı yenileme aralıkları ve önbelleğe alma işlemlerine bağlıdır. Güncellemeler genellikle nispeten hızlı bir şekilde görülebilir; ancak üretim değişiklikleri için doğrulama sürecine yeterli süre tanınmalıdır.
Her IPv4 ve IPv6 ön eki için bir ROA olması gerekir mi?
BGP'de ilan edilen prefix'ler için doğru ROA'ların yayınlanması şiddetle tavsiye edilir. Organizasyon, yetkilendirmenin yanlışlıkla meşru ilanları geçersiz kılmaması için önce yönlendirme tasarımını doğrulamalıdır.
Bir ROA, her BGP saldırısına karşı koruma sağlayabilir mi?
Hayır. Bir ROA (Route Origin Authorization), öncelikle köken doğrulamasını destekler. BGP yolunun her kısmını doğrulamaz, tüm rota sızıntılarını önlemez, trafiği şifrelemez veya trafiğin güvenli bir fiziksel rotayı izlediğini garanti etmez.
Bir Rota Köken Yetkilendirmesi (ROA), RPKI'nin temel bileşenlerinden biridir ve bir IP ön ekini BGP'de bu ön eki kökene gönderecek şekilde yetkilendirilen ASN arasında kriptografik olarak imzalanmış bir ilişki kurar. Kayıt genellikle ön eki, köken ASN'sini ve maksimum ön ek uzunluğunu içerir; bunların her biri kaynağı tanımlamada, kökeni izin vermede ve duyurunun ne kadar spesifik olabileceğini belirlemede belirleyici bir rol oynar. Doğru ROA'lar ağların yetkisiz veya yanlış yapılandırılmış duyuruları tespit etmesine yardımcı olur ve IPv4 transferleri, ASN değişiklikleri, sağlayıcı geçişleri, IPv6 dağıtımları ve çoklu ev sahipliği ağ operasyonları sırasında hayati önem taşır. Aynı zamanda bir ROA, yasal mülkiyet kanıtı değildir ve tek başına bir yönlendirme güvenliği çözümü de değildir; doğru kayıt defteri kayıtları, disiplinli BGP yapılandırmaları, IRR verileri, rota izleme ve belgelenmiş değişiklik süreçleriyle birlikte en iyi şekilde işlev görür. Herhangi bir kuruluşun genel IPv4 veya IPv6 alanını duyurması durumunda pratik kural basittir: yalnızca kullanmayı planladığınız kökenleri yayınlayın, yalnızca gerçekten duyurmayı planladığınız ön ek uzunluklarını yetkilendirin ve ağda herhangi bir değişiklik olduğunda kayıtları gözden geçirin. Bu, RPKI verilerinin gerçek yönlendirme ortamıyla uyumlu kalmasını sağlar ve meşru bir rotanın "Geçersiz" olarak sınıflandırılma olasılığını azaltır.