RPKI ve ROA Nedir? ROA Oluşturma ve Max-Length Hatası

RPKI (Resource Public Key Infrastructure), bir IP bloğunu hangi ASN'in anons etmeye yetkili olduğunu kriptografik olarak kanıtlayan sistemdir. ROA (Route Origin Authorization) ise bu yetkiyi tanımlayan imzalı kayıttır: "Bu prefix, şu ASN tarafından, en fazla şu uzunluğa kadar anons edilebilir." Ağların bir kısmı ROA'ya uymayan rotaları (RPKI invalid) düşürdüğü için, hatalı bir ROA veya yanlış max-length değeri IP bloğunuzun internetin bir bölümünden erişilemez olmasına yol açabilir.

Bu yazıda ROA'nın ne yaptığını, nasıl oluşturulacağını, invalid rotaların neden düşürüldüğünü ve en sık görülen max-length hatasını örneklerle anlatıyoruz. Örneklerde yalnızca dokümantasyon amaçlı kaynaklar kullanılır: 198.51.100.0/24, 2001:db8::/32, AS64496.

RPKI ve ROA Nedir?

BGP, tasarım gereği anonsa güvenir. Herhangi bir ağ bir prefix'i anons ederse, filtre yoksa komşuları bunu kabul edebilir. Yanlış yapılandırma veya kötü niyet (prefix hijack) bu yüzden mümkündür. RPKI, bu sorunun origin (rotayı kimin başlattığı) kısmını çözer.

Mantık şöyle işler:

1. Beş RIR (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC) kendi dağıttığı kaynaklar için güven çıpası (trust anchor) işletir.
2. IP bloğunun sahibi, RIR portalından ROA yayınlar.
3. Ağlar, bu kayıtları bir validator (Routinator, rpki-client, FORT gibi) ile indirip doğrular.
4. Validator, geçerli kayıtları (VRP) RTR protokolüyle yönlendiriciye aktarır.
5. Yönlendirici her gelen rotayı bu listeyle karşılaştırır. Buna Route Origin Validation (ROV) denir.

Bir ROA üç temel alan içerir:

Önemli bir sınır: ROA yalnızca origin'i doğrular, AS path'in tamamını değil. Path doğrulaması ayrı bir konudur (ASPA gibi çalışmalar sürmektedir).

Üç Doğrulama Durumu

Bir rota ROV'dan geçtiğinde üç sonuçtan birini alır:

Yani ROA oluşturmamak sizi invalid yapmaz; sadece NotFound bırakır. Asıl risk, yanlış ROA oluşturmaktır.

ROA Nasıl Oluşturulur?

Adımlar RIR'a göre görsel olarak değişir ama mantık aynıdır:

1. Kaynağın sahibi olduğunuz hesapla giriş yapın. RIPE bölgesinde LIR Portal (veya sponsor LIR'ınızın arayüzü), ARIN'de ARIN Online, APNIC'te MyAPNIC.
2. RPKI bölümüne gidin. Hosted (RIR tarafından barındırılan) RPKI'yı etkinleştirin. Çoğu kullanıcı için en kolay yol budur; sertifika yenileme işini RIR üstlenir.
3. ROA oluşturun. Prefix, origin ASN ve max-length girin.
4. Kaydı yayınlayın ve doğrulayın. Yayılım birkaç dakikadan birkaç saate kadar sürebilir, çünkü dünyadaki validator'lar kendi zamanlarında yeniler.

Örnek ROA kaydı:

Prefix:     198.51.100.0/24
Origin ASN: AS64496
Max-length: 24

IPv6 için aynı mantık geçerlidir:

Prefix:     2001:db8::/32
Origin ASN: AS64496
Max-length: 32

Birden fazla ASN'den anons yapıyorsanız (örneğin DDoS koruma sağlayıcısının ASN'i dahilse) her origin için ayrı ROA oluşturmanız gerekir. Aynı prefix için birden çok ROA tanımlamak normaldir.

Doğrulama

Yayınladıktan sonra RIPEstat API'siyle durumu sorgulayabilirsiniz:

curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64496&prefix=198.51.100.0/24" | jq '.data.status'

Çıktı "valid" olmalıdır. Ayrıca bgp.tools ve RIPEstat arayüzleri prefix bazında RPKI durumunu gösterir. Nixcon'un herkese açık looking glass aracıyla da prefix'inizin İzmir, Frankfurt ve ABD noktalarından nasıl göründüğünü kontrol edebilirsiniz.

Max-Length Hatası: En Sık Yapılan Hata

Max-length, "bu prefix'in ne kadar parçalanmış (more-specific) halini anons edebilirim" sınırıdır. Hata genellikle şöyle olur:

• ROA: 198.51.100.0/24, AS64496, max-length 24
• Siz 198.51.100.0/25 ve 198.51.100.128/25 anons edersiniz.
• /25'ler ROA ile eşleşmez, çünkü uzunluk 24'ü aşıyor. Sonuç: invalid.

Başka bir klasik senaryo: /22 bloğunuz için tek ROA açarsınız (max-length 22), sonra trafik mühendisliği veya DDoS azaltma için /24'lere bölersiniz. Tüm /24'ler invalid olur ve ROV uygulayan ağlar bunları düşürür. Not: Zaten /24'ten daha uzun prefix'ler internetin büyük bölümünde filtrelendiği için IPv4'te pratik sınır /24, IPv6'da /48'dir.

Çözüm seçenekleri

Seçenek 1 – Her /24 için ayrı ROA (önerilen):

198.51.100.0/22  AS64496  max-length 22
198.51.100.0/24  AS64496  max-length 24
198.51.101.0/24  AS64496  max-length 24
198.51.102.0/24  AS64496  max-length 24
198.51.103.0/24  AS64496  max-length 24

Seçenek 2 – Max-length'i 24'e çekmek: 198.51.100.0/22, max-length 24. Daha kolaydır ama izin alanını geniş bırakır. Birisi sizin ASN'inizi taklit ederek bu bloğun herhangi bir /24'ünü anons ederse (forged-origin) bu da valid görünür. Bu yüzden güncel pratikte (RFC 9319) minimal ROA yani sadece gerçekten anons ettiğiniz uzunlukların yetkilendirilmesi tavsiye edilir.

Diğer invalid nedenleri

• Yanlış origin ASN: Prefix'i başka bir ASN'den anons ediyorsunuz ama ROA'da yalnızca eski ASN var. Yeni bir sağlayıcı veya tünel kullanmaya başladığınızda ilgili ASN için ROA eklemeyi unutmayın.
• Süresi dolmuş veya kaldırılmış ROA: Hosted RPKI'da yenileme otomatiktir, kendi CA'nızı işletiyorsanız süreleri izleyin.
• Kaynak devri sonrası eski ROA: IP bloğu el değiştirdiğinde eski sahibin ROA'sı silinmemişse sorun çıkar. IP kiralama/satın almada bu kontrol edilmelidir.
• Taşınan blok, farklı RIR: ROA, kaynağın kayıtlı olduğu RIR'da oluşturulur.

Invalid Rotalar Neden Düşürülür?

Bir ağ ROV uyguladığında mantık basittir: kaynak sahibi "bu rotayı yalnızca şu koşullarla anons ederim" demiştir ve bu koşullara uymayan anons hatalı veya sahte olma ihtimali taşır. Reddetmek hijack'lerin yayılmasını durdurur. Büyük transit sağlayıcıların ve IX'lerin birçoğu invalid rotaları filtreler; yani ROA hatanız yalnızca teorik bir sorun değildir, gerçek erişim kaybıdır. NotFound rotalar ise genelde kabul edilir, bu yüzden "ROA yok" durumu "ROA yanlış" durumundan çok daha az risklidir.

Kendi Ağınızda ROV Uygulamak (BIRD 2)

Kendi BGP oturumlarınızda invalid rotaları reddetmek için önce bir validator çalıştırın. Örneğin Routinator'ı Docker ile (güncel TAL/ilk kurulum adımları için NLnet Labs dokümanına bakın):

docker run -d --restart unless-stopped --name routinator \
  -p 3323:3323 -p 9556:9556 nlnetlabs/routinator

Ardından BIRD 2 yapılandırması (RTR sunucusu adresi örnektir):

roa4 table r4;
roa6 table r6;

protocol rpki rpki1 {
    roa4 { table r4; };
    roa6 { table r6; };
    remote 192.0.2.10 port 3323;
    retry keep 90;
    refresh keep 900;
    expire keep 172800;
}

filter rov_in_v4 {
    if roa_check(r4, net, bgp_path.last) = ROA_INVALID then {
        print "RPKI invalid reddedildi: ", net, " AS", bgp_path.last;
        reject;
    }
    accept;
}

Filtreyi BGP protokolünüzün import bölümüne bağlayın (ipv4 { import filter rov_in_v4; };). IPv6 için r6 tablosuyla ayrı bir filtre yazın. Kontrol komutları:

birdc show protocols rpki1
birdc show route table r4 | head

Kendi prefix'inizi anonstan önce test etmek için BIRD içinde roa_check(r4, 198.51.100.0/24, 64496) ifadesini bir filtrede deneyebilirsiniz. FRRouting kullanıyorsanız aynı mantık route-map içinde match rpki invalid ile kurulur.

Hata Ayıklama Kontrol Listesi

1. Prefix ve origin ASN, ROA'daki değerlerle birebir aynı mı?
2. Anons ettiğiniz en uzun prefix, ROA max-length değerini aşıyor mu?
3. Farklı bir ASN (sağlayıcı, tünel, yedek hat) origin olarak görünüyor mu? O ASN için ROA var mı?
4. IRR route/route6 nesneleri de ROA ile tutarlı mı? (IRR kriptografik değildir ama birçok ağ prefix filtresini buradan üretir.)
5. ROA yayınlandıktan sonra yeterli süre geçti mi? Validator'lar yenilenene kadar eski durum görünebilir.
6. Looking glass ve bgp.tools'ta rota görünüyor mu, hangi durumda?

Nixcon'da ROA ve BGP

Kendi ASN'iniz ve IP bloğunuzla VDS üzerinden BGP anonsu yapacaksanız ROA'nızı önceden doğru oluşturmak kurulumu hızlandırır. Nixcon'un BGP destekli VDS hizmetinde ASN ve prefix sahipliği RPKI ROA ve resmi RIR/IRR kayıtlarıyla otomatik doğrulanır; doğrulanan ASN'iniz AS-NIXCON AS-SET'ine eklenir. Eksik veya yanlış max-length'li bir ROA bu doğrulamada da sorun çıkarır. Anonsunuzu DDoS korumalı yapmak istiyorsanız farklı bir ASN'in origin olarak görünüp görünmeyeceğini baştan netleştirip gerekli ROA'ları ekleyin.