RPKI ve ROA nedir? Yanlış bir ROA duyurunuzu neden görünmez yapar

BGP'nin tasarımında eksik bir parça var: protokolün kendisi, bir ASN'in duyurduğu bloğu duyurmaya gerçekten yetkili olup olmadığını sorgulamaz. Komşusundan gelen duyuruyu kabul eder ve dünyaya yayar. RPKI bu boşluğu, imzalı bir kayıt katmanı ekleyerek kapatır — kendi bloğunu başka bir ağ üzerinden duyurmaya hazırlanan herkesin en dikkatli olması gereken kayıt da budur.

Yanlış yapıldığında sonuç "korumasız kalmak" değildir. Duyurunuz, doğrulama yapan operatörlerde tamamen reddedilir. Bu yazı ROA'nın hangi alanlardan oluştuğunu, üç doğrulama sonucunun ne anlama geldiğini ve iki klasik hatanın nasıl göründüğünü anlatıyor.

ROA üç şey söyler

ROA (Route Origin Authorisation), blok sahibinin imzaladığı bir kayıttır ve üç alanı vardır:

Cümleye çevirirsek: "Şu bloğu, şu ASN, en fazla şu uzunlukta duyurabilir." Yönlendirme tablosunda bu üçlüye uymayan bir duyuru gördüğünde, doğrulama yapan bir router bunu bilerek reddeder.

Üç sonuç: valid, invalid, not-found

Bir duyuru doğrulandığında üç sonuçtan biri çıkar.

Valid — bloğu kapsayan bir ROA var ve duyuru hem origin ASN hem uzunluk bakımından ona uyuyor. Beklediğiniz durum budur.

Invalid — bloğu kapsayan bir ROA var ama duyuru ona uymuyor. Origin ASN farklıdır ya da prefix, maxLength'in izin verdiğinden uzundur. RPKI doğrulaması yapan operatörler bu durumda trafiği hiç kabul etmez.

Not-found — bloğu kapsayan bir ROA yok, yani RPKI sizin duyurunuz hakkında hiçbir şey söylemiyor. Bu, duyurunun reddedileceği anlamına gelmez; RPKI'nin sunduğu korumadan yararlanmadığınız anlamına gelir.

Kritik ayrım şudur: RPKI temelli reddetme invalid durumunu hedefler, not-found durumunu değil. Yani RPKI'ye hiç dokunmamış bir blok, yanlış ROA'lı bir bloktan daha az erişilebilirlik riski taşır. Kayıt açmak koruma sağlar; kaydı açıp duyuruyu değiştirmeyi unutmak ise doğrudan kesinti üretir.

Birinci klasik hata: origin ASN'i güncellememek

Senaryo her zaman aynı: blok yıllardır kendi ASN'inizden duyuruluyor, ROA da o ASN'i gösteriyor. Sonra bloğu bir koruma sağlayıcısının ağı üzerinden duyurmaya karar veriyorsunuz. Duyuru düzeni değişiyor, ROA ise eski değerde kalıyor. Sonuç: invalid.

Burada önemli bir nokta var — ROA'da yazması gereken origin ASN, tasarıma göre sizin ASN'iniz de olabilir, duyuruyu üstlenen ASN de. Belirleyen şey, duyuruyu fiilen hangi ASN'in başlattığıdır. Bu yüzden değeri tahmin etmeyin; BGP koruma kurulumunda kayıt değerleri — origin ASN, maxLength ve IRR route nesnesi — geçiş planıyla birlikte size yazılı olarak verilir. Kaydı siz güncellersiniz, çünkü RIPE hesabı sizindir; hangi değerin ne olacağını sağlayıcı söyler.

Belirtisi de sinsidir: invalid bir duyuru herkes tarafından değil, yalnızca doğrulama uygulayan ağlar tarafından reddedilir. Yani bazı bölgelerden erişilir, bazılarından erişilmez. "Bizde çalışıyor" cümlesi bu hatayı saatlerce gizleyebilir.

İkinci klasik hata: maxLength'i geniş bırakmak

maxLength'in cazibesi şudur: geniş tutarsanız ileride bloğu bölüp daha uzun prefix'ler duyurmanız gerektiğinde ROA'yı tekrar elden geçirmezsiniz. Bedeli ise doğrudan güvenlik tarafında.

RPKI yalnızca iki şeye bakar: duyuruyu yapan ASN ve prefix uzunluğu. maxLength'i gerçekte duyurduğunuzdan uzun tutmak, sizin origin ASN'inizle yapılan ama sizin yapmadığınız daha uzun bir duyuruyu da geçerli hale getirir. Daha uzun prefix yönlendirmede daha spesifik olduğu için trafiği kendine çeker — yani bloğunuzun alt parçalarının başkası tarafından duyurulmasına kapı aralamış olursunuz.

Pratik kural basit: maxLength, bugün fiilen duyurduğunuz prefix uzunluğuna eşit olsun. Bölmeniz gerektiğinde ROA'yı o zaman güncellersiniz; bu, birkaç dakikalık bir iştir.

IPv4 ve IPv6 kayıtları ayrıdır

IPv6 bloğunuz da aynı mantıkla duyurulur: IRR tarafında route6 nesnesi tanımlanır, RPKI ROA kaydı IPv6 prefix'i için ayrıca oluşturulur. İki ailenin kayıtları birbirinden tamamen bağımsızdır ve birini güncelleyip diğerini unutmak sık görülen bir hatadır. Çift yığın (dual-stack) çalışan bir hizmette bunun belirtisi özellikle kafa karıştırıcıdır: aynı alan adı bazı istemcilerde açılır, IPv6 tercih eden istemcilerde açılmaz.

Zamanlama: kayıt önce, duyuru sonra

Kayıt değişikliklerinin yayılması saatlere yayılabilir. Bu yüzden sıra hiçbir zaman tersine çevrilmez: önce ROA ve IRR güncellenir, yayılması beklenir, doğrulama durumu bağımsız kaynaklardan valid okunur, sonra duyuru açılır. Duyuru açıldıktan sonra kaydı düzeltmeye çalışmak, kesintiyi yayılma süresi kadar uzatmak demektir.

Geçiş sırasında bakılacak üç şey vardır: bloğun bağımsız gözlemcilerden — RIPE RIS, looking glass hizmetleri, kamuya açık BGP izleme araçları — görünürlüğü, RPKI doğrulama durumunun valid okunması ve gerçek kullanıcı trafiğinin beklenen yoldan gelmesi.

Bloğunuz yoksa bu sizi neden ilgilendirir

Kendi bloğunuz yoksa ROA'yı siz yönetmezsiniz, ama sonucunu yaşarsınız: kullandığınız adreslerin kayıtları yanlışsa erişilebilirlik sorunu sizin hizmetinizde görünür. IP kiralama modelinde adresler Datafex ağı üzerinden duyurulduğu için bu kayıtların sorumluluğu bizde kalır; sizin tarafınızda kalan iş rDNS ve yönlendirme tanımlarıdır.

Kendi bloğunuzu taşımayı planlıyorsanız başlamadan önce mevcut ROA'nızın origin ASN ve maxLength değerlerini çıkarın. Geçiş planını bu iki sayı belirler — bize yazarken onları da gönderin.