RPKI ve ROA'lar: alıcıların ve kiracıların gerçekte yapması gerekenler

Bu neden artık isteğe bağlı değil

Yıllarca RPKI, operatörlerin iyi bir fikir olduğunda anlaştığı ama bir türlü uygulamaya geçmediği bir şeydi. Büyük ağlar onu gerçekten uygulamaya başladığında bu değişti. Büyük transit sağlayıcılar, büyük bulut platformları ve birkaç büyük içerik ağı artık Route Origin Validation yapıyor ve geçersiz (invalid) dönen rotaları atıyor.

Pratik sonuç serttir. Bozuk bir ROA'ya sahip bir prefix yalnızca korumasız değildir, internetin giderek artan bir kısmından ulaşılamaz. Ve arıza kısmi ve kafa karıştırıcıdır: bazı kullanıcılar size ulaşır, bazıları ulaşamaz ve traceroute'lar test ettiğiniz yerden sorunsuz görünür.

Adres alanı satın alıyor veya kiralıyorsanız, size bir gün kaybettirmesi en olası tek yapılandırma ayrıntısı budur.

ROA aslında nedir

RPKI, adres kaydına bağlı kriptografik onaylardan oluşan bir sistemdir. Gündelik olarak önemli olan nesne Route Origin Authorization, yani ROA'dır ve tam olarak üç şey içerir:

• Prefix. Örneğin 192.0.2.0/24.
• Kaynak AS. Onu anons etmesine izin verilen otonom sistem numarası.
• Bir maksimum uzunluk. O blok içinde anons edilebilecek en uzun prefix.

Nesnenin tamamı budur. Adres sahibinden, “bu AS bu alanı, bu belirli boyuta kadar başlatabilir” diyen imzalı bir beyandır. Router'lar onu doğrudan okumaz. Doğrulayıcılar RPKI verilerini alıp doğrular ve sonucu router'lara iletir; router'lar da her rotayı valid, invalid veya not-found olarak sınıflandırır.

Her rota üç durumdan birine düşer. Valid: bir ROA prefix'i kapsar ve anons onunla eşleşir. NotFound, birçok aracın Unknown olarak gösterdiği: hiçbir ROA prefix'i kapsamaz. Invalid: bir ROA prefix'i kapsar ama anons onunla çelişir; ya yanlış AS'den ya da maksimum uzunluğun izin verdiğinden daha uzun bir prefix'le.

Bu durumların sırası insanların beklediğinden daha önemlidir. ROA'sı olmayan bir rota hâlâ neredeyse her yerde kabul edilir: korumasızdır ama geçer. Invalid dönen bir rota ise doğrulamayı uygulayan her ağ tarafından düşürülür. ROA olmaması yanlış bir ROA'dan iyidir. Amaç doğru bir ROA'dır, ama anons ettiğiniz gün ayrıntılar netleşmemişse, ROA olmadan anons edip netleştiğinde eklemek, gönderdiğinizle çelişen bir ROA yayımlamaktan çok daha güvenlidir.

Kimin oluşturduğu alanı nasıl edindiğinize bağlıdır

Bu insanları sürekli yanıltır, bu yüzden açıkça belirtmeye değer.

Bloğu satın aldıysanız, size kayıtlıdır ve ROA'yı kayıt kuruluşunuzun portalında kendiniz oluşturursunuz veya kayıt ilişkisini sizin adınıza tutan bir sponsor LIR varsa onun oluşturmasını istersiniz. Bunu transfer tamamlandıktan sonra yapın, önce değil, çünkü nesnenin yeni sahip altında oluşturulması gerekir. RIPE NCC bölgesinde satın alınan legacy alanın ROA'sı olabilmesi için önce RIPE NCC ile veya bir sponsor LIR ile bir sözleşmesi olması gerekir (RIPE NCC).

Kiralıyorsanız, blok size kayıtlı değildir ve ROA'yı oluşturamazsınız. Sahip onu sizin ASN'niz için oluşturur. Bu, ona baştan iki şey söylemeniz gerektiği anlamına gelir: anons edeceğiniz ASN ve bloğun tamamından daha spesifik bir şey anons etmeyi düşünüp düşünmediğiniz. ROA'nın ASN'niz için oluşturulmadığı bir kiralama, anons ettiğiniz anda invalid olarak doğrulanır.

BYOIP kapsamında bir bulut sağlayıcı üzerinden anons ediyorsanız, ROA'nın genellikle sizinkini değil sağlayıcının ASN'sini belirtmesi gerekir, çünkü rotayı onların ağı başlatır: AWS'de AS16509 ve AS14618, Azure'da AS8075, Google Cloud'da Premium katmanında AS396982. Bazı sağlayıcılar bunun yerine kendi ASN'nizden başlatmanıza izin verir; ya kendi BGP oturumunuz üzerinden (Vultr, Cherry Servers) ya da BYOIP'nin üzerine bir “kendi ASN'nizi getirin” seçeneği olarak (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). O zaman bir ROA sizin ASN'nizi belirtir ve AWS ile Oracle Cloud kendilerininkini belirten bir tane daha ister. Çoğu sağlayıcı ROA'nın belirtmesi gereken ASN'yi belgeler, aralarında Gcore'un da bulunduğu birkaçı ise onu yalnızca sorduğunuzda verir, bu yüzden bir şey oluşturmadan önce kontrol edin; sağlayıcı rehberlerimiz onları listeler.

Kesintilere neden olan iki hata

Gerçek dünyadaki RPKI arızalarının neredeyse tamamı maksimum uzunluğa dayanır.

Fazla serbest ayarlamak. 192.0.2.0/24 için maksimum uzunluğu /32 olan bir ROA, o blok içindeki her boyuttaki her anonsun doğrulandığı anlamına gelir. Bu, amacın çoğunu boşa çıkarır: sizin AS numaranızdan daha spesifik bir rota anons eden bir ele geçiren yine valid döner ve BGP'de daha spesifik rotalar kazanır. Güvenli varsayılan, somut bir nedeniniz yoksa maksimum uzunluğu prefix uzunluğuna eşit ayarlamaktır.

Fazla katı ayarlamak. Bir ROA'nın kapsadığı bir /24'ü anons ederseniz ve sonra trafik mühendisliği için iki /25'e bölmeniz gerekirse, bu /25'ler anında invalid olur ve internetin büyük bir kısmından kaybolur. Daha spesifik anonslar yapmayı planlıyorsanız, ROA başlamadan önce buna izin vermelidir.

İkisinden de kaçınan kural: ROA'nın gerçekte anons ettiğiniz şeyi tam olarak tanımlamasını sağlayın ve onu her yönlendirme değişikliğiyle aynı değişiklik penceresinde güncelleyin, sonrasında değil.

ASPA: sonraki katman

Bir ROA bir rotanın ilk halkasını korur: onu kimin başlatabileceğini. Ondan sonraki yol hakkında hiçbir şey söylemez; rota sızıntıları orada olur, bir ağ kendine saklaması gereken rotaları ilettiğinde. ASPA, yani Autonomous System Provider Authorization, bu boşluğun bir kısmını kapatır.

Bir ASPA nesnesi bir AS numarasının sahibi tarafından imzalanır ve onun upstream sağlayıcıları olan AS'leri listeler. Onu doğrulayan ağlar, AS'nizin internete sağlayıcınız olmayan biri üzerinden ulaşıyor göründüğü bir yolu reddedebilir. Gelişmekte olan bir IETF standardıdır. RIPE NCC onu imzalama için kullanıma hazır olarak tanımlar ve ARIN ile APNIC de sahiplerin ASPA imzalamasına izin verir (kayıt kuruluşları karşılaştırması).

• Kendi ASN'niz varsa, rotalarınızı internete taşıyan her upstream'i listeleyen bir ASPA yayımlayın. Peer'leri ve kendi müşterilerinizi dışarıda bırakın.
• Güncel tutun. Nesnede eksik olan bir sağlayıcı, ASPA uygulayan ağlar tarafından rotalarınızın o sağlayıcı üzerinden reddedilmesine yol açabilir, bu yüzden yeni bir transiti açmadan önce ekleyin ve eskisini kapattıktan sonra kaldırın.
• Kendi ASN'nizi bir buluta mı getiriyorsunuz? AWS, ASN'nizin sağlayıcıları olarak AS16509 ve AS14618'i listeleyen bir ASPA önerir; onlar olmadan sizin için yeniden duyurduğu rotalar ASPA doğrulamasından geçemez.
• Kiralıyor musunuz? ASPA prefix'e değil ASN'nize aittir, bu yüzden onu yayımlamak bize değil size düşer.

Kontrol listesi

Alan üretim trafiği taşımadan önce:

• ROA mevcut, doğru prefix ve doğru kaynak AS için.
• Maksimum uzunluk gerçek anons planınızla eşleşiyor.
• IRR route nesneleri de yerinde. RPKI onların yerini almadı. Birçok upstream prefix filtrelerini hâlâ IRR verilerinden oluşturur, bu yüzden eşleşen route nesnesi olmayan geçerli bir ROA yine de filtrelenmenize yol açar.
• ASPA her upstream'i listeliyor, bir tane yayımlıyorsanız, peer veya müşteri olmadan.
• Dışarıdan doğrulayın. Kendi rotalarınızı memnuniyetle kabul edecek kendi ağınızdan değil, dışarıdaki bir looking glass'tan veya bir RPKI doğrulayıcıdan kontrol edin.
• Çıkarken temizleyin. Bir kiralama sona erdiğinde veya bir bloğu anons etmeyi bıraktığınızda ROA geri çekilmeli veya güncellenmelidir. Alanı artık anons etmeyen bir ASN'yi gösteren eski bir ROA, onu sonra alan kişi için bir sorundur.

RTM Networks'ün yeri

ROA'ları bir eklenti olarak değil, hem kiralamanın hem sponsorluğun parçası olarak oluşturur ve sürdürürüz (IPv4 kiralama, PI ve ASN sponsorluğu). Bir kiralama için, anons edeceğiniz ASN'yi veya alanı getirdiğiniz bulut sağlayıcıyı ve daha spesifik anonslara ihtiyacınız olup olmadığını söyleyin, ROA teslimden önce yapılandırılır. Sponsorlu kaynaklar için RPKI yapılandırmasını diğer kayıt nesneleriyle birlikte yönetiriz.

Alanı başka bir yerden devralıyorsanız, RPKI'yi kimin kuracağı yola bağlıdır: blok için bunu alıcı yapar, bir kiralamada ise kiraya veren. Blok için bir ROA olup olmadığını ve varsa geçerli olup olmadığını kontrol edebiliriz.