SSU2

Durum

Dağıtım planı:

Genel Bakış

Bu öneri, SSU protokolünün çeşitli otomatik kimlik tespit yöntemlerine ve saldırılara karşı direncini artırmak için kimlik doğrulamalı anahtar anlaşma protokolünü açıklamaktadır.

Öneri şu şekilde organize edilmiştir: güvenlik hedefleri sunulur, ardından temel protokolün tartışması gelir. Sonra, tüm protokol mesajlarının eksiksiz bir spesifikasyonu verilir. Son olarak, router adresleri ve sürüm tanımlaması tartışılır.

Diğer I2P transport’ları gibi, SSU2 da I2NP mesajlarının noktadan noktaya (router’dan router’a) taşınması için tanımlanmıştır. Genel amaçlı bir veri borusu değildir. SSU gibi, iki ek hizmet daha sağlar: NAT geçişi için Relaying ve gelen erişilebilirliğin belirlenmesi için Peer Testing. Ayrıca SSU’da bulunmayan üçüncü bir hizmet olan, bir peer IP veya port değiştirdiğinde bağlantı geçişi için bir hizmet sağlar.

Motivasyon

SSU, ElGamal gerektiren tek kalan protokol katmanıdır ve bu çok yavaştır. SSU için akış kontrolü karmaşıktır ve iyi çalışmaz. SSU’nun bazı bölümleri adres sahteciliği saldırılarına karşı savunmasızdır. El sıkışma Noise kullanmaz.

Tasarım Hedefleri

• ElGamal’ı ortadan kaldırarak CPU kullanımını azaltın. DH için X25519 kullanın.

• Peer Test ve Relay fonksiyonlarını koruyun ve bunlar için güvenliği artırın.

• Standart akış kontrol algoritmalarına izin vererek uygulamayı kolaylaştırır.

• Kurulum gecikmesini azaltın. Medyan kurulum süresi şu anda NTCP2 için yaklaşık 135 ms ve SSU için 187 ms’dir, NTCP2’nin ek bir gidiş-dönüş yolculuğu olmasına rağmen; SSU2’de ElGamal’ı değiştirmek bunu azaltmalıdır, ancak diğer değişiklikler de yardımcı olabilir.

• SSU 1 ile karşılaştırıldığında maksimum iş hacmini koruyun veya artırın, bir test ağında simüle edilmiş gecikme ve paket düşürme yüzdeleri aralığında ölçüldüğü şekliyle.

• Sahte kaynak adreslerinden gelen trafik yükseltme ve yanlış yönlendirme saldırılarını “adres doğrulama” yoluyla önleyin.

• Paket tanımlamasını kolaylaştırarak, kodu aşırı karmaşık hale getiren yedek çözümlere ve buluşsal yöntemlere olan bağımlılığı azaltmak.

• Peer’ın IP’si veya portu değiştiğinde bağlantı geçişini resmileştir ve iyileştir. Saldırıları önlemek için adres doğrulaması tamamlanana kadar bağlantıları geçirme. Bazı SSU 1 uygulamaları NAT yeniden bağlanması nedeniyle port değişikliklerini işlemek için pahalı sezgisel yöntemler kullanır. Bilinen hiçbir SSU 1 uygulaması IP değişikliklerini hiç işleyemez.

• Tek bir portta SSU 1 ve 2’yi destekle, otomatik algıla ve NetDB‘de tek bir “transport” (yani RouterAddress) olarak yayınla.

• NetDB’de yalnızca sürüm 1, yalnızca sürüm 2 veya 1+2 için destek bilgisini ayrı bir alanda yayınla ve varsayılan olarak yalnızca sürüm 1’i kullan (sürüm desteğini belirli bir router sürümüne bağlama)

• Tüm implementasyonların (Java/i2pd/Go) kendi zamanlamalarına göre sürüm 2 desteği ekleyebilmesini (veya eklememesini) sağlamak

• Handshake ve veri mesajları dahil olmak üzere tüm mesajlara rastgele padding ekleyin. Tüm padding, SSU 1’deki paket sonu padding’inin aksine MAC tarafından korunmalıdır. Her iki tarafın minimum ve maksimum padding ve/veya padding dağılımı talep edebilmesi için seçenekler mekanizması sağlayın. Padding dağılımının detayları uygulama bağımlıdır ve protokolün kendisinde belirtilip belirtilmeyeceği değişkenlik gösterebilir.

• Tam olarak şifrelenmemiş mesajların başlıklarını ve içeriklerini, DPI kutuları ve AV imzalarının bunları kolayca sınıflandıramayacağı şekilde yeterince gizleyin. Ayrıca tek bir eş veya eş grubuna giden mesajların benzer bit desenlerine sahip olmadığından emin olun.

• Java formatından dolayı DH’de bit kaybını düzelt Ticket1112, ve X25519’a geçerek DH’yi hızlandır.

• DH sonucunu olduğu gibi kullanmak yerine gerçek bir anahtar türetme fonksiyonuna (KDF) geçiş yapın

• “Probing resistance” (Tor’un adlandırdığı şekilde) ekle; bu replay resistance’ı da içerir.

• 2 yönlü kimlik doğrulamalı anahtar değişimini (2W-AKE) koruyun. 1W-AKE uygulamamız için yeterli değildir.

• Kimlik doğrulamanın başka bir parçası olarak RouterInfo’da yayınlanan statik public key’e güvenin.

• Gelecekteki genişletilebilirlik için handshake’te seçenekler/sürüm ekle.

• Bağlantı kurulumu için gereken CPU’ya önemli ölçüde ekleme yapma; mümkünse, önemli ölçüde azalt.

• SSU 1’de AES şifreleme tarafından uygulanan 16 baytın katına doldurma gereksinimini kaldır.

• Şifreleme ve MAC için standart ChaCha/Poly1305 kullanın, SSU 1’de kullanılan AES şifreleme ve standart olmayan HMAC-MD5-128 MAC’i değiştirin.

• Gönderme ve alma için ayrı şifreleme anahtarları kullan, SSU 1’de her iki yön için kullanılan ortak anahtarlar yerine.

• NTCP2‘de olduğu gibi 3 mesajlı, tek gidiş-dönüş el sıkışması kullanın. SSU‘yu etkili bir şekilde iki gidiş-dönüş el sıkışması haline getiren veri mesajları için bekleme gecikmesini kaldırın.

• ACK’ler ve NACK’lerin verimliliğini önemli ölçüde artırır, ki bu SSU 1’de korkunçtur. ACK’ler ve NACK’ler için gereken bant genişliğini azaltır ve veri için kullanılabilir paket boyutunu artırır. WiFi üzerinde yaygın olan eksik mesaj patlamaları için NACK’leri verimli şekilde kodlar.

• I2NP mesaj parçalama işlemini uygulamak için gereken karmaşıklığı azaltın. Tam I2NP mesajları için parçalama mekanizmalarını ve kodlamayı atlayın.

• Dolgu öncesi protokol ek yükünü minimize edin, özellikle ACK’ler için. Dolgu eklenecek olsa da, dolgu öncesi ek yük hala ek yüktür. Düşük bant genişlikli düğümler SSU2 kullanabilmeli.

• Yeniden oynatma ve sapma tespiti için zaman damgalarını koru.

• Zaman damgalarında herhangi bir 2038 yılı sorunlarından kaçının, en az 2106 yılına kadar çalışmalı.

• Verimlilik, uygulama kolaylığı ve maksimum I2NP mesaj boyutunu artırmak için minimum MTU’yu 620’den 1280’e yükseltir. Parçalama ve yeniden birleştirme oldukça maliyetlidir. 1028 bayt tunnel mesajları için yer sağlayarak, I2NP mesajlarının büyük çoğunluğu parçalamaya gerek duymayacaktır.

• Verimlilik için maksimum MTU’yu 1488’den (IPv6 için 1484) 1500’e çıkarın. MTU’nun 16’nın katı olması gereksinimini kaldırın.

• SSU 1’de yaklaşık 32K olan maksimum I2NP mesaj boyutunu NTCP2’deki gibi yaklaşık 64 KB’ye çıkar.

• Handshake’ten IP ve port alanlarının imzasını kaldır, böylece dış IP ve portlarını bilmeyen router’lar bağlanabilsin.

• SSU 1’deki IP/port keşif mekanizmasını handshake’te koru, böylece router’lar dış IP ve port’larını öğrenebilsin.

• Tasarıma Java, C++ ve Go router geliştiricilerinin temsilcilerini dahil edin.

Non-Goals

• Kurşun geçirmez DPI direnci… bu pluggable transport’lar olacaktır, Proposal 109.

• TLS tabanlı (veya HTTPS benzeri) bir taşıma protokolü… bu Proposal 104 olurdu.

• Zamanlama tabanlı DPI direnci (mesajlar arası zamanlama/gecikmeler uygulamaya bağlı olabilir; mesaj içi gecikmeler herhangi bir noktada, örneğin rastgele dolgu gönderilmeden önce dahil olmak üzere eklenebilir). Yapay gecikmeler (obfs4’ün IAT veya varış arası süre dediği) protokolün kendisinden bağımsızdır.

• Bir oturuma katılımın inkar edilebilirliği (içinde imzalar bulunmaktadır).

Kısmen yeniden değerlendirilebilecek veya tartışılabilecek hedef-dışı konular:

• Derin Paket İncelemesi (DPI) karşı koruma derecesi

• Post-Quantum (PQ) güvenliği

• İnkar edilebilirlik

Security Goals

Üç tarafı ele alıyoruz:

• Yeni bir oturum kurmak isteyen Alice.
• Alice’in oturum kurmak istediği Bob.
• Alice ve Bob arasında “ortadaki adam” olan Mallory.

En fazla iki katılımcı aktif saldırılarda bulunabilir.

Alice ve Bob’un her ikisi de RouterIdentity’lerinde bulunan statik bir anahtar çiftine sahiptir.

Önerilen protokol, Alice ve Bob’un aşağıdaki gereksinimler altında paylaşılan bir gizli anahtar (K) üzerinde anlaşmalarına izin vermeye çalışır:

1. Özel anahtar güvenliği: ne Bob ne de Mallory, Alice’in statik özel anahtarı hakkında hiçbir şey öğrenmez. Simetrik olarak, Alice de Bob’un statik özel anahtarı hakkında hiçbir şey öğrenmez.

2. Oturum anahtarı K yalnızca Alice ve Bob tarafından bilinir.

3. Mükemmel ileri gizlilik: üzerinde anlaşılan oturum anahtarı gelecekte gizli kalır, Alice ve/veya Bob’un statik özel anahtarları anahtar üzerinde anlaşıldıktan sonra ifşa olsa bile.

4. İki yönlü kimlik doğrulama: Alice, Bob ile bir oturum kurduğundan emin olur ve Bob da aynı şekilde Alice ile oturum kurduğundan emin olur.

5. Çevrimiçi DPI’ye karşı koruma: Alice ve Bob’un protokolde yer aldığının yalnızca basit derin paket inceleme (DPI) teknikleri kullanılarak tespit edilmesinin önemsiz olmadığından emin olun. Aşağıya bakın.

6. Sınırlı inkâr edilebilirlik: ne Alice ne de Bob protokole katılımını inkâr edemez, ancak herhangi biri paylaşılan anahtarı sızdırırsa diğer taraf iletilen verinin içeriğinin gerçekliğini inkâr edebilir.

Bu önerme, Station-To-Station (STS) protokolü temelinde beş gereksinimin tamamını sağlamaya çalışmaktadır. Bu protokolün aynı zamanda SSU protokolünün de temelini oluşturduğunu unutmayın.

Additional DPI Discussion

İki DPI bileşeni varsaydık:

Online DPI

Tüm akışları gerçek zamanlı olarak inceleyen çevrimiçi DPI. Bağlantılar engellenebilir veya başka şekilde müdahale edilebilir. Bağlantı verisi veya metadata’sı tanımlanabilir ve çevrimdışı analiz için depolanabilir. Çevrimiçi DPI’nin I2P network database’ine erişimi yoktur. Çevrimiçi DPI’nin uzunluk hesaplama, alan inceleme ve XOR gibi basit hesaplamalar dahil olmak üzere yalnızca sınırlı gerçek zamanlı hesaplama yeteneği vardır. Çevrimiçi DPI ChaCha20, AEAD ve hashing gibi hızlı gerçek zamanlı kriptografik fonksiyonlara sahiptir, ancak bunları çoğu veya tüm akışlara uygulamak çok maliyetli olacaktır. Bu kriptografik işlemlerin herhangi bir uygulaması yalnızca çevrimdışı analiz tarafından önceden tanımlanmış IP/Port kombinasyonlarındaki akışlara uygulanacaktır. Çevrimiçi DPI, DH veya elligator2 gibi yüksek maliyetli kriptografik fonksiyon yeteneğine sahip değildir. Çevrimiçi DPI özellikle I2P’yi tespit etmek için tasarlanmamıştır, ancak bu amaç için sınırlı sınıflandırma kurallarına sahip olabilir.

Çevrimiçi bir DPI tarafından protokol tanımlamasını önlemek bir hedeftir.

Çevrimiçi veya “doğrudan” DPI kavramı burada aşağıdaki düşman yeteneklerini içerecek şekilde ele alınmaktadır:

1. Hedefin gönderdiği veya aldığı tüm verileri inceleme yeteneği.

2. Gözlemlenen veriler üzerinde blok şifreler veya hash fonksiyonları uygulama gibi işlemler gerçekleştirme yeteneği.

3. Daha önce gönderilen mesajları saklama ve bunlarla karşılaştırma yeteneği.

4. Paketleri değiştirme, geciktirme veya parçalara ayırma yeteneği.

Ancak, çevrimiçi DPI’nin aşağıdaki kısıtlamalara sahip olduğu varsayılmaktadır:

5. IP adreslerini router hash’lerine eşleyememe. Bu, network database’e gerçek zamanlı erişimle önemsiz olsa da, özellikle I2P’yi hedeflemek için tasarlanmış bir DPI sistemi gerektirir.

6. Protokolü tespit etmek için zamanlama bilgilerini kullanamamak.

7. Genel olarak konuşmak gerekirse, çevrimiçi DPI araç kutusu I2P tespiti için özel olarak tasarlanmış herhangi bir yerleşik araç içermez. Bu, örneğin mesajlarında rastgele olmayan dolgu içerecek olan “honeypot” oluşturmayı da kapsar. Bunun, diğer gereksinimleri karşıladıkları sürece makine öğrenmesi sistemlerini veya yüksek düzeyde yapılandırılabilir DPI araçlarını dışlamadığını unutmayın.

Payload analizi karşısında korunmak için, tüm mesajların rastgele verilerden ayırt edilemez olması sağlanır. Bu aynı zamanda uzunluklarının da rastgele olmasını gerektirir, ki bu sadece rastgele dolgu eklemekten daha karmaşıktır. Nitekim, Ek A’da yazarlar naif (yani uniform) bir dolgu şemasının sorunu çözmediğini savunmaktadır. Bu nedenle Ek A, ya rastgele gecikmeler eklemeyi ya da önerilen saldırıya karşı makul koruma sağlayabilecek alternatif bir dolgu şeması geliştirmeyi önermektedir.

Yukarıdaki altıncı maddeye karşı korunmak için, uygulamalar protokolde rastgele gecikmeler içermelidir. Bu tür teknikler bu önerinin kapsamında değildir, ancak padding uzunluğu sorunlarını da çözebilirler. Özetle, öneri payload analizine karşı iyi koruma sağlar (Ek A’daki hususlar dikkate alındığında), ancak akış analizine karşı yalnızca sınırlı koruma sunar.

Offline DPI

Çevrimdışı DPI, sonraki analiz için çevrimiçi DPI tarafından depolanan verileri incelemektedir. Çevrimdışı DPI, özellikle I2P’yi tespit etmek için tasarlanmış olabilir. Çevrimdışı DPI’nin I2P network database’ine gerçek zamanlı erişimi vardır. Çevrimdışı DPI’nin bu ve diğer I2P spesifikasyonlarına erişimi vardır. Çevrimdışı DPI, bu spesifikasyonda tanımlanan tüm kriptografik fonksiyonlar dahil olmak üzere sınırsız hesaplama yeteneğine sahiptir.

Çevrimdışı DPI, mevcut bağlantıları engelleme yeteneğine sahip değildir. Çevrimdışı DPI, paket enjeksiyonu ile tarafların host/port’larına neredeyse gerçek zamanlı (kurulumdan dakikalar içinde) gönderim yapabilme yeteneğine sahiptir. Çevrimdışı DPI, “araştırma” veya diğer nedenlerle önceki mesajların (değiştirilmiş olsun ya da olmasın) neredeyse gerçek zamanlı (kurulumdan dakikalar içinde) yeniden oynatılması yeteneğine sahiptir.

Çevrimdışı DPI tarafından protokol tanımlamasını engellemek bir hedef değildir. I2P router’ları tarafından uygulanan ilk iki mesajdaki gizlenmiş verilerin tüm kod çözme işlemleri, çevrimdışı DPI tarafından da uygulanabilir.

Önceki mesajların tekrarlanması kullanılarak yapılan bağlantı girişimlerini reddetmek bir hedeftir.

Address Validation

Aşağıdaki metin QUIC RFC 9000 belgesinden kopyalanmıştır. Her bölüm için gözden geçirin ve düzenleyin.

Adres doğrulaması, bir endpoint’in trafik amplifikasyonu saldırısı için kullanılamayacağını garanti eder. Böyle bir saldırıda, bir mağduru tanımlayan sahte kaynak adres bilgisi ile sunucuya bir paket gönderilir. Eğer sunucu bu pakete yanıt olarak daha büyük veya daha fazla paket üretirse, saldırgan sunucuyu mağdura kendi başına gönderebileceğinden daha fazla veri göndermek için kullanabilir.

Amplifikasyon saldırılarına karşı birincil savunma, bir eşin (peer) iddia ettiği transport adresinde paket alabileceğini doğrulamaktır. Bu nedenle, henüz doğrulanmamış bir adresten paket aldıktan sonra, bir endpoint doğrulanmamış adrese gönderdiği veri miktarını o adresten alınan veri miktarının üç katıyla sınırlamalıdır (MUST). Yanıt boyutundaki bu sınır, anti-amplifikasyon limiti olarak bilinir.

Adres doğrulaması hem bağlantı kurulumu sırasında (Bölüm 8.1’e bakın) hem de bağlantı taşıma işlemi sırasında (Bölüm 8.2’ye bakın) gerçekleştirilir.

Address Validation during Connection Establishment

Bağlantı kurulumu, her iki uç nokta için adres doğrulamasını örtük olarak sağlar. Özellikle, Handshake anahtarlarıyla korunan bir paketin alınması, eşin bir Initial paketini başarıyla işlediğini doğrular. Bir uç nokta, eşten gelen bir Handshake paketini başarıyla işlediğinde, eş adresinin doğrulanmış olduğunu kabul edebilir.

Ek olarak, bir endpoint, peer tarafından seçilen bir connection ID kullanılıyorsa ve connection ID en az 64 bit entropi içeriyorsa peer adresini doğrulanmış olarak kabul EDEBİLİR.

İstemci için, ilk Initial paketindeki Destination Connection ID alanının değeri, herhangi bir paketi başarıyla işlemenin bir parçası olarak sunucu adresini doğrulamasına olanak tanır. Sunucudan gelen Initial paketler, bu değerden türetilen anahtarlarla korunur (bkz. QUIC-TLS Bölüm 5.2). Alternatif olarak, bu değer sunucu tarafından Version Negotiation paketlerinde yankılanır (Bölüm 6) veya Retry paketlerindeki Integrity Tag’e dahil edilir (QUIC-TLS Bölüm 5.8).

İstemci adresini doğrulamadan önce, sunucular aldıkları bayt sayısının üç katından fazla bayt GÖNDERMEMELİDİR. Bu, sahte kaynak adresleri kullanılarak yapılabilecek herhangi bir amplifikasyon saldırısının büyüklüğünü sınırlar. Adres doğrulamadan önce amplifikasyonu önleme amacıyla, sunucular tek bir bağlantıya benzersiz şekilde atfedilen datagramlarda alınan tüm payload baytlarını sayMALIDIR. Bu, başarıyla işlenen paketler içeren datagramları ve tümü atılan paketler içeren datagramları içerir.

İstemciler, Initial paketleri içeren UDP datagramlarının en az 1200 bayt UDP yükü olduğundan emin OLMALIDIR ve gerektiğinde PADDING çerçeveleri eklemeli. Dolgulanmış datagramlar gönderen istemci, sunucunun adres doğrulama işlemini tamamlamadan önce daha fazla veri göndermesine olanak sağlar.

Sunucudan gelen bir Initial veya Handshake paketinin kaybı, istemci ek Initial veya Handshake paketleri göndermezse kilitlenmeye neden olabilir. Sunucu anti-amplifikasyon sınırına ulaştığında ve istemci gönderdiği tüm veriler için onayları aldığında kilitlenme oluşabilir. Bu durumda, istemcinin ek paket gönderme nedeni olmadığında, sunucu istemcinin adresini doğrulamadığı için daha fazla veri gönderemeyecektir. Bu kilitlenmeyi önlemek için, istemciler Probe Timeout (PTO) durumunda bir paket GÖNDERMELİDİR; QUIC-RECOVERY Bölüm 6.2’ye bakın. Özellikle, istemci Handshake anahtarlarına sahip değilse en az 1200 bayt içeren bir UDP datagramında bir Initial paketi GÖNDERMELİDİR, aksi takdirde bir Handshake paketi göndermelidir.

Bir sunucu, kriptografik el sıkışmayı başlatmadan önce istemci adresini doğrulamak isteyebilir. QUIC, el sıkışma tamamlanmadan önce adres doğrulaması sağlamak için Initial paketinde bir token kullanır. Bu token, bağlantı kurulumu sırasında bir Retry paketi (Bölüm 8.1.2’ye bakın) ile veya önceki bir bağlantıda NEW_TOKEN çerçevesi (Bölüm 8.1.3’e bakın) kullanılarak istemciye iletilir.

Adres doğrulamasından önce uygulanan gönderim sınırlarına ek olarak, sunucular aynı zamanda tıkanıklık denetleyicisi tarafından belirlenen sınırlarla neyi gönderebilecekleri konusunda da kısıtlanmıştır. İstemciler yalnızca tıkanıklık denetleyicisi tarafından kısıtlanır.

Token Construction

NEW_TOKEN frame’i veya Retry paketi içinde gönderilen bir token, sunucunun bir istemciye nasıl sağlandığını belirleyebilmesine olanak tanıyan bir şekilde oluşturulmalıdır. Bu tokenlar aynı alanda taşınır ancak sunuculardan farklı işlem gerektirir.

Address Validation Using Retry Packets

İstemcinin Initial paketini aldıktan sonra, sunucu bir token içeren Retry paketi (Bölüm 17.2.5) göndererek adres doğrulaması talep edebilir. Bu token, istemci tarafından Retry paketini aldıktan sonra o bağlantı için gönderdiği tüm Initial paketlerinde tekrarlanmak ZORUNDADIR.

Retry paketinde sağlanan bir token içeren Initial paketini işleme yanıt olarak, sunucu başka bir Retry paketi gönderemez; bağlantıyı yalnızca reddedebilir veya devam etmesine izin verebilir.

Bir saldırganın kendi adresi için geçerli bir token üretmesi mümkün olmadığı sürece (Bölüm 8.1.4’e bakın) ve istemci bu token’ı geri döndürebildiği sürece, bu durum sunucuya token’ı aldığını kanıtlar.

Bir sunucu ayrıca bağlantı kurma sürecinin durum ve işleme maliyetlerini ertelemek için bir Retry paketi kullanabilir. Sunucunun farklı bir connection ID sağlamasını gerektirmek, Bölüm 18.2’de tanımlanan original_destination_connection_id transport parametresi ile birlikte, sunucunun veya işbirliği yaptığı bir varlığın istemciden gelen orijinal Initial paketini aldığını kanıtlamasını zorlar. Farklı bir connection ID sağlamak ayrıca sunucuya sonraki paketlerin nasıl yönlendirileceği konusunda bir miktar kontrol verir. Bu, bağlantıları farklı bir sunucu örneğine yönlendirmek için kullanılabilir.

Bir sunucu, geçersiz bir Retry token içeren ancak bunun dışında geçerli olan bir istemci Initial’ı alırsa, istemcinin başka bir Retry token’ı kabul etmeyeceğini bilir. Sunucu böyle bir paketi atabilir ve el sıkışma hatasını tespit etmesi için istemcinin zaman aşımına uğramasına izin verebilir, ancak bu istemciye önemli bir gecikme cezası getirebilir. Bunun yerine, sunucu INVALID_TOKEN hatası ile bağlantıyı derhal kapatMALIDIR (Bölüm 10.2). Bu noktada sunucunun bağlantı için herhangi bir durum oluşturmadığını ve dolayısıyla kapanış dönemine girmediğini unutmayın.

Bir Retry paketi kullanımını gösteren akış Şekil 9’da gösterilmiştir.

Client                                                  Server

Initial[0]: CRYPTO[CH] ->

                                                <- Retry+Token

Initial+Token[1]: CRYPTO[CH] ->

                                 Initial[0]: CRYPTO[SH] ACK[1]
                       Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
                                 <- 1-RTT[0]: STREAM[1, "..."]

                Figure 9: Example Handshake with Retry

Address Validation for Future Connections

Bir sunucu, müşterilere bir bağlantı sırasında sonraki bir bağlantıda kullanılabilecek bir adres doğrulama belirteci sağlayabilir. Adres doğrulama, özellikle 0-RTT ile önemlidir çünkü bir sunucu potansiyel olarak 0-RTT verisine yanıt olarak müşteriye önemli miktarda veri gönderir.

Sunucu, gelecekteki bağlantıları doğrulamak için kullanılabilecek bir adres doğrulama token’ı istemciye sağlamak için NEW_TOKEN frame’ini (Bölüm 19.7) kullanır. Gelecekteki bir bağlantıda, istemci bu token’ı adres doğrulaması sağlamak için Initial paketlerine dahil eder. İstemci, bir Retry token’ı daha yeni biriyle değiştirmedikçe, gönderdiği tüm Initial paketlerde bu token’ı dahil etmek ZORUNDADIR. İstemci, gelecekteki bağlantılar için bir Retry’da sağlanan token’ı kullanmamalıdır. Sunucular, beklenen token’ı taşımayan herhangi bir Initial paketi atabilir.

Retry paketi için oluşturulan ve hemen kullanılan token’ın aksine, NEW_TOKEN frame’inde gönderilen token belirli bir süre geçtikten sonra kullanılabilir. Bu nedenle, bir token’ın son kullanma tarihi OLMALIDIR; bu, açık bir son kullanma tarihi veya son kullanma tarihini dinamik olarak hesaplamak için kullanılabilecek bir verilme zaman damgası olabilir. Bir sunucu, son kullanma tarihini saklayabilir veya token içinde şifreli bir biçimde dahil edebilir.

NEW_TOKEN ile verilen bir token, bir gözlemcinin değerleri verildiği bağlantıya bağlamasına izin verecek bilgileri İÇERMEMELİDİR. Örneğin, değerler şifrelenmediği sürece önceki bağlantı kimliğini veya adresleme bilgilerini içeremez. Bir sunucu, gönderdiği her NEW_TOKEN çerçevesinin, daha önce gönderilen NEW_TOKEN çerçevelerinin kayıplarını onarmak için gönderilen çerçeveler hariç olmak üzere, tüm istemciler arasında benzersiz olmasını SAĞLAMALIDIR. Sunucunun Retry ve NEW_TOKEN’dan gelen tokenları ayırt etmesine olanak sağlayan bilgilere sunucu dışındaki varlıklar ERİŞEBİLİR.

İki farklı bağlantıda client port numarasının aynı olması olası değildir; dolayısıyla portu doğrulamanın başarılı olması da pek olası değildir.

NEW_TOKEN çerçevesinde alınan bir token, bağlantının yetkili kabul edildiği herhangi bir sunucu için geçerlidir (örneğin, sertifikada bulunan sunucu adları). İstemci için geçerli ve kullanılmamış bir token’ın bulunduğu bir sunucuya bağlanırken, o token’ı Initial paketinin Token alanına dahil etmelidir. Bir token dahil etmek, sunucunun ek bir gidiş-dönüş olmadan istemci adresini doğrulamasına olanak sağlayabilir. Bir istemci, bağlanmakta olduğu sunucu için geçerli olmayan bir token’ı dahil etmemelidir, ancak istemci token’ı veren sunucu ile istemcinin bağlandığı sunucunun token’ları ortaklaşa yönettikleri bilgisine sahipse bu durumun istisnası vardır. Bir istemci, o sunucuyla yapılan herhangi bir önceki bağlantıdan bir token kullanabilir.

Bir token, sunucunun token’ın verildiği bağlantı ile kullanıldığı herhangi bir bağlantı arasındaki etkinliği ilişkilendirmesine olanak tanır. Bir sunucu ile kimlik sürekliliğini kırmak isteyen istemciler, NEW_TOKEN frame’i kullanılarak sağlanan token’ları atabilir. Karşılaştırma olarak, bir Retry paketinde elde edilen token bağlantı girişimi sırasında derhal kullanılMALI ve sonraki bağlantı girişimlerinde kullanılamaz.

Bir istemci, farklı bağlantı denemeleri için NEW_TOKEN çerçevesinden alınan bir token’ı yeniden kullanmamalıdır (SHOULD NOT). Token’ların yeniden kullanılması, ağ yolundaki varlıkların bağlantıları ilişkilendirmesine olanak tanır; bkz. Bölüm 9.5.

İstemciler tek bir bağlantıda birden fazla token alabilir. Bağlantı kurulabilirliğini engellemenin yanı sıra, herhangi bir token herhangi bir bağlantı girişiminde kullanılabilir. Sunucular, birden fazla bağlantı girişimi için adres doğrulamasını etkinleştirmek veya geçersiz hale gelebilecek eski tokenları değiştirmek için ek tokenlar gönderebilir. Bir istemci için bu belirsizlik, en son kullanılmamış tokenın gönderilmesinin en etkili olma ihtimalinin yüksek olduğu anlamına gelir. Eski tokenları kaydetmek ve kullanmanın olumsuz sonuçları olmasa da, istemciler eski tokenları sunucu için adres doğrulamasında daha az yararlı olma olasılığı yüksek olarak değerlendirebilir.

Bir sunucu, adres doğrulama token’ı içeren bir Initial paketi aldığında, adres doğrulamasını zaten tamamlamış olmadıkça, token’ı doğrulamaya çalışMALIDIR. Token geçersizse, sunucu potansiyel olarak bir Retry paketi göndermek dahil olmak üzere, istemcinin doğrulanmış bir adrese sahip olmadığı gibi davranMALIDIR. NEW_TOKEN frame’leri ve Retry paketleri ile sağlanan token’lar sunucular tarafından ayırt edilebilir (bkz. Bölüm 8.1.1) ve ikincisi daha katı bir şekilde doğrulanabilir. Doğrulama başarılı olursa, sunucu daha sonra handshake’in devam etmesine izin verMELIDIR.

Not: İstemciyi doğrulanmamış olarak ele alma (paketi atmak yerine) mantığı şudur: istemci, token’ı önceki bir bağlantıda NEW_TOKEN frame kullanarak almış olabilir ve sunucu durumu kaybetmişse, token’ı hiç doğrulayamayabilir, bu da paket atılırsa bağlantı hatasına yol açabilir.

Durumsuz bir tasarımda, sunucu şifrelenmiş ve kimliği doğrulanmış token’ları kullanarak istemcilere bilgi aktarabilir ve bu bilgileri daha sonra geri alarak istemci adresini doğrulamak için kullanabilir. Token’lar kriptografik handshake sürecine entegre edilmediği için kimlik doğrulamasından geçmezler. Örneğin, bir istemci bir token’ı yeniden kullanabilir. Bu özelliği istismar eden saldırıları önlemek için, sunucu token kullanımını yalnızca istemci adreslerini doğrulamak için gerekli bilgilerle sınırlayabilir.

İstemciler, bir bağlantıda elde ettikleri token’ları aynı sürümü kullanan herhangi bir bağlantı denemesi için kullanabilirler. Kullanılacak bir token seçerken, istemcilerin denenmekte olan bağlantının diğer özelliklerini göz önünde bulundurması gerekmez; buna olası uygulama protokollerinin seçimi, oturum biletleri veya diğer bağlantı özellikleri dahildir.

Address Validation Token Integrity

Bir adres doğrulama token’ı tahmin edilmesi zor olmalıdır. Token’da en az 128 bit entropi içeren rastgele bir değer dahil etmek yeterli olacaktır, ancak bu sunucunun istemcilere gönderdiği değeri hatırlamasına bağlıdır.

Token tabanlı bir şema, sunucunun doğrulama ile ilişkili herhangi bir durumu istemciye devretmesine olanak tanır. Bu tasarımın çalışması için, token’ın istemciler tarafından değiştirilme veya tahrif edilmeye karşı bütünlük koruması ile korunması GEREKİR. Bütünlük koruması olmadan, kötü niyetli istemciler sunucu tarafından kabul edilecek token değerleri üretebilir veya tahmin edebilir. Yalnızca sunucunun token’lar için bütünlük koruma anahtarına erişimi olması gerekir.

Token için tek bir iyi tanımlanmış formata ihtiyaç yoktur çünkü token’ı üreten sunucu aynı zamanda onu tüketir de. Retry paketlerinde gönderilen token’lar, sunucunun istemci paketlerindeki kaynak IP adresi ve portun sabit kaldığını doğrulamasına olanak sağlayan bilgileri İÇERMELİDİR.

NEW_TOKEN çerçevelerinde gönderilen token’lar, sunucunun token’ın verildiği zamandan itibaren istemci IP adresinin değişmediğini doğrulamasına olanak tanıyan bilgileri İÇERMEK ZORUNDADIR. Sunucular, istemci adresi değişmiş olsa bile, Retry paketi göndermeme kararında NEW_TOKEN çerçevelerinden gelen token’ları kullanabilir. Eğer istemci IP adresi değişmişse, sunucu amplifikasyon karşıtı sınıra UYMAK ZORUNDADIR; Bölüm 8’e bakınız. NAT’ın varlığında, bu gereksinimin NAT’ı paylaşan diğer host’ları amplifikasyon saldırılarından korumak için yetersiz olabileceğini unutmayın.

Saldırganlar, DDoS saldırılarında sunucuları amplifikatör olarak kullanmak için tokenları tekrar oynatabilir. Bu tür saldırılara karşı korunmak için sunucular, tokenların tekrar oynatılmasının önlendiğini veya sınırlandırıldığını ZORUNLU olarak sağlamalıdır. Sunucular, Retry paketlerinde gönderilen tokenların yalnızca kısa bir süre için kabul edilmesini SAĞLAMALILDIR, çünkü bunlar istemciler tarafından derhal geri döndürülür. NEW_TOKEN çerçevelerinde (Bölüm 19.7) sağlanan tokenların daha uzun süre geçerli olması gerekir ancak birden fazla kez kabul edilmemelidir. Sunucular, mümkünse tokenların yalnızca bir kez kullanılmasına izin vermeye teşvik edilir; tokenlar, uygulanabilirliği veya yeniden kullanımı daha da daraltmak için istemciler hakkında ek bilgi içerebilir.

Çevrimiçi DPI

Yol doğrulama, bağlantı geçişi sırasında (Bölüm 9’a bakın) her iki eş tarafından da adres değişikliği sonrasında erişilebilirliği doğrulamak için kullanılır. Yol doğrulamada, uç noktalar belirli bir yerel adres ile belirli bir eş adresi arasındaki erişilebilirliği test eder; burada adres, IP adresi ve port’un 2’li grubudur.

Path doğrulama, bir peer’a giden yolda gönderilen paketlerin o peer tarafından alındığını test eder. Path doğrulama, taşınan bir peer’dan alınan paketlerin sahte kaynak adresi taşımadığından emin olmak için kullanılır.

Yol doğrulaması, bir peer’ın dönüş yönünde gönderim yapabileceğini doğrulamaz. Onaylamalar, yetersiz entropi içerdikleri ve sahte olabilecekleri için dönüş yolu doğrulaması için kullanılamaz. Uç noktalar bir yolun her yönündeki erişilebilirliği bağımsız olarak belirler ve bu nedenle dönüş erişilebilirliği yalnızca peer tarafından kurulabilir.

Yol doğrulama, herhangi bir zamanda her iki uç nokta tarafından da kullanılabilir. Örneğin, bir uç nokta, bir süre hareketsizlik sonrasında bir eşin hala adresine sahip olup olmadığını kontrol edebilir.

Path validation, NAT geçiş mekanizması olarak tasarlanmamıştır. Burada açıklanan mekanizma NAT geçişini destekleyen NAT bağlantılarının oluşturulması için etkili olabilse de, beklenti bir endpoint’in o path üzerinde önce bir paket göndermeksizin paketleri alabilmesidir. Etkili NAT geçişi burada sağlanmayan ek senkronizasyon mekanizmalarına ihtiyaç duyar.

Bir uç nokta, yol doğrulama için kullanılan PATH_CHALLENGE ve PATH_RESPONSE çerçeveleri ile birlikte diğer çerçeveleri de içerebilir. Özellikle, bir uç nokta Yol Maksimum İletim Birimi Keşfi (PMTUD) için PATH_CHALLENGE çerçevesi ile PADDING çerçevelerini dahil edebilir; bkz. Bölüm 14.2.1. Bir uç nokta ayrıca PATH_RESPONSE çerçevesi gönderirken kendi PATH_CHALLENGE çerçevesini de dahil edebilir.

Bir uç nokta, yeni bir yerel adresten gönderilen araştırmalar için yeni bir bağlantı kimliği kullanır; bkz. Bölüm 9.5. Yeni bir yol araştırırken, bir uç nokta eşinin yanıtlar için kullanılmamış bir bağlantı kimliğine sahip olduğundan emin olabilir. Eşinin active_connection_id_limit’i izin veriyorsa, NEW_CONNECTION_ID ve PATH_CHALLENGE çerçevelerini aynı pakette göndermek, yanıt gönderirken eşe kullanılmamış bir bağlantı kimliğinin mevcut olmasını sağlar.

Bir endpoint aynı anda birden fazla yolu araştırmayı seçebilir. Araştırmalar için kullanılan eşzamanlı yol sayısı, eşinin önceden sağladığı ekstra connection ID’lerin sayısıyla sınırlıdır, çünkü bir araştırma için kullanılan her yeni yerel adres daha önce kullanılmamış bir connection ID gerektirir.

Çevrimdışı DPI

Yol doğrulamasını başlatmak için, bir endpoint doğrulanacak yol üzerinde öngörülemeyen bir payload içeren PATH_CHALLENGE frame’i gönderir.

Bir endpoint paket kaybına karşı korunmak için birden fazla PATH_CHALLENGE frame’i gönderebilir. Ancak, bir endpoint tek bir pakette birden fazla PATH_CHALLENGE frame’i göndermemelidir.

Bir uç nokta, PATH_CHALLENGE çerçevesi içeren paketlerle yeni bir yolu, bir Initial paketi göndereceğinden daha sık araştırmamalıdır (SHOULD NOT). Bu, bağlantı geçişinin yeni bir yol üzerinde yeni bir bağlantı kurmaktan daha fazla yük oluşturmamasını sağlar.

Uç nokta, eşin yanıtını ilgili PATH_CHALLENGE ile ilişkilendirebilmesi için her PATH_CHALLENGE çerçevesinde öngörülemeyen veri kullanMALIDIR.

Bir endpoint, PATH_CHALLENGE frame içeren datagramları en az 1200 bayt olan izin verilen en küçük maksimum datagram boyutuna genişletmek ZORUNDADIR, ancak yol için anti-amplifikasyon sınırı bu boyutta bir datagram gönderilmesine izin vermiyorsa bu durum hariçtir. Bu boyutta UDP datagramları göndermek, endpoint’ten eşe (peer) giden ağ yolunun QUIC için kullanılabileceğini garanti eder; Bölüm 14’e bakınız.

Bir uç nokta, anti-amplifikasyon sınırı nedeniyle datagram boyutunu 1200 bayta genişletiremediğinde, yol MTU’su doğrulanmayacaktır. Yol MTU’sunun yeterince büyük olduğundan emin olmak için, uç nokta en az 1200 bayt boyutunda bir datagram içinde PATH_CHALLENGE çerçevesi göndererek ikinci bir yol doğrulaması gerçekleştirmelidir. Bu ek doğrulama, bir PATH_RESPONSE başarıyla alındıktan sonra veya yolda daha büyük datagram gönderilmesinin anti-amplifikasyon sınırını aşmaması için yeterli bayt alındığında gerçekleştirilebilir.

Datagramların genişletildiği diğer durumların aksine, uç noktalar PATH_CHALLENGE veya PATH_RESPONSE içeren datagramları çok küçük görünse bile ASLA atmamalıdır.

Path Validation Responses

PATH_CHALLENGE frame alındığında, bir endpoint PATH_CHALLENGE frame içinde yer alan veriyi PATH_RESPONSE frame içinde yankılayarak yanıt vermek ZORUNDADIR. Bir endpoint, tıkanıklık kontrolü tarafından kısıtlanmadıkça PATH_RESPONSE frame içeren bir paketin iletimini geciktirmemelidir.

Bir PATH_RESPONSE frame’i, PATH_CHALLENGE frame’inin alındığı ağ yolu üzerinden GÖNDERİLMELİDİR. Bu, bir eş tarafından yol doğrulamasının yalnızca yol her iki yönde de işlevsel ise başarılı olmasını sağlar. Bu gereklilik, yol doğrulamasını başlatan uç nokta tarafından uygulanmamalıdır, çünkü bu migrasyon üzerinde bir saldırıyı mümkün kılardı; Bölüm 9.3.3’e bakınız.

Bir endpoint, PATH_RESPONSE frame içeren datagramları en az izin verilen minimum maksimum datagram boyutu olan 1200 byte’a genişletmek ZORUNDADIR. Bu, yolun bu boyuttaki datagramları her iki yönde de taşıyabildiğini doğrular. Ancak bir endpoint, sonuçta elde edilen veri anti-amplifikasyon sınırını aşıyorsa PATH_RESPONSE içeren datagramı genişletmemelidir. Bunun yalnızca alınan PATH_CHALLENGE’ın genişletilmiş bir datagramda gönderilmemiş olması durumunda gerçekleşmesi beklenir.

Bir endpoint, bir PATH_CHALLENGE frame’ine yanıt olarak birden fazla PATH_RESPONSE frame göndermemelidir (MUST NOT); bkz. Bölüm 13.3. Peer’in ek PATH_RESPONSE frame’lerini uyandırmak için gerektiği kadar daha fazla PATH_CHALLENGE frame göndermesi beklenir.

Bağlantı Kurulumu Sırasında Adres Doğrulama

Yol doğrulaması, daha önce bir PATH_CHALLENGE frame’inde gönderilen veriyi içeren bir PATH_RESPONSE frame’i alındığında başarılı olur. Herhangi bir ağ yolunda alınan PATH_RESPONSE frame’i, PATH_CHALLENGE’ın gönderildiği yolu doğrular.

Bir uç nokta PATH_CHALLENGE çerçevesini en az 1200 bayta genişletilmemiş bir datagram içinde gönderirse ve buna verilen yanıt eş adresini doğrularsa, yol doğrulanır ancak yol MTU’su doğrulanmaz. Sonuç olarak, uç nokta artık alınan veri miktarının üç katından fazlasını gönderebilir. Ancak, uç nokta yolun gerekli MTU’yu desteklediğini doğrulamak için genişletilmiş bir datagram ile başka bir yol doğrulaması başlatMALIDIR.

PATH_CHALLENGE frame’i içeren bir paket için onay alınması yeterli doğrulama değildir, çünkü onay kötü niyetli bir eş tarafından sahteleştirilebilir.

Token Oluşturma

Yol doğrulaması yalnızca yolu doğrulamaya çalışan uç nokta, yolu doğrulama girişimini terk ettiğinde başarısız olur.

Uç noktalar, bir zamanlayıcıya dayalı olarak path validation’ı terk ETMELİDİR. Bu zamanlayıcıyı ayarlarken, implementasyonlar yeni path’in orijinalinden daha uzun round-trip time’a sahip olabileceği konusunda dikkatli olmalıdır. Mevcut PTO veya yeni path için PTO’nun (QUIC-RECOVERY‘de tanımlandığı şekilde kInitialRtt kullanarak) büyük olanının üç katı değeri ÖNERİLİR.

Bu zaman aşımı, yol doğrulamasının başarısız olmasından önce birden fazla PTO’nun sona ermesine olanak tanır, böylece tek bir PATH_CHALLENGE veya PATH_RESPONSE çerçevesinin kaybolması yol doğrulama başarısızlığına neden olmaz.

Endpoint’in yeni yol üzerinde diğer çerçeveleri içeren paketler alabileceğini, ancak yol doğrulamasının başarılı olması için uygun veri içeren bir PATH_RESPONSE çerçevesinin gerekli olduğunu unutmayın.

Bir endpoint path validation’ı terk ettiğinde, yolun kullanılamaz olduğunu belirler. Bu mutlaka bağlantının başarısız olduğu anlamına gelmez – endpoint’ler uygun olan diğer yollar üzerinden paket göndermeye devam edebilir. Hiçbir yol mevcut değilse, bir endpoint yeni bir yolun kullanılabilir hale gelmesini bekleyebilir veya bağlantıyı kapatabilir. Peer’ına geçerli bir network path’i olmayan bir endpoint bunu NO_VIABLE_PATH connection error kullanarak sinyal verebilir, bunun yalnızca network path’in var olması ancak gerekli MTU’yu desteklememesi durumunda mümkün olduğunu not ederek (Bölüm 14).

Bir yol doğrulaması, başarısızlık dışındaki nedenlerle de terk edilebilir. Bu durum öncelikle, eski yol üzerinde devam eden bir yol doğrulaması sırasında yeni bir yola bağlantı geçişi başlatıldığında gerçekleşir.

Connection Migration

Aşağıdaki metin QUIC RFC 9000‘den kopyalanmıştır. Her bölüm için gözden geçirin ve düzenleyin.

Bir bağlantı kimliği kullanımı, bağlantıların uç nokta adreslerindeki değişiklikleri (IP adresi ve port) atlatmasını sağlar; örneğin bir uç noktanın yeni bir ağa geçmesi durumunda meydana gelen değişiklikler gibi. Bu bölüm, bir uç noktanın yeni bir adrese geçiş sürecini açıklar.

QUIC tasarımı, handshake süresince endpoint’lerin kararlı bir adres tutmasına dayanır. Bir endpoint, QUIC-TLS belgesinin 4.1.2 bölümünde tanımlandığı şekilde handshake onaylanmadan önce bağlantı migrasyonu başlatmamalıdır.

Eğer karşı taraf disable_active_migration transport parametresini gönderdiyse, bir endpoint ayrıca handshake sırasında karşı tarafın kullandığı adrese farklı bir yerel adresten paket göndermemelidir (probing paketleri dahil; bkz. Bölüm 9.1), endpoint karşı taraftan bir preferred_address transport parametresi üzerinde işlem yapmış olmadığı sürece. Eğer karşı taraf bu gereksinimi ihlal ederse, endpoint ya o yoldaki gelen paketleri Stateless Reset oluşturmadan düşürmeli ya da path validation ile devam ederek karşı tarafın migrate etmesine izin vermelidir. Stateless Reset oluşturmak veya bağlantıyı kapatmak, ağdaki üçüncü tarafların gözlemlenen trafiği taklit ederek veya başka şekilde manipüle ederek bağlantıların kapanmasına neden olmasına izin verecektir.

Peer adres değişikliklerinin hepsi kasıtlı veya aktif migrasyonlar değildir. Peer, NAT rebinding yaşayabilir: genellikle bir NAT olan middlebox’ın bir akış için yeni bir giden port veya hatta yeni bir giden IP adresi ayırması nedeniyle oluşan adres değişikliği. Bir endpoint, peer’ının adresinde herhangi bir değişiklik tespit ederse, o adresi daha önce doğrulamış olmadıkça, path validation (Bölüm 8.2) gerçekleştirmelidir.

Bir endpoint’in paket göndermek için doğrulanmış bir yolu olmadığında, bağlantı durumunu atabilir. Bağlantı geçişi yapabilen bir endpoint, bağlantı durumunu atmadan önce yeni bir yolun kullanılabilir hale gelmesini bekleyebilir.

Bu belge, Bölüm 9.6’da açıklananlar dışında, bağlantıların yeni istemci adreslerine taşınmasını sınırlar. İstemciler tüm taşıma işlemlerini başlatmaktan sorumludur. Sunucular, o adresten probing olmayan bir paket görene kadar istemci adresine probing olmayan paketler (Bölüm 9.1’e bakın) göndermez. Eğer bir istemci bilinmeyen bir sunucu adresinden paketler alırsa, istemci bu paketleri MUTLAKA atmalıdır.

Yeniden Deneme Paketleri Kullanarak Adres Doğrulama

Bir endpoint, bağlantıyı yeni yerel adrese taşımadan önce yol doğrulaması (Bölüm 8.2) kullanarak yeni yerel adresten peer erişilebilirliğini araştırabilir (MAY). Yol doğrulamasının başarısız olması, sadece yeni yolun bu bağlantı için kullanılabilir olmadığı anlamına gelir. Bir yolu doğrulayamama, geçerli alternatif yollar mevcut olmadıkça bağlantının sona ermesine neden olmaz.

PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID ve PADDING frame’leri “probing frame’ler"dir ve diğer tüm frame’ler “non-probing frame’ler"dir. Yalnızca probing frame’ler içeren bir paket “probing packet"tır ve başka herhangi bir frame içeren paket “non-probing packet"tır.

Gelecekteki Bağlantılar için Adres Doğrulama

Bir endpoint, o adresten probing olmayan frame’ler içeren paketler göndererek bağlantıyı yeni bir yerel adrese taşıyabilir.

Her endpoint, bağlantı kurulumu sırasında eş adresini doğrular. Bu nedenle, taşınan bir endpoint, eşinin mevcut adresinde almaya istekli olduğunu bilerek eşine gönderebilir. Böylece, bir endpoint önce eşinin adresini doğrulamadan yeni bir yerel adrese taşınabilir.

Yeni yolda erişilebilirlik kurmak için, bir endpoint yeni yol üzerinde yol doğrulaması (Bölüm 8.2) başlatır. Bir endpoint, bir peer yeni adresine sonraki probing olmayan frame’i gönderene kadar yol doğrulamasını erteleyebilir.

Geçiş yapılırken, yeni yol endpoint’in mevcut gönderme hızını desteklemeyebilir. Bu nedenle, endpoint tıkanıklık denetleyicisini ve RTT tahminini sıfırlar, Bölüm 9.4’te açıklandığı gibi.

Yeni yol aynı ECN yeteneğine sahip olmayabilir. Bu nedenle, uç nokta ECN yeteneğini Bölüm 13.4’te açıklandığı gibi doğrular.

Adres Doğrulama Token Bütünlüğü

Yeni bir peer adresinden probing olmayan bir frame içeren bir paket almak, peer’in o adrese taşındığını gösterir.

Alıcı göçe izin verirse, sonraki paketleri yeni peer adresine göndermek ZORUNDADIR ve doğrulama henüz devam etmiyorsa peer’ın adresin sahipliğini doğrulamak için path validation (Bölüm 8.2) başlatmak ZORUNDADIR. Alıcının peer’dan kullanılmamış bağlantı ID’leri yoksa, peer bir tane sağlayana kadar yeni yolda hiçbir şey gönderemeyecektir; Bölüm 9.5’e bakın.

Bir endpoint, paketleri gönderdiği adresi yalnızca en yüksek numaralı probing olmayan pakete yanıt olarak değiştirir. Bu, bir endpoint’in yeniden sıralanmış paketler alması durumunda eski bir peer adresine paket göndermemesini sağlar.

Bir uç nokta, doğrulanmamış bir peer adresine veri gönderebilir (MAY), ancak Bölüm 9.3.1 ve 9.3.2’de açıklanan potansiyel saldırılara karşı koruma sağlamalıdır (MUST). Bir uç nokta, o adres yakın zamanda görülmüşse bir peer adresinin doğrulamasını atlayabilir (MAY). Özellikle, bir uç nokta sahte bir migrasyon biçimi tespit ettikten sonra önceden doğrulanmış bir yola geri döndüğünde, adres doğrulamasını atlayarak kayıp tespiti ve tıkanıklık durumunu geri yüklemek saldırının performans etkisini azaltabilir.

Probing olmayan paketleri gönderdiği adresi değiştirdikten sonra, bir endpoint diğer adresler için herhangi bir yol doğrulamasını terk edebilir.

Yeni bir peer adresinden paket almak, peer’da bir NAT yeniden bağlama işleminin sonucu olabilir.

Yeni bir istemci adresini doğruladıktan sonra, sunucu istemciye yeni adres doğrulama token’ları (Bölüm 8) GÖNDERMELİDİR.

Yol Doğrulama

Bir peer’ın kaynak adresini taklit ederek bir endpoint’in isteksiz bir host’a aşırı miktarda veri göndermesine neden olması mümkündür. Endpoint, taklit yapan peer’dan önemli ölçüde daha fazla veri gönderiyorsa, bağlantı geçişi bir saldırganın bir kurbana yönelik üretebileceği veri hacmini artırmak için kullanılabilir.

Bölüm 9.3’te açıklandığı gibi, bir endpoint’in, eşinin yeni adrese sahip olduğunu doğrulamak için eş’in yeni adresini doğrulaması gerekir. Bir eş’in adresi geçerli kabul edilene kadar, endpoint o adrese gönderdiği veri miktarını sınırlar; bkz. Bölüm 8. Bu sınır olmadığında, endpoint şüphelenmeyen bir mağdura karşı hizmet reddi saldırısında kullanılma riskiyle karşı karşıya kalır.

Bir uç nokta yukarıda açıklandığı gibi bir peer adresinin doğrulamasını atlarsa, gönderme hızını sınırlaması gerekmez.

Yol Doğrulamasını Başlatma

Yol üzerindeki bir saldırgan, sahte bir adresle bir paketi kopyalayıp yönlendirerek, orijinal paketten önce gelmesini sağlayarak sahte bir bağlantı migrasyonuna neden olabilir. Sahte adresli paket, migrate olan bir bağlantıdan geliyormuş gibi görünecek ve orijinal paket duplikat olarak algılanıp atılacaktır. Sahte bir migrasyondan sonra, kaynak adresi doğrulaması başarısız olacaktır çünkü kaynak adresindeki varlık, kendisine gönderilen PATH_CHALLENGE frame’ini okumak veya yanıtlamak için gerekli kriptografik anahtarlara sahip değildir, istese bile.

Bağlantının böyle sahte bir migration nedeniyle başarısız olmasından korunmak için, bir endpoint yeni bir peer adresinin doğrulanması başarısız olduğunda son doğrulanmış peer adresini kullanmaya geri DÖNMEK zorundadır. Ek olarak, meşru peer adresinden daha yüksek paket numaralarına sahip paketlerin alınması başka bir connection migration’ı tetikleyecektir. Bu, sahte migration’ın adres doğrulamasının terk edilmesine neden olacak ve böylece saldırganın tek bir paket enjekte etmesiyle başlatılan migration’ları sınırlandıracaktır.

Bir endpoint, son doğrulanmış peer adresi hakkında hiçbir duruma sahip değilse, tüm bağlantı durumunu atarak bağlantıyı sessizce kapatMALIDIR. Bu, bağlantıdaki yeni paketlerin genel olarak işlenmesine neden olur. Örneğin, bir endpoint daha fazla gelen pakete yanıt olarak Stateless Reset gönderebilir.

Yol Doğrulama Yanıtları

Paketleri gözlemleyebilen yol-dışı bir saldırgan, gerçek paketlerin kopyalarını uç noktalara iletebilir. Kopyalanan paket gerçek paketten önce ulaşırsa, bu bir NAT yeniden bağlama olarak görünecektir. Herhangi bir gerçek paket, kopya olarak atılacaktır. Saldırgan paketleri iletmeye devam edebilirse, saldırgan üzerinden geçen bir yola geçişe neden olabilir. Bu, saldırganı yol-üstü konumuna yerleştirir ve ona sonraki tüm paketleri gözlemleme veya düşürme yeteneği verir.

Bu saldırı türü, saldırganın uç noktalar arasındaki doğrudan yol ile yaklaşık olarak aynı özelliklere sahip bir yol kullanmasına dayanır. Saldırı, nispeten az sayıda paket gönderildiğinde veya paket kaybının denenen saldırıyla aynı zamana denk geldiğinde daha güvenilirdir.

Orijinal yolda alınan ve maksimum alınan paket numarasını artıran probing olmayan bir paket, uç noktanın o yola geri dönmesine neden olacaktır. Bu yoldaki paketleri tetikleme, saldırının başarısız olma olasılığını artırır. Bu nedenle, bu saldırının hafifletilmesi paket alışverişinin tetiklenmesine dayanır.

Görünür bir migrasyon karşısında, endpoint’ler daha önce aktif olan yolu bir PATH_CHALLENGE frame kullanarak doğrulamalıdır (MUST). Bu, o yol üzerinde yeni paketlerin gönderilmesini tetikler. Yol artık kullanılabilir değilse, doğrulama girişimi zaman aşımına uğrar ve başarısız olur; yol kullanılabilir ancak artık istenmiyor ise, doğrulama başarılı olur fakat sadece o yol üzerinde probing paketlerinin gönderilmesi ile sonuçlanır.

Aktif bir yol üzerinde PATH_CHALLENGE alan bir endpoint, yanıt olarak probing olmayan bir paket gönderMELİDİR. Probing olmayan paket, bir saldırgan tarafından yapılan herhangi bir kopyadan önce ulaşırsa, bu bağlantının orijinal yola geri taşınmasıyla sonuçlanır. Başka bir yola yapılan sonraki herhangi bir taşınma, tüm bu süreci yeniden başlatır.

Bu savunma kusurludur, ancak bu ciddi bir sorun olarak görülmez. Saldırı yoluyla giden yol, orijinal yolu kullanma konusundaki çoklu girişimlere rağmen orijinal yoldan güvenilir bir şekilde daha hızlıysa, bir saldırı ile yönlendirmedeki bir iyileştirme arasında ayrım yapmak mümkün değildir.

Bir endpoint, bu tür saldırıları tespit etmeyi iyileştirmek için sezgisel yöntemler de kullanabilir. Örneğin, eski yolda yakın zamanda paketler alınmışsa NAT rebinding olasılığı düşüktür; benzer şekilde, IPv6 yollarında rebinding nadirdir. Endpoint’ler ayrıca çoğaltılmış paketleri arayabilir. Tersine, connection ID’de bir değişiklik bir saldırıdan ziyade kasıtlı bir göçü işaret etme olasılığı daha yüksektir.

Başarılı Yol Doğrulama

Yeni yolda bulunan kapasite, eski yol ile aynı olmayabilir. Eski yol üzerinde gönderilen paketler, yeni yol için tıkanıklık kontrolü veya RTT tahminine katkıda bulunmamalıdır.

Bir peer’ın yeni adresinin sahipliğini doğruladıktan sonra, peer’ın adresindeki tek değişiklik port numarası olmadığı sürece, bir endpoint yeni yol için sıkışma kontrolcüsünü ve gidiş-dönüş süresi tahmin edicisini derhal başlangıç değerlerine sıfırlamalıdır (QUIC-RECOVERY’nin Ek A.3 ve B.3’üne bakınız). Yalnızca port değişiklikleri genellikle NAT yeniden bağlama veya diğer middlebox etkinliklerinin sonucu olduğundan, endpoint bunun yerine bu durumlarda başlangıç değerlerine geri dönmek yerine sıkışma kontrol durumunu ve gidiş-dönüş tahminini koruyabilir. Eski bir yoldan korunan sıkışma kontrol durumunun önemli ölçüde farklı özelliklere sahip yeni bir yolda kullanıldığı durumlarda, sıkışma kontrolcüsü ve RTT tahmin edicisi uyum sağlayana kadar bir gönderici çok agresif şekilde iletim yapabilir. Genel olarak, uygulamaların yeni bir yolda önceki değerleri kullanırken dikkatli olmaları tavsiye edilir.

Bir uç nokta göç süreci boyunca birden fazla adresten/adrese veri ve prob gönderdiğinde, ortaya çıkan iki yolun farklı gidiş-dönüş sürelerine sahip olabileceğinden dolayı alıcıda görünür yeniden sıralama olabilir. Birden fazla yoldan paket alan bir alıcı, alınan tüm paketleri kapsayan ACK frame’lerini göndermeye devam edecektir.

Bağlantı geçişi sırasında birden fazla yol kullanılabileceği halde, tek bir tıkanıklık kontrol bağlamı ve tek bir kayıp kurtarma bağlamı (QUIC-RECOVERY‘de açıklandığı gibi) yeterli olabilir. Örneğin, bir uç nokta eski bir yolun artık gerekli olmadığı onaylanana kadar yeni bir tıkanıklık kontrol bağlamına geçişi geciktirebilir (Bölüm 9.3.3’te açıklanan durum gibi).

Bir gönderici, probe paketleri için istisna yapabilir, böylece kayıp tespitleri bağımsız olur ve tıkanıklık kontrolcüsünün gönderim hızını gereksiz yere düşürmesine neden olmaz. Bir endpoint, PATH_CHALLENGE gönderildiğinde ayrı bir zamanlayıcı ayarlayabilir ve karşılık gelen PATH_RESPONSE alınırsa bu zamanlayıcı iptal edilir. PATH_RESPONSE alınmadan önce zamanlayıcı tetiklenirse, endpoint yeni bir PATH_CHALLENGE gönderebilir ve zamanlayıcıyı daha uzun bir süre için yeniden başlatabilir. Bu zamanlayıcı QUIC-RECOVERY belgesinin 6.2.1. bölümünde açıklandığı şekilde ayarlanMALI ve daha agresif olmaMALIDIR.

Başarısız Yol Doğrulaması

Birden fazla ağ yolunda kararlı bir bağlantı ID’si kullanmak, pasif bir gözlemcinin bu yollar arasındaki aktiviteyi ilişkilendirmesine olanak sağlayacaktır. Ağlar arasında hareket eden bir endpoint, aktivitelerinin eşi dışında herhangi bir varlık tarafından ilişkilendirilmesini istemeyebilir, bu nedenle Bölüm 5.1’de tartışıldığı gibi farklı yerel adreslerden gönderim yaparken farklı bağlantı ID’leri kullanılır. Bunun etkili olması için, endpoint’lerin sağladıkları bağlantı ID’lerinin başka hiçbir varlık tarafından bağlantılandırılamayacağından emin olmaları gerekir.

Herhangi bir zamanda, uç noktalar başka bir yolda kullanılmamış bir değere sahip olan Destination Connection ID’yi değiştirerek iletebilirler.

Bir endpoint, birden fazla yerel adresten gönderim yaparken bir bağlantı kimliğini yeniden kullanmamalıdır – örneğin, Bölüm 9.2’de açıklandığı gibi bağlantı migrasyonu başlatırken veya Bölüm 9.1’de açıklandığı gibi yeni bir ağ yolunu test ederken.

Benzer şekilde, bir endpoint birden fazla hedef adrese gönderirken bir connection ID’yi yeniden kullanmamalıdır (MUST NOT). Eş kontrolü dışındaki ağ değişiklikleri nedeniyle, bir endpoint aynı Destination Connection ID alan değeriyle yeni bir kaynak adresten paketler alabilir, bu durumda aynı yerel adresten göndermeye devam ederken yeni uzak adresle mevcut connection ID’yi kullanmaya devam edebilir (MAY).

Bağlantı kimliği yeniden kullanımına ilişkin bu gereksinimler, yalnızca paket gönderimi için geçerlidir, çünkü bağlantı kimliğinde bir değişiklik olmaksızın yolda kasıtsız değişiklikler mümkündür. Örneğin, bir ağ hareketsizlik döneminden sonra, NAT yeniden bağlama, istemci göndermeye devam ettiğinde paketlerin yeni bir yolda gönderilmesine neden olabilir. Bir endpoint böyle bir olaya Bölüm 9.3’te açıklandığı gibi yanıt verir.

Her yeni ağ yolu üzerinde her iki yönde gönderilen paketler için farklı bağlantı kimliklerinin kullanılması, aynı bağlantıdan gelen paketlerin farklı ağ yolları arasında bağlantılandırılması için bağlantı kimliğinin kullanımını ortadan kaldırır. Başlık koruması, paket numaralarının etkinlikleri ilişkilendirmek için kullanılamamasını sağlar. Bu, paketlerin zamanlama ve boyut gibi diğer özelliklerinin etkinlikleri ilişkilendirmek için kullanılmasını engellemez.

Bir endpoint, sıfır uzunluklu connection ID talep etmiş bir peer ile migration başlatmamalıdır, çünkü yeni yol üzerindeki trafik eski yol üzerindeki trafikle önemsiz şekilde bağlantılı olabilir. Sunucu, sıfır uzunluklu connection ID’ye sahip paketleri doğru bağlantıyla ilişkilendirebiliyorsa, bu sunucunun paketleri ayırmak için başka bilgiler kullandığı anlamına gelir. Örneğin, bir sunucu her istemciye benzersiz bir adres sağlayabilir – örneğin, HTTP alternative services ALTSVC kullanarak. Paketlerin birden fazla ağ yolu boyunca doğru şekilde yönlendirilmesine izin verebilecek bilgiler, aynı zamanda bu yollardaki etkinliklerin peer dışındaki varlıklar tarafından da bağlantılı olmasına izin verir.

Bir istemci, hareketsizlik döneminin ardından trafik gönderirken yeni bir bağlantı ID’si, kaynak UDP portu veya IP adresine geçerek (RFC8981 bakınız) bağlanabilirliği azaltmak isteyebilir. Paketleri gönderdiği adresi aynı anda değiştirmek, sunucunun bir bağlantı migration’ı algılamasına neden olabilir. Bu, migration’ı destekleyen mekanizmaların NAT rebinding’leri veya gerçek migration’lar yaşamayan istemciler için bile çalıştırılmasını sağlar. Adres değiştirmek, bir peer’ın congestion control durumunu sıfırlamasına neden olabilir (Bölüm 9.4’e bakınız), bu nedenle adresler SADECE nadiren değiştirilmelidir.

Mevcut bağlantı ID’lerini tüketen bir endpoint, yeni yolları araştıramaz veya migration başlatamaz, ayrıca peer’ının araştırma girişimlerine veya migration denemelerine yanıt veremez. Migration’ın mümkün olduğundan ve farklı yollarda gönderilen paketlerin ilişkilendirilemeyeceğinden emin olmak için, endpoint’ler peer’lar migration yapmadan önce yeni bağlantı ID’leri sağlamalıdır (SHOULD); bkz. Bölüm 5.1.1. Bir peer’ın mevcut bağlantı ID’lerini tüketmiş olabileceği durumda, migration yapan bir endpoint, yeni ağ yolunda gönderilen tüm paketlere bir NEW_CONNECTION_ID frame’i dahil edebilir.

Server’s Preferred Address

QUIC, sunucuların bir IP adresinde bağlantıları kabul etmesine ve el sıkışmadan kısa bir süre sonra bu bağlantıları daha tercih edilen bir adrese aktarmaya çalışmasına olanak tanır. Bu, özellikle istemcilerin başlangıçta birden fazla sunucu tarafından paylaşılan bir adrese bağlandığı ancak bağlantı kararlılığını sağlamak için tek noktaya yayın (unicast) adresini kullanmayı tercih ettiği durumlarda faydalıdır. Bu bölüm, bir bağlantının tercih edilen sunucu adresine taşınması protokolünü açıklar.

Bir bağlantının bağlantı ortasında yeni bir sunucu adresine taşınması, bu belgede belirtilen QUIC sürümü tarafından desteklenmez. İstemci, o adrese bir taşıma işlemi başlatmadığı halde yeni bir sunucu adresinden paketler alırsa, istemci bu paketleri ATMALI (SHOULD).

Yeni Bir Yolun Araştırılması

Bir sunucu, TLS handshake’inde preferred_address transport parametresini dahil ederek tercih edilen bir adresi iletir.

Sunucular, istemcilerin kendi ağ bağlantılarına en uygun olanı seçmelerine olanak sağlamak için her adres ailesi (IPv4 ve IPv6) için tercih edilen bir adres iletebilirler.

Handshake onaylandıktan sonra, istemci sunucu tarafından sağlanan iki adresten birini seçmeli ve yol doğrulamasını başlatmalıdır (Bölüm 8.2’ye bakın). İstemci, preferred_address aktarım parametresinden veya NEW_CONNECTION_ID frame’inden alınan daha önce kullanılmamış aktif bağlantı ID’sini kullanarak paketler oluşturur.

Yol doğrulama başarılı olur olmaz, istemci gelecekteki tüm paketleri yeni bağlantı kimliği kullanarak yeni sunucu adresine göndermeye başlaMALI ve eski sunucu adresini kullanmayı bırakMALIDIR. Yol doğrulama başarısız olursa, istemci gelecekteki tüm paketleri sunucunun orijinal IP adresine göndermeye devam etMELIDIR.

Bağlantı Geçişini Başlatma

Tercih edilen bir adrese geçiş yapan bir istemci, geçiş yapmadan önce seçtiği adresi doğrulamalıdır; Bölüm 21.5.3’e bakın.

Bir sunucu, bir bağlantıyı kabul ettikten sonra herhangi bir zamanda tercih edilen IP adresine yönlendirilmiş bir paket alabilir. Bu paket bir PATH_CHALLENGE frame’i içeriyorsa, sunucu Bölüm 8.2’ye göre bir PATH_RESPONSE frame’i içeren bir paket gönderir. Sunucu, istemciden tercih edilen adresinde probing olmayan bir paket alana kadar ve sunucu yeni yolu doğrulayıncaya kadar orijinal adresinden probing olmayan paketler göndermelidir.

Sunucu, tercih ettiği adresinden istemciye doğru olan yol üzerinde probe yapmalıdır. Bu, bir saldırgan tarafından başlatılan sahte migration’a karşı korunmaya yardımcı olur.

Sunucu yol doğrulamasını tamamladıktan ve tercih ettiği adres üzerinde yeni en büyük paket numarasına sahip probing olmayan bir paket aldıktan sonra, sunucu probing olmayan paketleri istemciye yalnızca tercih ettiği IP adresinden göndermeye başlar. Sunucu, eski IP adresinde alınan bu bağlantı için daha yeni paketleri BIRAKMALIDIR. Sunucu, eski IP adresinde alınan gecikmeli paketleri işlemeye devam EDEBİLİR.

Bir sunucunun preferred_address transport parametresinde sağladığı adresler yalnızca sağlandıkları bağlantı için geçerlidir. Bir istemci bunları mevcut bağlantıdan devam ettirilen bağlantılar da dahil olmak üzere diğer bağlantılar için KULLANMAMALIDIR.

Bağlantı Taşımasına Yanıt Verme

Bir istemci, sunucunun tercih ettiği adrese taşınmadan önce bir bağlantı taşıması gerçekleştirmesi gerekebilir. Bu durumda, istemci hem orijinal hem de tercih edilen sunucu adresine istemcinin yeni adresinden eş zamanlı olarak yol doğrulaması gerçekleştirmelidir.

Sunucunun tercih ettiği adresin yol doğrulaması başarılı olursa, istemci orijinal adresin doğrulamasını terk ETMELİ ve sunucunun tercih ettiği adresi kullanmaya geçmelidir. Sunucunun tercih ettiği adresin yol doğrulaması başarısız olur ancak sunucunun orijinal adresinin doğrulaması başarılı olursa, istemci kendi yeni adresine geçebilir ve sunucunun orijinal adresine göndermeye devam edebilir.

Sunucunun tercih edilen adresinde alınan paketlerin, handshake sırasında istemciden gözlemlenen kaynak adresinden farklı bir kaynak adresi varsa, sunucu Bölüm 9.3.1 ve 9.3.2’de açıklanan potansiyel saldırılara karşı koruma SAĞLAMALIDIR. Kasıtlı eşzamanlı migrasyon’a ek olarak, bu durum istemcinin erişim ağının sunucunun tercih edilen adresi için farklı bir NAT binding kullanması nedeniyle de oluşabilir.

Sunucular, farklı bir adresten probe paketi aldıklarında istemcinin yeni adresine path validation başlatMALIDIR; Bölüm 8’e bakınız.

Yeni bir adrese geçiş yapan bir client, server için aynı adres ailesinden tercih edilen bir adres kullanMALIDIR.

preferred_address aktarım parametresinde sağlanan bağlantı kimliği, sağlanan adreslere özel değildir. Bu bağlantı kimliği, istemcinin göç için kullanılabilir bir bağlantı kimliğine sahip olduğundan emin olmak için sağlanır, ancak istemci bu bağlantı kimliğini herhangi bir yolda kullanabilir.

Eş Adres Sahtekarlığı

QUIC, IPv6 kullanarak veri gönderen uç noktaların, yerel API IPv6 akış etiketlerinin ayarlanmasına izin vermediği durumlar haricinde, RFC 6437 uyumlu olarak IPv6 akış etiketi uygulaması GEREKTİĞİNİ önerir.

Ne yazık ki, Java API’si IPv6 akış etiketlerinin ayarlanmasına izin vermiyor.

Hedefler Dışı

Aşağıdaki QUIC RFC 9000 belgesinden kopyalanmıştır. Her bölümü gözden geçirin ve düzenleyin.

QUIC’in amacı güvenli bir aktarım bağlantısı sağlamaktır. Bölüm 21.1 bu özelliklere genel bir bakış sunar; sonraki bölümler bilinen saldırıların ve karşı önlemlerin açıklamaları da dahil olmak üzere bu özelliklerle ilgili kısıtlamaları ve uyarıları tartışır.

Yol Üzerindeki Adres Sahteciliği

QUIC’in tam bir güvenlik analizi bu belgenin kapsamı dışındadır. Bu bölüm, uygulayıcılara yardımcı olmak ve protokol analizine rehberlik etmek amacıyla istenen güvenlik özelliklerinin gayri resmi bir açıklamasını sağlar.

QUIC, SEC-CONS bölümünde açıklanan tehdit modelini varsayar ve bu modelden kaynaklanan birçok saldırıya karşı koruma sağlar.

Bu amaçla saldırılar pasif ve aktif saldırılar olarak ikiye ayrılır. Pasif saldırganlar ağdan paketleri okuma yeteneğine sahipken, aktif saldırganlar ayrıca ağa paket yazma yeteneğine de sahiptir. Ancak pasif bir saldırı, bir bağlantıyı oluşturan paketlerin aldığı yolda yönlendirme değişikliğine veya başka bir değişikliğe neden olma yeteneğine sahip bir saldırganyı da içerebilir.

Saldırganlar ayrıca yol üzeri saldırganlar (on-path attackers) veya yol dışı saldırganlar (off-path attackers) olarak kategorize edilir. Yol üzeri saldırgan, gözlemlediği herhangi bir paketi okuyabilir, değiştirebilir veya paketin artık hedefine ulaşmaması için kaldırabilirken, yol dışı saldırgan paketleri gözlemler ancak orijinal paketin hedeflenen varış noktasına ulaşmasını engelleyemez. Her iki saldırgan türü de rastgele paketler gönderebilir. Bu tanım, SEC-CONS Bölüm 3.5’teki tanımdan farklıdır çünkü yol dışı saldırganın paketleri gözlemleme yeteneği vardır.

Handshake, korumalı paketler ve bağlantı taşıma özellikler ayrı ayrı değerlendirilir.

Yol Dışı Paket Yönlendirme

QUIC el sıkışması TLS 1.3 el sıkışmasını bünyesinde barındırır ve TLS13 belgesinin Ek E.1 bölümünde açıklanan kriptografik özellikleri miras alır. QUIC’in güvenlik özelliklerinin çoğu, TLS el sıkışmasının bu özellikleri sağlamasına bağlıdır. TLS el sıkışmasına yönelik herhangi bir saldırı QUIC’i etkileyebilir.

Oturum anahtarlarının gizliliğini veya benzersizliğini ya da katılımcı eşlerin kimlik doğrulamasını tehlikeye atan TLS el sıkışması üzerindeki herhangi bir saldırı, bu anahtarlara bağlı olan QUIC tarafından sağlanan diğer güvenlik garantilerini etkiler. Örneğin, migrasyon (Bölüm 9) hem TLS el sıkışması kullanarak anahtar müzakeresinde hem de QUIC paket korumasında gizlilik korumalarının etkinliğine bağlıdır ve bu sayede ağ yolları arasında bağlantı kurulabilirliğini önler.

TLS el sıkışması bütünlüğüne yönelik bir saldırı, saldırganın uygulama protokolü veya QUIC sürümü seçimini etkilemesine olanak sağlayabilir.

TLS tarafından sağlanan özelliklere ek olarak, QUIC handshake’i, handshake üzerindeki DoS saldırılarına karşı bir miktar savunma sağlar.

Kayıp Algılama ve Tıkanıklık Kontrolü

Adres doğrulaması (Bölüm 8), belirli bir adresi talep eden bir varlığın o adreste paket alabildiğini doğrulamak için kullanılır. Adres doğrulaması, amplifikasyon saldırısı hedeflerini saldırganın paketleri gözlemleyebildiği adreslerle sınırlar.

Adres doğrulamasından önce, uç noktaların gönderebilecekleri sınırlıdır. Uç noktalar, doğrulanmamış bir adrese o adresten alınan verinin üç katını aşan veri gönderemez.

Not: Anti-amplification sınırı yalnızca bir endpoint doğrulanmamış bir adresten alınan paketlere yanıt verdiğinde uygulanır. Anti-amplification sınırı, yeni bir bağlantı kurarken veya bağlantı migration başlatırken istemciler için uygulanmaz.

Bağlantı Geçişinin Gizlilik Etkileri

Tam bir handshake için sunucunun ilk flight’ını hesaplamak potansiyel olarak pahalıdır ve hem imza hem de anahtar değişimi hesaplaması gerektirir. Hesaplamsal DoS saldırılarını önlemek amacıyla, Retry paketi sunucuların herhangi bir pahalı hesaplama yapmadan önce istemcinin IP adresini tek bir round trip maliyetiyle doğrulamasına olanak sağlayan ucuz bir token değişim mekanizması sağlar. Başarılı bir handshake’ten sonra, sunucular istemciye yeni tokenlar verebilir ve bu da bu maliyete katlanmadan yeni bağlantı kurulumuna izin verecektir.

Sunucunun Tercih Edilen Adresi

Yol üzerindeki veya yol dışındaki bir saldırgan, Initial paketlerini değiştirerek veya yarışa sokarak handshake’in başarısız olmasına neden olabilir. Geçerli Initial paketleri değiştokene sonra, sonraki Handshake paketleri Handshake anahtarları ile korunur ve yol üzerindeki bir saldırgan, uç noktaların girişimi terk etmesine neden olmak için paketleri düşürmek dışında handshake başarısızlığına zorla neden olamaz.

Yol üzerindeki bir saldırgan, paketlerin her iki tarafındaki adresleri de değiştirebilir ve bu nedenle istemci veya sunucunun uzak adresler hakkında yanlış bir görüşe sahip olmasına neden olabilir. Böyle bir saldırı, bir NAT tarafından gerçekleştirilen işlevlerden ayırt edilemez.

Tercih Edilen Adresin İletilmesi

Tüm el sıkışma süreci kriptografik olarak korunur; Initial paketleri sürüme özgü anahtarlarla şifrelenir ve Handshake ile sonraki paketler TLS anahtar değişiminden türetilen anahtarlarla şifrelenir. Ayrıca, parametre müzakeresi TLS transkriptine dahil edilir ve böylece sıradan TLS müzakeresindekiyle aynı bütünlük garantilerini sağlar. Bir saldırgan istemcinin taşıma parametrelerini gözlemleyebilir (sürüme özgü salt değerini bildiği sürece) ancak sunucunun taşıma parametrelerini gözlemleyemez ve parametre müzakeresini etkileyemez.

Bağlantı ID’leri tüm paketlerde şifrelenmemiş ancak bütünlük korumalıdır.

Bu QUIC sürümü bir sürüm müzakere mekanizması içermez; uyumsuz sürümlerin uygulamaları basitçe bağlantı kurmada başarısız olacaktır.

Tercih Edilen Adrese Geçiş

Paket koruması (Bölüm 12.1), Versiyon Müzakeresi paketleri hariç tüm paketlere kimlik doğrulamalı şifreleme uygular, ancak Initial ve Retry paketleri versiyona özgü anahtar materyali kullanımı nedeniyle sınırlı korumaya sahiptir; daha fazla ayrıntı için QUIC-TLS bölümüne bakın. Bu bölüm, korumalı paketlere karşı pasif ve aktif saldırıları ele almaktadır.

Hem yol üzerindeki hem de yol dışındaki saldırganlar, gözlemledikleri paketleri gelecekte paket korumasına karşı çevrimdışı bir saldırı için saklayarak pasif saldırı düzenleyebilirler; bu durum herhangi bir ağdaki herhangi bir paketin herhangi bir gözlemcisi için geçerlidir.

Bir bağlantı için geçerli paketleri gözlemleyemeden paket enjekte eden bir saldırgan başarılı olma olasılığı düşüktür, çünkü paket koruması geçerli paketlerin yalnızca handshake sırasında oluşturulan anahtar materyaline sahip olan uç noktalar tarafından üretilmesini sağlar; bkz. Bölüm 7 ve 21.1.1. Benzer şekilde, paketleri gözlemleyen ve bu paketlere yeni veri eklemeye veya mevcut veriyi değiştirmeye çalışan herhangi bir aktif saldırgan, Initial paketler dışında, alıcı uç nokta tarafından geçerli kabul edilen paketler üretememelidir.

Aktif bir saldırganın ilettiği veya enjekte ettiği bir paketin korumasız kısımlarını (kaynak veya hedef adres gibi) yeniden yazdığı bir spoofing saldırısı, yalnızca saldırgan paketleri orijinal uç noktaya iletebiliyorsa etkilidir. Paket koruması, paket yüklerinin yalnızca el sıkışmayı tamamlayan uç noktalar tarafından işlenebilmesini sağlar ve geçersiz paketler bu uç noktalar tarafından göz ardı edilir.

Bir saldırgan ayrıca paketler ve UDP datagramları arasındaki sınırları değiştirerek, birden fazla paketin tek bir datagram içinde birleştirilmesine veya birleştirilmiş paketlerin birden fazla datagram’a bölünmesine neden olabilir. Dolgu gerektiren Initial paketleri içeren datagramlar dışında, paketlerin datagramlarda nasıl düzenlendiğinin değiştirilmesi bir bağlantı üzerinde işlevsel bir etkiye sahip değildir, ancak bazı performans özelliklerini değiştirebilir.

İstemci Göçü ve Tercih Edilen Adres Etkileşimi

Bağlantı geçişi (Bölüm 9), uç noktalara birden fazla yol üzerinde IP adresleri ve portlar arasında geçiş yapma yetisi sağlar ve aynı anda sadece bir yolu araştırma dışı çerçevelerin iletimi ve alımı için kullanır. Yol doğrulama (Bölüm 8.2), bir eşin belirli bir yol üzerinde gönderilen paketleri hem almaya istekli hem de muktedir olduğunu tesis eder. Bu, sahte bir adrese gönderilen paket sayısını sınırlayarak adres sahteciliğinin etkilerini azaltmaya yardımcı olur.

Bu bölüm, çeşitli DoS saldırı türleri altında bağlantı geçişinin (connection migration) amaçlanan güvenlik özelliklerini açıklamaktadır.

IPv6 Flow Label Kullanımı ve Geçiş

Gözlemlediği bir paketin artık hedeflenen varış noktasına ulaşmasını engelleyebilen bir saldırgan, yol üzerinde saldırgan (on-path attacker) olarak kabul edilir. Bir saldırgan bir istemci ve sunucu arasında bulunduğunda, uç noktalar belirli bir yolda bağlantı kurmak için paketleri saldırgan üzerinden göndermek zorundadır.

Yol üzerindeki bir saldırgan şunları yapabilir:

• Paketleri incele

• IP ve UDP paket başlıklarını değiştir

• Yeni paketler enjekte et

• Paketleri geciktir

• Paketleri yeniden sırala

• Paketleri düşür

• Paket sınırları boyunca datagramları böl ve birleştir

Yol üzerindeki bir saldırgan şunları yapamaz:

• Bir paketin kimlik doğrulamalı kısmını değiştirip alıcının o paketi kabul etmesine neden olmak

Yol üzerindeki bir saldırgan gözlemlediği paketleri değiştirme fırsatına sahiptir; ancak, bir paketin kimlik doğrulaması yapılan kısmındaki herhangi bir değişiklik, paket yüklerinin hem kimlik doğrulaması yapıldığı hem de şifrelendiği için, alıcı uç nokta tarafından geçersiz olarak değerlendirilip bırakılmasına neden olacaktır.

QUIC, yol üzerindeki saldırganın yeteneklerini aşağıdaki şekilde sınırlamayı amaçlar:

1. Yol üzerindeki bir saldırgan, bir bağlantı için bir yolun kullanımını engelleyebilir ve saldırganı içermeyen farklı bir yol kullanamıyorsa bağlantının başarısız olmasına neden olabilir. Bu, tüm paketleri düşürerek, şifre çözme işleminin başarısız olması için bunları değiştirerek veya diğer yöntemlerle gerçekleştirilebilir.

2. Yol üzerinde bulunan bir saldırgan, yeni yol üzerinde de bulunduğu durumda, yeni yolda yol doğrulamasının başarısız olmasına neden olarak yeni bir yola geçişi engelleyebilir.

3. Yol üzerindeki bir saldırgan, istemcinin saldırganın yol üzerinde olmadığı bir yola geçmesini engelleyemez.

4. Yol üzerindeki bir saldırgan, paketleri geciktirerek veya düşürerek bir bağlantının throughput’unu azaltabilir.

5. Yol üzerindeki bir saldırgan, bir uç noktanın, o paketin kimliği doğrulanmış kısmını değiştirdiği bir paketi kabul etmesine neden olamaz.

Off-Path Active Attacks

Yol dışı saldırgan, istemci ve sunucu arasındaki yolda doğrudan bulunmayan ancak istemci ve sunucu arasında gönderilen paketlerin bir kısmının veya tamamının kopyalarını elde edebilen saldırgandır. Ayrıca bu paketlerin kopyalarını her iki uç noktaya da gönderebilir.

Yol dışı bir saldırgan şunları yapabilir:

• Paketleri incele

• Yeni paketler enjekte et

• Enjekte edilen paketleri yeniden sırala

Yol dışı bir saldırgan şunları yapamaz:

• Uç noktalar tarafından gönderilen paketleri değiştir

• Paketleri geciktir

• Paketleri bırak

• Orijinal paketleri yeniden sırala

Yol dışı bir saldırgan, gözlemlediği paketlerin değiştirilmiş kopyalarını oluşturabilir ve bu kopyaları ağa enjekte edebilir, potansiyel olarak sahte kaynak ve hedef adresleriyle birlikte.

Bu tartışmanın amaçları doğrultusunda, yol-dışı (off-path) saldırganın, ağa değiştirilmiş bir paket kopyası enjekte etme ve bu paketin hedef endpoint’e saldırganın gözlemlediği orijinal paketten önce ulaşma kabiliyetine sahip olduğu varsayılmaktadır. Başka bir deyişle, saldırgan endpoint’ler arasında meşru paketlerle tutarlı bir şekilde “yarışı kazanma” kabiliyetine sahiptir ve bu da orijinal paketin alıcı tarafından görmezden gelinmesine neden olabilir.

Ayrıca bir saldırganın NAT durumunu etkilemek için gerekli kaynaklara sahip olduğu varsayılmaktadır. Özellikle, bir saldırgan bir uç noktanın NAT bağlamasını kaybetmesine neden olabilir ve ardından aynı portu kendi trafiği ile kullanmak üzere elde edebilir.

QUIC, yol dışı bir saldırganın yeteneklerini aşağıdaki şekilde sınırlamayı amaçlar:

1. Yol-dışı bir saldırgan paketleri yarıştırabilir ve “sınırlı” yol-üstü saldırgan olmaya çalışabilir.

2. Yol dışı bir saldırgan, kaynak adresi yol dışı saldırgan olarak listelenen iletilen paketler için yol doğrulamasının başarılı olmasına neden olabilir, ancak bu yalnızca istemci ve sunucu arasında geliştirilmiş bağlantı sağlayabildiği sürece mümkündür.

3. Handshake tamamlandıktan sonra, yol dışı bir saldırgan bağlantının kapanmasına neden olamaz.

4. Yeni yolu gözlemleyemeyen yol dışı bir saldırgan, yeni bir yola geçişin başarısız olmasına neden olamaz.

5. Yol-dışı bir saldırgan, kendisinin aynı zamanda yol-dışı saldırgan olduğu yeni bir yola geçiş sırasında sınırlı bir yol-üzerinde saldırgan haline gelebilir.

6. Yol-dışı bir saldırgan, istemcinin başlangıçta kullandığı IP adresi ve port ile aynı IP adresi ve porttan sunucuya paketler göndermesi için paylaşılan NAT durumunu etkileyerek sınırlı bir yol-üzeri saldırgan haline gelebilir.

Güvenlik Özelliklerine Genel Bakış

Sınırlı yol üzerindeki saldırgan (limited on-path attacker), sunucu ve istemci arasındaki orijinal paketleri kopyalayıp ileterek paket yönlendirmesini iyileştirme teklifi sunan ve bu paketlerin orijinal kopyalardan önce varmasına neden olarak hedef uç noktasının orijinal paketleri düşürmesine yol açan, yol dışındaki bir saldırgandır (off-path attacker).

Sınırlı yol-üzerinde saldırgan, uç noktalar arasındaki orijinal yol üzerinde bulunmaması açısından yol-üzerinde saldırgandan farklıdır ve bu nedenle bir uç nokta tarafından gönderilen orijinal paketler hâlâ hedeflerine ulaşmaktadır. Bu, gelecekte kopyalanan paketleri orijinal yollarından daha hızlı hedefe yönlendirmedeki başarısızlığın, orijinal paketlerin hedefe ulaşmasını engellemeyeceği anlamına gelir.

Sınırlı yol üzerinde saldırgan şunları yapabilir:

• Paketleri incele

• Yeni paketler enjekte et

• Şifrelenmemiş paket başlıklarını değiştirme

• Paketleri yeniden sırala

Sınırlı yol üzerindeki saldırgan şunları yapamaz:

• Paketleri geciktirerek orijinal yolda gönderilen paketlerden daha geç ulaşmalarını sağla

• Paketleri bırak

• Bir paketin kimlik doğrulaması yapılmış ve şifrelenmiş kısmını değiştirerek alıcının o paketi kabul etmesine neden olmak

Sınırlı yol-üstü saldırgan, paketleri yalnızca orijinal paketlerin kopya paketlerden önce ulaştığı noktaya kadar geciktirebilir, bu da orijinal yoldan daha kötü gecikme sunan yönlendirme sağlayamayacağı anlamına gelir. Sınırlı yol-üstü saldırgan paketleri düşürürse, orijinal kopya yine de hedef uç noktaya ulaşacaktır.

QUIC, sınırlı off-path saldırganın yeteneklerini aşağıdaki şekilde kısıtlamayı amaçlar:

1. Sınırlı bir yol-üzerinde saldırgan, el sıkışma tamamlandıktan sonra bir bağlantının kapanmasına neden olamaz.

2. Sınırlı bir yol üzerindeki saldırgan, istemci etkinliğe ilk olarak devam ederse, boşta olan bir bağlantının kapanmasına neden olamaz.

3. Sınırlı yol üzerindeki saldırgan, sunucu etkinliği ilk olarak yeniden başlatan taraf ise, boşta olan bir bağlantının kaybolmuş olarak değerlendirilmesine neden olabilir.

Bu garantilerin, aynı nedenlerle herhangi bir NAT için sağlanan garantilerle aynı olduğunu unutmayın.

El Sıkışma

Şifreli ve kimlik doğrulamalı bir aktarım protokolü olarak QUIC, hizmet reddi saldırılarına karşı bir dizi koruma sağlar. Kriptografik el sıkışma tamamlandıktan sonra, QUIC uç noktaları kimlik doğrulaması yapılmamış paketlerin çoğunu atar ve saldırganın mevcut bağlantılara müdahale etme kabiliyetini büyük ölçüde sınırlar.

Bir bağlantı kurulduktan sonra, QUIC uç noktaları bazı kimlik doğrulaması yapılmamış ICMP paketlerini kabul edebilir (Bölüm 14.2.1’e bakın), ancak bu paketlerin kullanımı son derece sınırlıdır. Bir uç noktanın kabul edebileceği diğer tek paket türü, kullanılana kadar token’ın gizli tutulmasına dayanan durumsuz sıfırlama (Bölüm 10.3) paketidir.

Bir bağlantının oluşturulması sırasında, QUIC yalnızca ağ yolu dışından gelen saldırılara karşı koruma sağlar. Tüm QUIC paketleri, alıcının eşinden önceki bir paketi gördüğüne dair kanıt içerir.

Adresler handshake sırasında değişemez, bu nedenle endpoint’ler farklı bir ağ yolunda alınan paketleri atabilir.

Source ve Destination Connection ID alanları, handshake sırasında off-path saldırılara karşı birincil koruma yöntemidir; bkz. Bölüm 8.1. Bunların bir peer tarafından belirlenenlerle eşleşmesi gerekir. Initial ve Stateless Reset’ler dışında, bir endpoint yalnızca endpoint’in daha önce seçtiği bir değerle eşleşen Destination Connection ID alanı içeren paketleri kabul eder. Bu, Version Negotiation paketleri için sunulan tek korumadır.

Initial paketindeki Destination Connection ID alanı, istemci tarafından tahmin edilemez olacak şekilde seçilir ve bu ek bir amaca hizmet eder. Kriptografik el sıkışmayı taşıyan paketler, bu bağlantı kimliğinden ve QUIC sürümüne özgü bir tuzdan türetilen bir anahtar ile korunur. Bu, uç noktaların aldıkları paketleri doğrulamak için kriptografik el sıkışma tamamlandıktan sonra kullandıkları işlemle aynı süreci kullanmalarına olanak tanır. Doğrulanamayan paketler atılır. Paketleri bu şekilde korumak, paketin göndereninin Initial paketi gördüğü ve anladığına dair güçlü bir güvence sağlar.

Bu korumalar, bağlantı kurulmadan önce QUIC paketlerini alabilen bir saldırganın etkisine karşı etkili olması amaçlanmamıştır. Böyle bir saldırgan, QUIC uç noktaları tarafından kabul edilecek paketleri potansiyel olarak gönderebilir. QUIC’in bu sürümü bu tür saldırıları tespit etmeye çalışır, ancak uç noktaların kurtarma yerine bağlantı kurmakta başarısız olmasını bekler. Çoğunlukla, kriptografik handshake protokolü QUIC-TLS handshake sırasındaki tahrifatı tespit etmekten sorumludur.

Endpoint’ler, el sıkışma ile müdahaleyi tespit etmek ve bundan kurtulmaya çalışmak için başka yöntemler kullanmasına izin verilir. Geçersiz paketler başka yöntemler kullanılarak tanımlanabilir ve atılabilir, ancak bu belgede belirli bir yöntem zorunlu kılınmamıştır.

Amplifikasyon Karşıtı

Bir saldırgan bir sunucudan adres doğrulama token’ı (Bölüm 8) alabilir ve ardından bu token’ı almak için kullandığı IP adresini bırakabilir. Daha sonra, saldırgan aynı adresi taklit ederek sunucu ile 0-RTT bağlantısı başlatabilir; bu adres artık farklı bir (kurban) uç noktasını adresliyor olabilir. Böylece saldırgan, sunucunun bir başlangıç tıkanıklık penceresi değerinde veriyi kurbana göndermesine neden olabilir.

Sunucular bu saldırıya karşı adres doğrulama token’larının kullanımını ve yaşam süresini sınırlayarak önlemler SAĞLAMALIDIR; Bölüm 8.1.3’e bakın.

Sunucu Tarafı DoS

Almadığı paketleri onaylayan bir uç nokta, tıkanıklık denetleyicisinin ağın desteklediğinin ötesindeki hızlarda gönderim yapmasına izin vermesine neden olabilir. Bir uç nokta, bu davranışı tespit etmek için paket gönderirken paket numaralarını atlayabilir (MAY). Uç nokta daha sonra PROTOCOL_VIOLATION tipinde bir bağlantı hatası ile bağlantıyı derhal kapatabilir; Bölüm 10.2’ye bakınız.

Yol Üzerinde Handshake Sonlandırma

Bir istek sahtekarlığı saldırısı, bir uç noktanın eşinin bir mağdura doğru bir istek göndermesine neden olduğu ve bu isteğin uç nokta tarafından kontrol edildiği durumlarda meydana gelir. İstek sahtekarlığı saldırıları, saldırgana eşinin aksi takdirde saldırgan için erişilemez olabilecek yeteneklerine erişim sağlamayı amaçlar. Bir ağ protokolü için, istek sahtekarlığı saldırısı genellikle mağdur tarafından eşe verilen ve eşin ağdaki konumu nedeniyle oluşan herhangi bir örtülü yetkilendirmeyi istismar etmek için kullanılır.

İstek sahteciliğinin etkili olması için, bir saldırganın peer’ın hangi paketleri gönderdiğini ve bu paketlerin nereye gönderildiğini etkileyebilmesi gerekir. Eğer bir saldırgan kontrollü bir payload ile savunmasız bir servisi hedefleyebilirse, o servis saldırganın peer’ına atfedilen ancak saldırgan tarafından belirlenen eylemleri gerçekleştirebilir.

Örneğin, Web’deki cross-site request forgery CSRF saldırıları, bir istemcinin yetkilendirme çerezlerini COOKIE içeren istekler göndermesine neden olarak, bir sitenin farklı bir siteye kısıtlanması amaçlanan bilgilere ve eylemlere erişmesine izin verir.

QUIC, UDP üzerinde çalıştığından, birincil endişe kaynağı olan saldırı yöntemi, bir saldırganın eşinin UDP datagramlarını gönderdiği adresi seçebileceği ve bu paketlerin korunmamış içeriğinin bir kısmını kontrol edebileceği durumdur. QUIC uç noktaları tarafından gönderilen verilerin çoğu korunduğu için, bu şifrelenmiş metin üzerinde kontrolü de içerir. Bir saldırı, eğer saldırgan bir eşinin datagramdaki içeriğe dayanarak bazı eylemler gerçekleştirecek bir ana bilgisayara UDP datagramı göndermesine neden olabilirse başarılıdır.

Bu bölüm, QUIC’in istek sahteciliği saldırıları için kullanılabileceği yolları ele alır.

Bu bölüm ayrıca QUIC uç noktaları tarafından uygulanabilecek sınırlı karşı önlemleri de açıklar. Bu azaltma tedbirleri, istek sahteciliği saldırıları için potansiyel hedeflerin harekete geçmesi gerekmeksizin, bir QUIC uygulaması veya dağıtımı tarafından tek taraflı olarak kullanılabilir. Ancak, UDP tabanlı hizmetler istekleri düzgün bir şekilde yetkilendirmezse bu karşı önlemler yetersiz kalabilir.

Bölüm 21.5.4’te açıklanan geçiş saldırısı oldukça güçlü olduğu ve yeterli karşı önlemlere sahip olmadığı için, QUIC sunucu uygulamaları saldırganların onları keyfi hedeflere keyfi UDP yükleri oluşturmaya zorlayabileceğini varsaymalıdır. QUIC sunucuları giriş filtreleme BCP38 uygulamayan ve ayrıca yetersiz güvenlikli UDP uç noktalarına sahip ağlarda konuşlandırılmamalıdır.

İstemcilerin savunmasız uç noktalarla aynı konumda bulunmamasını sağlamanın genel olarak mümkün olmamasına rağmen, QUIC’in bu sürümü sunucuların migrate edilmesine izin vermez, böylece istemcilere yönelik sahte migration saldırılarını önler. Sunucu migration’ına izin veren gelecekteki herhangi bir uzantı AYRICA sahtecilik saldırılarına karşı önlemleri tanımlamalıdır.

Parametre Müzakeresi

QUIC, bir saldırganın eşinin UDP datagramlarını nereye göndereceğini etkileme veya kontrol etme konusunda bazı fırsatlar sunar:

• ilk bağlantı kurulumu (Bölüm 7), burada bir sunucu istemcinin datagramları nereye göndereceğini seçebilir – örneğin, DNS kayıtlarını doldurarak;

• tercih edilen adresler (Bölüm 9.6), burada bir sunucu istemcinin datagramları nereye göndereceğini seçebilir;

• sahte bağlantı geçişleri (Bölüm 9.3.1), burada bir istemci sunucunun sonraki datagramları nereye göndereceğini seçmek için kaynak adres sahteciliği kullanabilir; ve

• sunucunun bir Version Negotiation paketi göndermesine neden olan sahte paketler (Bölüm 21.5.5).

Her durumda, saldırgan eşinin QUIC’i anlamayabilecek bir mağdura datagram göndermesine neden olabilir. Yani, bu paketler adres doğrulamasından önce eş tarafından gönderilir; Bölüm 8’e bakın.

Paketlerin şifrelenmiş kısmının dışında, QUIC bir endpoint’e, eşinin gönderdiği UDP datagramlarının içeriğini kontrol etmek için çeşitli seçenekler sunar. Destination Connection ID alanı, eşi tarafından gönderilen paketlerde erken görünen baytlar üzerinde doğrudan kontrol sağlar; bkz. Bölüm 5.1. Initial paketlerdeki Token alanı, bir sunucuya Initial paketlerin diğer baytları üzerinde kontrol imkanı sunar; bkz. Bölüm 17.2.2.

QUIC’in bu sürümünde paketlerin şifrelenmiş bölümleri üzerinde dolaylı kontrolü önleyici herhangi bir önlem bulunmamaktadır. Uç noktaların, özellikle STREAM frame’leri gibi uygulama verilerini taşıyan frame’ler olmak üzere, bir eşin gönderdiği frame’lerin içeriklerini kontrol edebildiğini varsaymak gereklidir. Bu bir dereceye kadar uygulama protokolünün ayrıntılarına bağlı olsa da, birçok protokol kullanım bağlamında bir miktar kontrol mümkündür. Saldırganın paket koruma anahtarlarına erişimi olduğu için, muhtemelen bir eşin gelecekteki paketleri nasıl şifreleyeceğini tahmin edebilme yetisine sahip olacaklardır. Datagram içeriği üzerinde başarılı kontrol, daha sonra yalnızca saldırganın paket numarasını ve frame’lerin paketlerdeki yerleşimini belirli bir güvenilirlik miktarıyla tahmin edebilmesini gerektirir.

Bu bölüm, datagram içeriği üzerinde sınırlayıcı kontrolün uygulanabilir olmadığını varsayar. Sonraki bölümlerdeki risk azaltma önlemlerinin odak noktası, adres doğrulamasından önce gönderilen datagramların istek sahtekarlığı için kullanılma yollarını sınırlamaktır.

Korumalı Paketler

Sunucu olarak hareket eden bir saldırgan, kullanılabilirliğini duyurduğu IP adresini ve portunu seçebilir, bu nedenle istemcilerden gelen Initial paketlerin bu tür saldırılarda kullanılabilir olduğu varsayılır. Handshake sürecinde bulunan adres doğrulaması, yeni bir bağlantı için istemcinin QUIC’i anlamayan veya QUIC bağlantısını kabul etmeye istekli olmayan bir hedefe diğer türdeki paketleri göndermeyeceğini garanti eder.

İlk paket koruma (QUIC-TLS’nin 5.2. bölümü), sunucuların istemciler tarafından gönderilen Initial paketlerinin içeriğini kontrol etmesini zorlaştırır. Öngörülemeyen bir Destination Connection ID seçen bir istemci, sunucuların istemcilerden gelen Initial paketlerinin şifrelenmiş kısmının hiçbirini kontrol edememesini sağlar.

Ancak, Token alanı sunucu kontrolüne açıktır ve bir sunucunun istemcileri kullanarak istek sahteciliği saldırıları düzenlemesine izin verir. NEW_TOKEN çerçevesi (Bölüm 8.1.3) ile sağlanan token’ların kullanımı, bağlantı kurulumu sırasında istek sahteciliği için tek seçeneği sunar.

Ancak istemciler, NEW_TOKEN frame’ini kullanmakla yükümlü değildir. Token alanına dayanan istek sahteciliği saldırıları, NEW_TOKEN frame’i alındığında sunucu adresi değişmişse istemcilerin boş bir Token alanı göndermesiyle önlenebilir.

Sunucu adresi değişirse istemciler NEW_TOKEN kullanmaktan kaçınabilir. Ancak, Token alanının dahil edilmemesi performansı olumsuz etkileyebilir. Sunucular, veri gönderme konusundaki üç kat sınırının aşılmasına olanak sağlamak için NEW_TOKEN’a güvenebilir; bkz. Bölüm 8.1. Özellikle, bu durum istemcilerin sunuculardan veri talep etmek için 0-RTT kullandığı durumları etkiler.

Retry paketi gönderme (Bölüm 17.2.5) sunucuya Token alanını değiştirme seçeneği sunar. Retry gönderdikten sonra, sunucu aynı zamanda istemciden gelen sonraki Initial paketlerinin Destination Connection ID alanını kontrol edebilir. Bu aynı zamanda Initial paketlerinin şifrelenmiş içeriği üzerinde dolaylı kontrol sağlayabilir. Ancak, Retry paketi değişimi sunucunun adresini doğrular ve böylece sonraki Initial paketlerinin istek sahteciliği için kullanımını engeller.

Bağlantı Geçişi

Sunucular tercih edilen bir adres belirtebilir ve istemciler handshake’i onayladıktan sonra bu adrese geçiş yapar; bkz. Bölüm 9.6. İstemcinin tercih edilen adrese gönderdiği paketlerin Destination Connection ID alanı, istek sahteciliği için kullanılabilir.

Bir istemci, o adresi doğrulamadan önce tercih edilen bir adrese probing olmayan çerçeveler GÖNDERMEMELİDİR; Bölüm 8’e bakın. Bu, bir sunucunun datagramların şifrelenmiş kısmını kontrol etmek için sahip olduğu seçenekleri büyük ölçüde azaltır.

Bu belge, tercih edilen adreslerin kullanımına özgü ve uç noktalar tarafından uygulanabilecek herhangi bir ek karşı önlem sunmamaktadır. Bölüm 21.5.6’da açıklanan genel önlemler daha fazla risk azaltma olarak kullanılabilir.

Yol Üzerindeki Aktif Saldırılar

İstemciler, bir sunucunun o adrese datagram göndermesine neden olmak için görünür bir bağlantı geçişinin parçası olarak sahte bir kaynak adres sunabilir.

Sunucunun daha sonra bu sahte adrese gönderdiği herhangi bir paketteki Destination Connection ID alanı, istek sahteciliği için kullanılabilir. Bir istemci ayrıca şifrelenmiş metni etkileyebilir.

Adres doğrulaması öncesinde bir adrese yalnızca araştırma paketleri (Bölüm 9.1) gönderen bir sunucu, saldırgana datagramların şifrelenmiş kısmı üzerinde yalnızca sınırlı kontrol sağlar. Ancak, özellikle NAT yeniden bağlama durumunda, bu performansı olumsuz etkileyebilir. Sunucu uygulama verisi taşıyan çerçeveler gönderirse, saldırgan datagramların içeriğinin çoğunu kontrol edebilir.

Bu belge, Bölüm 21.5.6’da açıklanan genel önlemlerin dışında, uç noktalar tarafından uygulanabilecek spesifik karşı önlemler sunmamaktadır. Ancak, ağ düzeyindeki adres sahteciliği karşı önlemleri – özellikle giriş filtreleme BCP38 – sahteciliği kullanan ve harici bir ağdan kaynaklanan saldırılara karşı özellikle etkilidir.

Yol Dışı Aktif Saldırılar

Sahte bir kaynak adresi sunabilen istemciler, sunucunun o adrese bir Version Negotiation paketi (Bölüm 17.2.1) göndermesine neden olabilir.

Bilinmeyen sürüme sahip paketler için bağlantı ID alanlarında boyut kısıtlamalarının bulunmaması, istemcinin sonuçta ortaya çıkan datagramdan kontrol ettiği veri miktarını artırır. Bu paketin ilk byte’ı istemci kontrolü altında değildir ve sonraki dört byte sıfırdır, ancak istemci beşinci byte’tan başlayarak 512 byte’a kadar kontrol edebilir.

Bu saldırı için özel karşı önlemler sağlanmamıştır, ancak genel korumalar (Bölüm 21.5.6) uygulanabilir. Bu durumda, giriş filtrelemesi BCP38 de etkilidir.

Sınırlı Yol Üzerinde Aktif Saldırılar

İstek sahteciliği saldırılarına karşı en etkili savunma, güvenlik açığı olan hizmetleri güçlü kimlik doğrulama kullanacak şekilde değiştirmektir. Ancak bu her zaman QUIC dağıtımının kontrolü dahilinde olan bir şey değildir. Bu bölüm, QUIC uç noktalarının tek taraflı olarak atabileceği diğer bazı adımları özetlemektedir. Bu ek adımların tümü isteğe bağlıdır çünkü koşullara bağlı olarak meşru kullanımlara müdahale edebilir veya bunları engelleyebilir.

Loopback arayüzleri üzerinden sunulan hizmetler genellikle uygun kimlik doğrulamadan yoksundur. Endpoint’ler loopback adresine bağlantı girişimlerini veya geçişi engelleyebilir. Endpoint’ler aynı hizmet daha önce farklı bir arayüzde mevcut idiyse veya adres loopback olmayan bir adreste bulunan bir hizmet tarafından sağlandıysa loopback adresine bağlantılara veya geçişe izin vermemelidir. Bu yeteneklere bağımlı olan endpoint’ler bu korumaları devre dışı bırakma seçeneği sunabilir.

Benzer şekilde, endpoint’ler global, benzersiz-yerel RFC4193, veya özel olmayan bir adresten link-local adres RFC4291 veya özel kullanım aralığındaki RFC1918 bir adrese değişikliği potansiyel bir istek sahteciliği girişimi olarak değerlendirebilir. Endpoint’ler bu adresleri tamamen kullanmayı reddedebilir, ancak bu durum meşru kullanımlara müdahale etme konusunda önemli bir risk taşır. Endpoint’ler, belirli bir aralıktaki doğrulanmamış adreslere datagram göndermenin güvenli olmadığını gösteren ağ hakkında spesifik bilgileri olmadıkça bir adresi kullanmayı reddetmemelidir.

Endpoint’ler, NEW_TOKEN frame’lerindeki değerleri Initial paketlere dahil etmeyerek veya adres doğrulamasını tamamlamadan önce yalnızca probing frame’leri göndererek istek sahteciliği riskini azaltmayı SEÇEBİLİR. Bunun bir saldırganın Destination Connection ID alanını bir saldırı için kullanmasını engellemediğini unutmayın.

Uç noktaların, istek sahteciliği saldırısının savunmasız hedefleri olabilecek sunucuların konumu hakkında belirli bilgilere sahip olması beklenmez. Ancak, zaman içinde saldırıların yaygın hedefleri olan belirli UDP portlarını veya saldırılarda kullanılan datagramlardaki belirli desenleri tanımlamak mümkün olabilir. Uç noktalar, hedef adresi doğrulamadan önce bu portlara datagram göndermemeyi veya bu desenlerle eşleşen datagramları göndermemeyi seçebilir. Uç noktalar, sorunlu olduğu bilinen desenleri içeren bağlantı ID’lerini kullanmadan devre dışı bırakabilir.

Not: Bu korumaları uygulamak için endpoint’leri değiştirmek, ağ tabanlı korumalar dağıtmaktan daha verimlidir, çünkü endpoint’lerin doğrulanmış bir adrese gönderim yaparken herhangi bir ek işleme yapması gerekmez.

El Sıkışma Hizmet Reddi Saldırısı

Genellikle Slowloris SLOWLORIS olarak bilinen saldırılar, hedef uç noktasına çok sayıda bağlantıyı açık tutmaya ve bunları mümkün olduğunca uzun süre açık tutmaya çalışır. Bu saldırılar, hareketsizlik nedeniyle kapatılmaktan kaçınmak için gereken minimum aktivite miktarını üreterek QUIC uç noktasına karşı gerçekleştirilebilir. Bu, küçük miktarlarda veri göndermeyi, gönderen hızını kontrol etmek için akış kontrol pencerelerini kademeli olarak açmayı veya yüksek kayıp oranını simüle eden ACK çerçeveleri üretmeyi içerebilir.

QUIC dağıtımları, sunucunun izin vereceği maksimum istemci sayısını artırma, tek bir IP adresinin yapmasına izin verilen bağlantı sayısını sınırlama, bir bağlantının sahip olmasına izin verilen minimum aktarım hızına kısıtlamalar getirme ve bir uç noktanın bağlı kalmasına izin verilen süreyi kısıtlama gibi Slowloris saldırıları için azaltıcı önlemler SAĞLAMALIDIR.

Yükseltme Saldırısı

Düşmanca davranan bir gönderici, akış verilerinin bölümlerini kasıtlı olarak göndermeyebilir ve alıcının gönderilmeyen veriler için kaynak ayırmasına neden olabilir. Bu durum, alıcıda orantısız bir alma tamponu bellek taahhüdüne ve/veya büyük ve verimsiz bir veri yapısının oluşturulmasına yol açabilir.

Düşmanca davranan bir alıcı, göndericiyi yeniden iletim için onaylanmamış akış verilerini depolamaya zorlamak amacıyla akış verisi içeren paketleri kasıtlı olarak onaylamayabilir.

Alıcılara yönelik saldırı, akış kontrol pencerelerinin mevcut bellekle eşleşmesi durumunda azaltılır. Ancak, bazı alıcılar belleği aşırı tahsis edecek ve toplamda gerçek mevcut belleği aşan akış kontrol offset’lerini duyuracaktır. Aşırı tahsis stratejisi, uç noktalar iyi davrandığında daha iyi performansa yol açabilir, ancak uç noktaları stream fragmentation saldırısına karşı savunmasız hale getirir.

QUIC dağıtımları akış parçalanma saldırılarına karşı önlemler SAĞLAMALIDIR. Önlemler belleğin aşırı kullanımından kaçınma, izleme veri yapılarının boyutunu sınırlama, STREAM çerçevelerinin yeniden birleştirilmesini geciktirme, yeniden birleştirme boşluklarının yaşı ve süresine dayalı buluşsal yöntemler uygulama veya bunların bir kombinasyonundan oluşabilir.

İyimser ACK Saldırısı

Düşman bir endpoint çok sayıda stream açabilir ve bir endpoint üzerindeki durumu tüketebilir. Düşman endpoint bu süreci çok sayıda bağlantı üzerinde tekrarlayabilir, TCP’deki SYN flooding saldırılarına benzer bir şekilde.

Normalde, istemciler akışları sıralı olarak açar, Bölüm 2.1’de açıklandığı gibi. Ancak, birkaç akış kısa aralıklarla başlatıldığında, kayıp veya yeniden sıralama, akışları açan STREAM çerçevelerinin sıra dışı alınmasına neden olabilir. Daha yüksek numaralı bir akış kimliği aldığında, alıcı aynı türdeki tüm ara akışları açmak zorundadır; Bölüm 3.2’ye bakınız. Bu nedenle, yeni bir bağlantıda, 4000000 akışını açmak 1 milyon ve 1 istemci tarafından başlatılan çift yönlü akışı açar.

Aktif stream sayısı, Bölüm 4.6’da açıklandığı gibi, alınan MAX_STREAMS frame’leri tarafından güncellenen initial_max_streams_bidi ve initial_max_streams_uni transport parametreleri ile sınırlandırılmıştır. Akıllıca seçildiğinde, bu sınırlar stream commitment saldırısının etkisini azaltır. Ancak, sınırı çok düşük ayarlamak, uygulamaların çok sayıda stream açmasının beklendiği durumlarda performansı etkileyebilir.

İstek Sahtekarlığı Saldırıları

QUIC ve TLS, belirli bağlamlarda meşru kullanımları olan çerçeveler veya mesajlar içerir, ancak bu çerçeveler veya mesajlar kötüye kullanılarak bir eşin bağlantının durumu üzerinde gözlemlenebilir bir etkisi olmaksızın işlem kaynakları harcamasına neden olabilir.

Mesajlar ayrıca akış kontrol limitlerini küçük artışlarla göndermek gibi küçük veya önemsiz şekillerde durumu değiştirmek ve geri almak için de kullanılabilir.

İşleme maliyetleri, bant genişliği tüketimine veya durum üzerindeki etkiye kıyasla orantısız şekilde büyükse, bu durumda kötü niyetli bir peer’ın işleme kapasitesini tüketmesine olanak sağlayabilir.

Tüm mesajların meşru kullanım alanları bulunsa da, uygulamalar işleme maliyetini ilerlemeye göre izlemeli ve üretken olmayan paketlerin aşırı miktarlarını bir saldırı göstergesi olarak değerlendirmelidir. Uç noktalar bu duruma bağlantı hatası ile veya paketleri düşürerek yanıt verebilir.

Endpoint’ler için Kontrol Seçenekleri

Yol üzerindeki bir saldırgan, gönderenin hızını etkilemek için IP başlığındaki ECN alanlarının değerini manipüle edebilir. RFC3168 manipülasyonları ve etkilerini daha detaylı olarak tartışmaktadır.

Sınırlı bir yol üzerinde saldırgan, gönderenin hızını etkilemek için değiştirilmiş ECN alanlarına sahip paketleri çoğaltabilir ve gönderebilir. Çoğaltılmış paketler bir alıcı tarafından atılırsa, saldırganın bu saldırıda başarılı olmak için çoğaltılmış paketi orijinaline karşı yarıştırması gerekecektir. Bu nedenle, QUIC uç noktaları bir IP paketindeki ECN alanını, o IP paketindeki en az bir QUIC paketi başarıyla işlenmedikçe göz ardı eder; Bölüm 13.4’e bakınız.

İstemci İlk Paketleri ile İstek Sahteciliği

Stateless reset’ler, TCP reset injection’a benzer olası bir hizmet reddi saldırısı yaratır. Bu saldırı, bir saldırganın seçilmiş bir connection ID ile bir bağlantı için stateless reset token’ının oluşturulmasına neden olabiliyorsa mümkündür. Bu token’ın oluşturulmasına neden olabilen bir saldırgan, aynı connection ID’ye sahip aktif bir bağlantıyı reset edebilir.

Bir paket statik bir anahtarı paylaşan farklı örneklere yönlendirilebiliyorsa – örneğin, bir IP adresini veya portu değiştirerek – o zaman bir saldırgan sunucunun durumsuz bir sıfırlama göndermesine neden olabilir. Bu tür hizmet reddi saldırısına karşı savunmak için, durumsuz sıfırlamalar için statik bir anahtar paylaşan uç noktalar (Bölüm 10.3.2’ye bakın) belirli bir bağlantı ID’sine sahip paketlerin her zaman bağlantı durumuna sahip bir örneğe ulaşacağı şekilde düzenlenMELİDİR, bu bağlantı artık aktif olmadığı durumlar hariç.

Daha genel olarak, sunucular karşılık gelen bağlantı kimliği ile aynı statik anahtarı kullanan herhangi bir uç noktada etkin olabilecek bir bağlantı varsa durumsuz sıfırlama oluşturmamalıdır.

Dinamik yük dengeleme kullanan bir küme durumunda, aktif bir instance bağlantı durumunu korurken yük dengeleyici konfigürasyonunda değişiklik meydana gelmesi mümkündür. Bir instance bağlantı durumunu koruyor olsa bile, yönlendirmedeki değişiklik ve bunun sonucunda oluşan stateless reset bağlantının sonlandırılmasına neden olacaktır. Paketin doğru instance’a yönlendirilme şansı yoksa, bağlantının zaman aşımına uğramasını beklemek yerine stateless reset göndermek daha iyidir. Ancak bu, yalnızca yönlendirmenin bir saldırgan tarafından etkilenememesi durumunda kabul edilebilir.

Tercih Edilen Adreslerle İstek Sahteciliği

Bu belge, iki uç nokta arasında kullanılan QUIC sürümünü müzakere etmek için kullanılabilen QUIC Sürüm Müzakeresi paketlerini (Bölüm 6) tanımlar. Ancak, bu belge bu sürüm ile gelecekteki sonraki sürümler arasında bu müzakerenin nasıl gerçekleştirileceğini belirtmez. Özellikle, Sürüm Müzakeresi paketleri sürüm düşürme saldırılarını önleyecek herhangi bir mekanizma içermez. Sürüm Müzakeresi paketlerini kullanan gelecekteki QUIC sürümleri, sürüm düşürme saldırılarına karşı dayanıklı bir mekanizma tanımlaMALIDIR.

Sahte Göç ile İstek Sahteciliği

Dağıtımlar, bir saldırganın belirli bir sunucu örneğine yeni bir bağlantıyı hedefleyebilme yeteneğini sınırlamalıdır. İdeal olarak, yönlendirme kararları adresler dahil olmak üzere istemci tarafından seçilen değerlerden bağımsız olarak verilir. Bir örnek seçildikten sonra, sonraki paketlerin aynı örneğe yönlendirilmesi için bir bağlantı kimliği seçilebilir.

Sürüm Müzakeresi ile İstek Sahteciliği

QUIC paketlerinin uzunluğu, bu paketlerin içerik uzunluğu hakkında bilgi verebilir. PADDING frame’i, uç noktaların paket içeriğinin uzunluğunu gizleme konusunda bir miktar yeteneğe sahip olması için sağlanmıştır; Bölüm 19.1’e bakın.

Trafik analizi önleme zorlu bir konudur ve aktif araştırma konusudur. Uzunluk, bilginin sızabileceği tek yol değildir. Uç noktalar ayrıca paket zamanlama gibi diğer yan kanallar aracılığıyla da hassas bilgileri açığa çıkarabilir.

Relay Security

Aşağıda SSU1’de Relay Request, Relay Response, Relay Intro ve Hole Punch analizi yer almaktadır.

Kısıtlamalar: Relay’lerin hızlı olması önemlidir. Round trip’ler en aza indirilmelidir. Bant genişliği ve CPU o kadar önemli değildir.

SSU 1: Alice önce introducer Bob’a bağlanır, Bob talebi Charlie’ye (güvenlik duvarı arkasında olan) iletir. Hole punch işleminden sonra, oturum Alice ve Charlie arasında doğrudan kurulumdaki gibi kurulur.

Alice                         Bob                  Charlie
1. RelayRequest ---------------------->
2.      <-------------- RelayResponse    RelayIntro ----------->
3.      <-------------------------------------------- HolePunch
4. SessionRequest -------------------------------------------->
5.      <-------------------------------------------- SessionCreated
6. SessionConfirmed ------------------------------------------>

Kimlik Doğrulama: Relay Request ve Relay Response güvenli bir şekilde kimlik doğrulaması yapılmaz, çünkü Alice ve Bob genellikle mevcut bir oturuma sahip değildir; bu mesajlar yayınlanmış intro anahtarları kullanır. Oturum içi Relay Request/Response, bir oturum mevcutsa izin verilir ve tercih edilir.

Bob’dan Charlie’ye Relay Intro’nun mevcut bir oturumda olması gerekir, bu nedenle güvenli olduğu varsayılır.

Bob, Relay Intro’ları taklit edebilir veya Relay Request’ten IP/port’u değiştirebilir. İstekleri intro’lara kriptografik olarak bağlayacak veya kötü niyetli Bob’ları önleyecek ya da tespit edecek herhangi bir mekanizma yoktur.

Bob’un router hash’i şu anda Charlie’nin Router Info’sunda yayınlanmamış durumda, bu nedenle Alice-Bob mesajlarının doğrulanmasını istiyorsak bu eklenmelidir. Ek olarak, diğer SSU2 parametreleri Charlie’nin Router Info’sunda yayınlanmalı veya Alice’in ağ veritabanında Bob’un Router Info’sunu araması gerekecektir ki bu da ek gecikmeye neden olur. Doğrulama, Alice ve Bob arasında bir round-trip ekleyecektir.

Alice’in router hash’ini Charlie’ye ileterek, Charlie yerel bir yasaklama listesini kontrol ederek Alice’den bir bağlantı almak isteyip istemediğini daha kolay belirleyebilir. Charlie’nin Bob aracılığıyla Alice’e bir red mesajı göndererek röleyi reddetmesi için bir mekanizma yoktur. Charlie’nin Bob aracılığıyla Alice’e bir kabul mesajı göndererek röleyi kabul etmesi için bir mekanizma yoktur. Alice HolePunch’ı beklemeli veya SessionRequest’i körü körüne göndermelidir. HolePunch, NAT nedeniyle Alice’in beklediğinden farklı bir porttan gelebilir, bu da HolePunch’ın hangi router’dan geldiğini tanımayı zorlaştırabilir.

Alice, tam Router Info’sunu Bob’a Relay Request içinde gönderebilir ve Charlie’ye Relay Intro içinde iletebilir.

Relay Request bir zaman damgası içermez, bu nedenle tekrar saldırısı koruması yoktur. Kaynak IP sahteleştirilebilir, böylece Charlie’nin herhangi bir IP/port’a Hole Punch göndermesi sağlanabilir. Relay Request imzalanmamıştır ve imzalansa ve zaman damgası eklense bile, Charlie imzayı doğrulayabilmek için tam Router Identity’ye sahip değildir.

Protokol, 0-255 bayt değişken uzunlukta bir challenge alanı tanımlar. Relay Request’teki challenge, Relay Intro’da Charlie’ye iletilir. Ancak protokol, challenge’ın nasıl oluşturulacağını, kullanılacağını veya doğrulanacağını belirtmez ve henüz uygulanmamıştır. Eğer HolePunch challenge’ı içerseydi, Alice HolePunch’ı Charlie ile kolayca ilişkilendirebilirdi.

Dört baytlık nonce’nin 8 baytlık bağlantı kimliği ile değiştirilmesi veya desteklenmesi gerekebilir.

Boş Hole Punch mesajı benzersizdir ve yol üzerindeki gözlemciler tarafından protokolü tanımlamak için kullanılabilir, bu değiştirilmelidir.

Ek DPI Tartışması

Aşağıda SSU1’de Peer Test analizi yer almaktadır.

Kısıtlamalar: Peer Test’lerin hızlı, düşük bant genişlikli veya düşük CPU kullanımlı olması özellikle önemli değildir, belki de router başlangıcında bunun istisnası vardır; burada router’ın erişilebilirliğini oldukça hızlı bir şekilde keşfetmesini tercih ederiz.

SSU 1:

Alice                     Bob                  Charlie
1. PeerTest ------------------->
2.                          PeerTest-------------------->
3.                             <-------------------PeerTest
4.      <-------------------PeerTest

5.      <------------------------------------------PeerTest
6. PeerTest------------------------------------------>
7.      <------------------------------------------PeerTest

SSU1 spesifikasyonunu takip etmek zor olduğu için, mesaj içeriklerini aşağıda belgeliyoruz.

Bob, mevcut bir oturumu olan bir Charlie seçer. Mesaj 2 ve 3 oturum içinde gönderilir. Bu nedenle, mesaj 2 ve 3 güvenli ve kimlik doğrulamalıdır.

Mesaj 4 oturum içinde gönderilmelidir; ancak, SSU 1 spesifikasyonu daha önce bunun Alice’in yayınlanmış intro anahtarı ile gönderildiğini söylüyordu, bu da oturum içinde olmadığı anlamına gelir. 0.9.52’den önce, Java I2P intro anahtarı ile gönderiyordu. 0.9.52 itibarıyla, spesifikasyon oturum anahtarının kullanılması gerektiğini belirtir ve Java I2P 0.9.52 itibarıyla mesajı oturum içinde gönderir.

Alice’in Charlie ile mevcut bir oturumu olmaması gerekir ki test devam edebilsin; Bob, Alice ile oturumu olan bir Charlie seçerse Alice testi iptal eder. Bu nedenle, 5-7 mesajları güvenli ve doğrulanmış değildir.

Tüm Peer Test mesajları Alice tarafından seçilen 4 baytlık bir nonce içerir. Bu nonce kriptografik olarak kullanılmaz.

Mesaj 5-7’de mümkün olan saldırılar: araştırılacak.

Alice’in router hash’i Charlie tarafından bilinmemektedir. Charlie’nin router hash’i Alice tarafından bilinmemektedir. Alice-Charlie mesajlarının doğrulanmasını istiyorsak bunların protokole eklenmesi gerekir. Ayrıca, diğer SSU2 parametrelerinin Peer Test mesajlarında sağlanması gerekir, ya da Charlie’nin Alice’in Router Info’sunu network database’den araması gerekir ki bu ek gecikme yaratır. Doğrulama, Charlie ve Alice arasında ek bir round-trip ekleyecektir.

Alice’in router hash’ini Charlie’ye ileterek, Charlie yerel bir yasaklı listesini kontrol ederek Alice ile bir Peer Test’e katılmak isteyip istemediğini daha kolay belirleyebilir.

Dört baytlık nonce’un 8-baytlık bağlantı ID’si ile değiştirilmesi veya desteklenmesi gerekebilir.

Relay and Peer Test Design Goals

Relay ve Peer Test benzer yapılara sahiptir. Her iki durumda da Alice, Bob’tan Charlie’ye bir hizmet isteğini iletmesini talep eder ve Charlie daha sonra bu istek üzerinde hareket eder.

Mevcut SSU1 Eş Test sorunları:

• Peer Test kötü niyetli bir Bob’a karşı herhangi bir koruma sağlamaz
• Peer Test’in Bob veya Charlie’nin bir isteği reddetmesi için herhangi bir yolu yoktur
• Peer Test’in Alice’in Charlie’nin kimliğini bilmesi veya Alice’in bir Charlie’yi reddetmesi için herhangi bir yolu yoktur
• Peer Test’in Charlie’nin Alice’in kimliğini bilmesi veya Charlie’nin bir Alice’i reddetmesi için herhangi bir yolu yoktur
• Peer Test kendi geçici yeniden iletim şemasına sahiptir
• Peer Test hangi mesajın hangi durum için olduğunu bilmek için karmaşık bir durum makinesi gerektirir
• Charlie’nin onu reddettiğini bilmeden, Alice testi bir başarısızlık olarak değerlendirecektir.

Mevcut SSU1 Relay sorunları:

Yukarıda listelenen Peer Test sorunlarının çoğu Peer Test için de geçerlidir.

Relay ve Peer Test güvenliğini iyileştirme konusunda aşağıdaki hedeflerimiz bulunmaktadır:

• Charlie, Alice’in gerektiğinde bilgiyi doğrulayabilmesi için netdb’de tanıtıcıları (Bob’lar) hakkında yeterli bilgi yayınlamalıdır. Örneğin, her tanıtıcı için bir router hash’i yayınlamak, Alice’in zaman izin verdiğinde netdb’den router bilgisini getirmesini sağlar.

• Alice’ten Bob’a gelen istekleri taklit edebilecek, değiştirebilecek, sahteleyebilecek veya tekrar oynatabilecek adres sahteciliği veya yol üzerindeki tehditlere karşı koruma sağlar. Bob, Alice’in gerçek bir I2P router olduğundan ve sunulan istek ile test adresinin geçerli olduğundan emin olmalıdır.

• Kötü niyetli Bob’ların Charlie’ye iletilen istekleri taklit etme, değiştirme, sahtecilik yapma veya yeniden oynatma saldırılarına karşı koruma sağlayın. Charlie, hem Alice hem de Bob’un gerçek I2P router’lar olduğundan ve sunulan istek ile test adresinin geçerli olduğundan emin olmalıdır.

• Bob, isteği doğrulayabilmek ve ardından kabul etmek veya reddetmek için Alice’ten yeterli bilgi almalıdır. Bob, kabul veya reddi Alice’e geri gönderebilmek için bir mekanizmaya sahip olmalıdır. Bob hiçbir zaman talep edilen eylemi gerçekleştirmek zorunda bırakılmamalıdır.

• Charlie, isteği doğrulayabilmek ve ardından kabul edip etmeyeceğini belirleyebilmek için Bob’dan yeterli bilgi almalıdır. Charlie’nin kabul ya da reddi Bob’a geri göndermek için bir mekanizmaya sahip olması gerekir, böylece bu Alice’e iletilebilir. Charlie’nin talep edilen eylemi gerçekleştirmesi asla zorunlu olmamalıdır.

• Alice, Bob üzerinden iletilen yanıtın gerçekten Charlie’den kaynaklandığını doğrulayabilmelidir.

• Alice ve Charlie, sonraki doğrudan mesajlarının (Bob üzerinden aktarılmayan) beklenen kaynaktan geldiğini ve gerçek I2P router’lardan olduğunu doğrulayabilmelidir.

Aşağıdaki mekanizmalar bu hedeflere ulaşmada yardımcı olabilir:

• Zaman damgaları

• Router imzalama anahtarı kullanılarak yapılan imzalar

• İstekte bulunan meydan okuma verilerini kullanma

• Router şifreleme anahtarı kullanarak şifreleme

• IP ve port bilgilerinin yanı sıra router hash’leri, Router Identity’leri veya Router Info’ları gönderme.

• Network veritabanını sorgulayarak router bilgilerinin doğrulanması

• Router bilgilerini, IP’leri ve portları yasak listelere karşı kontrol etme

• Hız sınırlama

• Oturum kurulumu gerektirme

Bu olası mekanizmalar Relay veya Peer Test fonksiyonlarının işlem süresini ve gecikme süresini artırabilir. Tüm etkiler değerlendirilmelidir.

Mümkünse sürümler arası relay ve peer testi de desteklenmelidir. Bu, SSU 1’den SSU 2’ye kademeli geçişi kolaylaştıracaktır. Olası sürüm kombinasyonları şunlardır:

Güvenlik Hedefleri

Summary

Hem I2P içindeki hem de dış standartlardaki mevcut birkaç protokole ilham, rehberlik ve kod yeniden kullanımı için güveniyoruz:

• Tehdit modelleri: NTCP2 NTCP2‘den, QUIC RFC 9000 RFC 9001 tarafından analiz edilen UDP taşıma ile ilgili önemli ek tehditlerle birlikte.

• Kriptografik seçimler: NTCP2‘den.

• Handshake: NTCP2 ve NOISE‘dan Noise XK. UDP tarafından sağlanan kapsülleme (doğal mesaj sınırları) nedeniyle NTCP2’de önemli basitleştirmeler mümkündür.

• Handshake ephemeral key obfuscation: NTCP2‘den uyarlanmıştır ancak AES yerine ECIES‘den ChaCha20 kullanmaktadır.

• Paket başlıkları: WireGuard WireGuard ve QUIC RFC 9000 RFC 9001 protokollerinden uyarlanmıştır.

• Paket başlığı gizleme: NTCP2‘den uyarlanmıştır ancak AES yerine ECIES‘den ChaCha20 kullanır.

• Paket başlığı koruması: QUIC RFC 9001 ve Nonces kaynaklarından uyarlandı

• ECIES içindeki gibi AEAD ilişkili veri olarak kullanılan başlıklar.

• Paket numaralandırma: WireGuard WireGuard ve QUIC RFC 9000 RFC 9001 protokollerinden uyarlanmıştır.

• Mesajlar: SSU protokolünden uyarlanmıştır

• I2NP Fragmentasyonu: SSU adresinden uyarlanmıştır

• Relay ve Peer Testing: SSU adresinden uyarlanmıştır

• Relay ve Peer Test verilerinin İmzaları: Ortak yapılar spesifikasyonundan Common

• Blok formatı: NTCP2 ve ECIES protokollerinden.

• Dolgu ve seçenekler: NTCP2 ve ECIES‘den.

• Onaylar, redler: QUIC RFC 9000‘den uyarlanmıştır.

• Akış kontrolü: TBD

I2P’de daha önce kullanılmamış yeni kriptografik ilkel (primitive) bulunmamaktadır.

Adres Doğrulama

Diğer I2P transport protokolleri NTCP, NTCP2 ve SSU 1’de olduğu gibi, bu transport da sıralı bayt akışı iletimi için genel amaçlı bir tesis değildir. I2NP mesajlarının taşınması için tasarlanmıştır. Herhangi bir “akış” soyutlaması sağlanmamaktadır.

Ek olarak, SSU için olduğu gibi, eş destekli NAT geçişi ve erişilebilirlik testleri (gelen bağlantılar) için ek olanaklar içerir.

SSU 1 için, I2NP mesajlarının sıralı teslimatını sağlamaz. Ayrıca I2NP mesajlarının garantili teslimatını da sağlamaz. Verimlilik için, ya da UDP datagramlarının sırasız teslimatı veya bu datagramların kaybı nedeniyle, I2NP mesajları uzak uca sırasız olarak teslim edilebilir veya hiç teslim edilmeyebilir. Gerekirse bir I2NP mesajı birden fazla kez yeniden iletilebilir, ancak teslim sonunda tam bağlantının kesilmesine neden olmadan başarısız olabilir. Ayrıca, diğer I2NP mesajları için yeniden iletim (kayıp kurtarma) gerçekleşirken bile yeni I2NP mesajları gönderilmeye devam edebilir.

Bu protokol I2NP mesajlarının yinelenen teslimatını tamamen engellemez. Router, I2NP süre dolumunu uygulamalı ve I2NP mesaj kimliğine dayalı bir Bloom filtresi veya başka bir mekanizma kullanmalıdır. Aşağıdaki I2NP Mesaj Yinelemesi bölümüne bakınız.

Noise Protocol Framework

Bu öneri, Noise Protocol Framework NOISE (Revizyon 33, 2017-10-04) temel alınarak hazırlanmış gereksinimleri sağlar. Noise, SSU protokolünün temelini oluşturan Station-To-Station (STS) protokolü ile benzer özelliklere sahiptir. Noise terminolojisinde Alice başlatıcı, Bob ise yanıtlayıcıdır.

SSU2, Noise protokolü Noise_XK_25519_ChaChaPoly_SHA256 tabanlıdır. (İlk anahtar türetme fonksiyonu için gerçek tanımlayıcı, I2P uzantılarını belirtmek üzere “Noise_XKchaobfse+hs1+hs2+hs3_25519_ChaChaPoly_SHA256"dır - aşağıdaki KDF 1 bölümüne bakın)

NOT: Bu tanımlayıcı NTCP2 için kullanılandan farklıdır, çünkü her üç handshake mesajı da başlığı ilişkili veri olarak kullanır.

Bu Noise protokolü aşağıdaki temel öğeleri kullanır:

• Handshake Pattern: XK Alice anahtarını Bob’a iletir (X) Alice Bob’un statik anahtarını zaten biliyor (K)

• DH Function: X25519 RFC 7748‘de belirtildiği gibi 32 byte anahtar uzunluğuna sahip X25519 DH.

• Cipher Function: ChaChaPoly RFC 7539 bölüm 2.8’de belirtilen AEAD_CHACHA20_POLY1305. İlk 4 baytı sıfıra ayarlanmış 12 baytlık nonce.

• Hash Function: SHA256 I2P’de halihazırda yaygın olarak kullanılan standart 32-byte hash.

Additions to the Framework

Bu öneri, Noise_XK_25519_ChaChaPoly_SHA256’ya aşağıdaki geliştirmeleri tanımlar. Bunlar genellikle NOISE bölüm 13’teki yönergeleri takip eder.

1. Handshake mesajları (Session Request, Created, Confirmed) 16 veya 32 byte’lık bir başlık içerir.

2. Handshake mesajlarının başlıkları (Session Request, Created, Confirmed) şifreleme/şifre çözme öncesinde mixHash() fonksiyonuna girdi olarak kullanılır ve başlıkları mesaja bağlar.

3. Başlıklar şifrelenir ve korunur.

4. Açık metin geçici anahtarlar, bilinen bir anahtar ve IV kullanılarak ChaCha20 şifrelemesi ile gizlenir. Bu, elligator2’den daha hızlıdır.

5. Payload formatı mesaj 1, 2 ve veri aşaması için tanımlanmıştır. Tabii ki bu Noise’da tanımlı değildir.

Veri aşaması, Noise veri aşamasına benzer ancak onunla uyumlu olmayan şifreleme kullanır.

Processing overhead estimate

TBD

Definitions

Kullanılan kriptografik yapı taşlarına karşılık gelen aşağıdaki fonksiyonları tanımlıyoruz.

ZEROLEN

zero-length byte array

H(p, d)

SHA-256 hash function that takes a personalization string p and data d, and
produces an output of length 32 bytes.
As defined in [NOISE](https://noiseprotocol.org/noise.html).
|| below means append.

Use SHA-256 as follows::

    H(p, d) := SHA-256(p || d)

MixHash(d)

SHA-256 hash function that takes a previous hash h and new data d,
and produces an output of length 32 bytes.
|| below means append.

Use SHA-256 as follows::

    MixHash(d) := h = SHA-256(h || d)

STREAM

The ChaCha20/Poly1305 AEAD as specified in [RFC 7539](https://tools.ietf.org/html/rfc7539).
S_KEY_LEN = 32 and S_IV_LEN = 12.

ENCRYPT(k, n, plaintext, ad)
    Encrypts plaintext using the cipher key k, and nonce n which MUST be unique for
    the key k.
    Associated data ad is optional.
    Returns a ciphertext that is the size of the plaintext + 16 bytes for the HMAC.

    The entire ciphertext must be indistinguishable from random if the key is secret.

DECRYPT(k, n, ciphertext, ad)
    Decrypts ciphertext using the cipher key k, and nonce n.
    Associated data ad is optional.
    Returns the plaintext.

DH

X25519 public key agreement system. Private keys of 32 bytes, public keys of 32
bytes, produces outputs of 32 bytes. It has the following
functions:

GENERATE_PRIVATE()
    Generates a new private key.

DERIVE_PUBLIC(privkey)
    Returns the public key corresponding to the given private key.

DH(privkey, pubkey)
    Generates a shared secret from the given private and public keys.

HKDF(salt, ikm, info, n)

A cryptographic key derivation function which takes some input key material ikm (which
should have good entropy but is not required to be a uniformly random string), a salt
of length 32 bytes, and a context-specific 'info' value, and produces an output
of n bytes suitable for use as key material.

Use HKDF as specified in [RFC 5869](https://tools.ietf.org/html/rfc5869), using the HMAC hash function SHA-256
as specified in [RFC 2104](https://tools.ietf.org/html/rfc2104). This means that SALT_LEN is 32 bytes max.

MixKey(d)

Use HKDF() with a previous chainKey and new data d, and
sets the new chainKey and k.
As defined in [NOISE](https://noiseprotocol.org/noise.html).

Use HKDF as follows::

    MixKey(d) := output = HKDF(chainKey, d, "", 64)
                 chainKey = output[0:31]
                 k = output[32:63]

Messages

Her UDP datagramı tam olarak bir mesaj içerir. Datagramın uzunluğu (IP ve UDP başlıklarından sonra) mesajın uzunluğudur. Dolgu (padding), varsa, mesajın içindeki bir dolgu bloğunda bulunur. Bu belgede “datagram” ve “paket” terimlerini çoğunlukla birbirinin yerine kullanıyoruz. Her datagram (veya paket) tek bir mesaj içerir (bir datagramın birden fazla QUIC paketi içerebileceği QUIC’in aksine). “Paket başlığı” IP/UDP başlığından sonraki kısımdır.

İstisna: Session Confirmed mesajı, birden fazla pakete bölünebilmesi açısından benzersizdir. Daha fazla bilgi için aşağıdaki Session Confirmed Fragmentation bölümüne bakın.

Tüm SSU2 mesajları en az 40 bayt uzunluğundadır. 1-39 bayt uzunluğundaki herhangi bir mesaj geçersizdir. Tüm SSU2 mesajları 1472 (IPv4) veya 1452 (IPv6) bayt uzunluğuna eşit veya daha kısadır. Mesaj formatı Noise mesajlarına dayanır, çerçeveleme ve ayırt edilemezlik için değişiklikler yapılmıştır. Standart Noise kütüphaneleri kullanan uygulamalar, alınan mesajları standart Noise mesaj formatına ön-işlemelidir. Tüm şifrelenmiş alanlar AEAD şifreli metinlerdir.

Aşağıdaki mesajlar tanımlanmıştır:

Session Establishment

Alice’in Bob’dan daha önce aldığı geçerli bir token’a sahip olduğu durumdaki standart kuruluş dizisi aşağıdaki gibidir:

Alice                           Bob

SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->

Alice geçerli bir token’a sahip olmadığında, kurulum sırası şu şekildedir:

Alice                           Bob

TokenRequest --------------------->
<---------------------------  Retry
SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->

Alice geçerli bir token’a sahip olduğunu düşündüğünde, ancak Bob bunu reddedip (belki de Bob yeniden başlatıldığı için), kurulum sırası şu şekildedir:

Alice                           Bob

SessionRequest ------------------->
<---------------------------  Retry
SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->

Bob, bir Termination bloğu içeren ve neden kodu bulunan bir Retry mesajı ile yanıtlayarak bir Session veya Token Request’i reddedebilir. Neden koduna göre, Alice belirli bir süre boyunca başka bir istek denememelidir:

Alice                           Bob

SessionRequest ------------------->
<---------------------------  Retry containing a Termination block

or

TokenRequest --------------------->
<---------------------------  Retry containing a Termination block

Noise terminolojisini kullanarak, kurulum ve veri dizisi aşağıdaki gibidir: (Payload Güvenlik Özellikleri)

XK(s, rs):           Authentication   Confidentiality
    <- s
    ...
    -> e, es                  0                2
    <- e, ee                  2                1
    -> s, se                  2                5
    <-                        2                5

Bir oturum kurulduktan sonra, Alice ve Bob Data mesajları alışverişinde bulunabilir.

Packet Header

Tüm paketler gizlenmiş (şifrelenmiş) bir başlıkla başlar. İki başlık türü vardır, uzun ve kısa. İlk 13 baytın (Hedef Bağlantı Kimliği, paket numarası ve tür) tüm başlıklar için aynı olduğunu unutmayın.

Genel İstek Sahteciliği Karşı Önlemleri

Uzun başlık 32 byte’tır. Bir oturum oluşturulmadan önce Token Request, SessionRequest, SessionCreated ve Retry için kullanılır. Ayrıca oturum-dışı Peer Test ve Hole Punch mesajları için de kullanılır.

Başlık şifrelemesinden önce:

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: 8 bytes, unsigned big endian integer

  Packet Number :: 4 bytes, unsigned big endian integer

  type :: The message type = 0, 1, 7, 9, 10, or 11

  ver :: The protocol version, equal to 2

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: 8 bytes, unsigned big endian integer

  Token :: 8 bytes, unsigned big endian integer

Slowloris Saldırıları

Kısa başlık 16 bayttır. Session Created ve Data mesajları için kullanılır. Session Request, Retry ve Peer Test gibi kimlik doğrulaması yapılmamış mesajlar her zaman uzun başlığı kullanacaktır.

16 byte gereklidir, çünkü alıcının mesaj türünü elde etmek için ilk 16 byte’ı deşifre etmesi gerekir ve daha sonra mesaj türü tarafından belirtildiği gibi gerçekten uzun bir header ise ek 16 byte’ı deşifre etmesi gerekir.

Session Confirmed için, header şifrelemesinden önce:

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type|frag|  flags  |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: 8 bytes, unsigned big endian integer

  Packet Number :: 4 bytes, all zeros

  type :: The message type = 2

  frag :: 1 byte fragment info:
         bit order: 76543210 (bit 7 is MSB)
         bits 7-4: fragment number 0-14, big endian
         bits 3-0: total fragments 1-15, big endian

  flags :: 2 bytes, unused, set to 0 for future compatibility

Frag alanı hakkında daha fazla bilgi için aşağıdaki Session Confirmed Fragmentation bölümüne bakınız.

Data mesajları için, başlık şifrelemesinden önce:

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type|flag|moreflags|
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: 8 bytes, unsigned big endian integer

  Packet Number :: 4 bytes, unsigned big endian integer

  type :: The message type = 6

  flag :: 1 byte flags:
         bit order: 76543210 (bit 7 is MSB)
         bits 7-1: unused, set to 0 for future compatibility
         bits 0: when set to 1, immediate ack requested

  moreflags :: 2 bytes, unused, set to 0 for future compatibility

Stream Parçalama ve Yeniden Birleştirme Saldırıları

Bağlantı ID’leri rastgele oluşturulmalıdır. Kaynak ve Hedef ID’leri aynı olmamalıdır, böylece yol üzerindeki bir saldırgan yakalayıp geçerli görünen bir paketi gönderene geri gönderemez. Bağlantı ID’leri oluşturmak için sayaç KULLANMAYIN, böylece yol üzerindeki bir saldırgan geçerli görünen bir paket oluşturamaz.

QUIC’ten farklı olarak, handshake sırasında veya sonrasında, hatta bir Retry mesajından sonra bile bağlantı ID’lerini değiştirmiyoruz. ID’ler ilk mesajdan (Token Request veya Session Request) son mesaja (Termination ile Data) kadar sabit kalır. Ayrıca, bağlantı ID’leri path challenge veya connection migration sırasında veya sonrasında değişmez.

QUIC’ten farklı olan bir diğer nokta da başlıklardaki bağlantı ID’lerinin her zaman başlık-şifreli olmasıdır. Aşağıya bakınız.

Stream Commitment Saldırısı

Handshake sırasında First Packet Number bloğu gönderilmezse, paketler tek bir oturum içinde, her yön için, 0’dan başlayarak maksimum (2**32 -1)’e kadar numaralandırılır. Maksimum paket sayısı gönderilmeden çok önce oturum sonlandırılmalı ve yeni bir oturum oluşturulmalıdır.

Eğer handshake sırasında bir First Packet Number bloğu gönderilirse, paketler o yön için tek bir oturum içinde, o paket numarasından başlayarak numaralandırılır. Paket numarası oturum sırasında döngüye girebilir. Maksimum 2**32 paket gönderildiğinde, paket numarası ilk paket numarasına geri dönerek, o oturum artık geçerli olmaz. Maksimum paket sayısı gönderilmeden çok önce oturum sonlandırılmalı ve yeni bir oturum oluşturulmalıdır.

TODO anahtar rotasyonu, maksimum paket sayısını azalt?

Kaybolduğu belirlenen handshake paketleri, paket numarası dahil olmak üzere aynı başlık ile bütün olarak yeniden iletilir. Session Request, Session Created ve Session Confirmed handshake mesajları, yanıtı şifrelemek için aynı zincirleme hash’in kullanılması amacıyla aynı paket numarası ve özdeş şifrelenmiş içerik ile yeniden iletilmelidir. Retry mesajı asla iletilmez.

Kaybolduğu belirlenen veri fazı paketleri asla bütün olarak yeniden iletilmez (sonlandırma hariç, aşağıya bakın). Aynı durum kayıp paketlerin içinde yer alan bloklar için de geçerlidir. Bunun yerine, bloklarda taşınabilecek bilgiler gerektiğinde yeni paketlerde tekrar gönderilir. Veri Paketleri asla aynı paket numarasıyla yeniden iletilmez. Paket içeriklerinin herhangi bir yeniden iletimi (içerikler aynı kalsa da kalmasın da) bir sonraki kullanılmamış paket numarasını kullanmalıdır.

Değiştirilmemiş bütün bir paketi aynı paket numarasıyla olduğu gibi yeniden iletmek, çeşitli nedenlerle izin verilmez. Arka plan bilgisi için QUIC RFC 9000 bölüm 12.3’e bakınız.

• Yeniden iletim için paketleri saklamak verimsizdir
• Yeni bir paket verisi, yol üzerindeki bir gözlemci için farklı görünür, yeniden iletildiğini anlayamaz
• Yeni bir paket ile birlikte güncellenmiş bir ack bloğu gönderilir, eski ack bloğu değil
• Sadece gerekli olanı yeniden iletirsiniz. bazı parçalar zaten bir kez yeniden iletilmiş ve ack alınmış olabilir
• Daha fazla beklemedeyse, her yeniden iletilen pakete ihtiyacınız kadar sığdırabilirsiniz
• Kopya paketleri tespit etmek amacıyla tüm bireysel paketleri takip eden endpoint’ler aşırı durum biriktirme riski altındadır. Kopyaları tespit etmek için gereken veriler, altında tüm paketlerin anında düşürüldüğü minimum bir paket numarası tutarak sınırlandırılabilir.
• Bu şema çok daha esnektir

Yeni paketler, kaybolduğu belirlenen bilgileri taşımak için kullanılır. Genel olarak, bilgi o bilgiyi içeren bir paketin kaybolduğu belirlendiğinde tekrar gönderilir ve o bilgiyi içeren bir paket onaylandığında gönderim durur.

İstisna: Bir Termination bloğu içeren veri fazı paketi, olduğu gibi tamamen yeniden iletilebilir, ancak bu zorunlu değildir. Aşağıdaki Oturum Sonlandırma bölümüne bakın.

Aşağıdaki paketler, göz ardı edilen rastgele bir paket numarası içerir:

• Oturum İsteği
• Oturum Oluşturuldu
• Token İsteği
• Yeniden Deneme
• Eş Testi
• Delik Delme

Alice için, giden paket numaralandırması Session Confirmed ile 0’dan başlar. Bob için, giden paket numaralandırması Session Confirmed’ın ACK’ı olması gereken ilk Data paketi ile 0’dan başlar. Örnek standart handshake’deki paket numaraları şunlar olacaktır:

Alice                           Bob

SessionRequest (r)    ------------>
<-------------   SessionCreated (r)
SessionConfirmed (0)  ------------>
<-------------             Data (0) (Ack-only)
Data (1)              ------------> (May be sent before Ack is received)
<-------------             Data (1)
Data (2)              ------------>
Data (3)              ------------>
Data (4)              ------------>
<-------------             Data (2)

r = random packet number (ignored)
Token Request, Retry, and Peer Test
also have random packet numbers.

Handshake mesajlarının (SessionRequest, SessionCreated veya SessionConfirmed) herhangi bir yeniden iletimi, aynı paket numarası ile değiştirilmeden yeniden gönderilmelidir. Bu mesajları yeniden iletirken farklı ephemeral anahtarlar kullanmayın veya payload’ı değiştirmeyin.

Eş Hizmet Reddi Saldırısı

Başlık (gizleme ve koruma öncesi) AEAD fonksiyonu için ilişkili veride her zaman dahil edilir, böylece başlık kriptografik olarak veriye bağlanır.

Açık Tıkanıklık Bildirimi Saldırıları

Başlık şifreleme birkaç hedefe sahiptir. Arka plan ve varsayımlar için yukarıdaki “Ek DPI Tartışması” bölümüne bakın.

• Çevrimiçi DPI’nin protokolü tanımlamasını engelle
• Aynı bağlantıdaki bir dizi mesajda örüntüleri engelle, handshake yeniden iletimlerini hariç tutarak
• Farklı bağlantılardaki aynı türdeki mesajlarda örüntüleri engelle
• netDb’de bulunan introduction key bilgisi olmaksızın handshake başlıklarının şifresinin çözülmesini engelle
• netDb’de bulunan introduction key bilgisi olmaksızın X25519 geçici anahtarlarının tanımlanmasını engelle
• Herhangi bir çevrimiçi veya çevrimdışı saldırgan tarafından veri aşaması paket numarası ve türünün şifresinin çözülmesini engelle
• netDb’de bulunan introduction key bilgisi olmaksızın yol üzerindeki veya yol dışındaki bir gözlemci tarafından geçerli handshake paketlerinin enjekte edilmesini engelle
• Yol üzerindeki veya yol dışındaki bir gözlemci tarafından geçerli veri paketlerinin enjekte edilmesini engelle
• Gelen paketlerin hızlı ve verimli sınıflandırılmasına izin ver
• Kötü bir Session Request’e yanıt verilmemesi veya Retry yanıtı varsa, netDb’de bulunan introduction key bilgisi olmaksızın yanıtın I2P olarak tanımlanamaması için “sondaj” direnci sağla
• Destination Connection ID kritik veri değildir ve netDb’de bulunan introduction key bilgisine sahip bir gözlemci tarafından şifresi çözülse sorun değildir
• Bir veri aşaması paketinin paket numarası bir AEAD nonce’udur ve kritik veridir. netDb’de bulunan introduction key bilgisine sahip olan bir gözlemci tarafından bile şifresi çözülememeli. Bkz. Nonces.

Başlıklar, ağ veritabanında yayınlanan bilinen anahtarlar veya daha sonra hesaplanan anahtarlarla şifrelenir. El sıkışma aşamasında, bu yalnızca DPI direnci içindir, çünkü anahtar herkese açıktır ve anahtar ile nonce’ler yeniden kullanılır, dolayısıyla bu etkili bir şekilde sadece gizlemedir. Başlık şifrelemesinin, geçici X anahtarlarını (Session Request’te) ve Y anahtarlarını (Session Created’da) gizlemek için de kullanıldığını unutmayın.

Ek rehberlik için aşağıdaki Gelen Paket İşleme bölümüne bakın.

Tüm başlıkların 0-15 baytları, bilinen anahtarlardan hesaplanan verilerle XOR işlemi yapılarak, QUIC RFC 9001 ve Nonces benzer şekilde ChaCha20 kullanılarak bir başlık koruma şeması ile şifrelenir. Bu, şifrelenmiş kısa başlığın ve uzun başlığın ilk bölümünün rastgele görünmesini sağlar.

Session Request ve Session Created için, uzun başlığın 16-31 baytları ve 32-bayt Noise geçici anahtarı ChaCha20 kullanılarak şifrelenir. Şifrelenmemiş veri rastgeledir, bu nedenle şifrelenmiş veri rastgele görünecektir.

Retry için, uzun başlığın 16-31 baytları ChaCha20 kullanılarak şifrelenir. Şifrelenmemiş veri rastgeledir, bu nedenle şifrelenmiş veri de rastgele görünecektir.

QUIC RFC 9001 başlık koruma şemasından farklı olarak, hedef ve kaynak bağlantı ID’leri de dahil olmak üzere tüm başlıkların TÜM bölümleri şifrelenir. QUIC RFC 9001 ve Nonces öncelikle başlığın “kritik” bölümünü, yani paket numarasını (ChaCha20 nonce) şifrelemeye odaklanır. Oturum ID’sini şifrelemek gelen paket sınıflandırmasını biraz daha karmaşık hale getirse de, bazı saldırıları daha zor hale getirir. QUIC farklı fazlar için ve yol zorluğu ile bağlantı geçişi için farklı bağlantı ID’leri tanımlar. Burada şifrelendiği için aynı bağlantı ID’lerini boyunca kullanıyoruz.

Yedi başlık koruma anahtarı fazı bulunmaktadır:

• Session Request ve Token Request
• Session Created
• Retry
• Session Confirmed
• Data Phase
• Peer Test
• Hole Punch

Session Created ve Retry’nin Connection ID’yi şifresini çözmek için k_header_1’e yönelik fallback işleme gerektiren TEK mesajlar olduğuna dikkat edin, çünkü bunlar gönderenin (Bob’un) intro key’ini kullanır. DİĞER TÜM mesajlar k_header_1 için alıcının intro key’ini kullanır. Fallback işleme yalnızca kaynak IP/port’a göre bekleyen outbound bağlantıları araması gerekir.

Kaynak IP/port tarafından yapılan yedek işleme, bekleyen bir giden bağlantı bulamazsa, bunun birkaç nedeni olabilir:

• SSU2 mesajı değil
• Bozuk bir SSU2 mesajı
• Yanıt bir saldırgan tarafından sahte veya değiştirilmiş
• Bob simetrik NAT’a sahip
• Bob mesajın işlenmesi sırasında IP veya port değiştirdi
• Bob yanıtı farklı bir arayüzden gönderdi

Bekleyen giden bağlantıyı bulmaya ve o bağlantı için k_header_1 kullanarak bağlantı kimliğini şifre çözmeye çalışacak ek yedek işleme mümkün olsa da, muhtemelen gerekli değildir. Bob’un NAT’ı veya paket yönlendirmesiyle ilgili sorunları varsa, bağlantının başarısız olmasına izin vermek muhtemelen daha iyidir. Bu tasarım, uç noktaların handshake süresi boyunca kararlı bir adres korumasına dayanır.

Ek yönergeler için aşağıdaki Gelen Paket İşleme bölümüne bakın.

O aşama için başlık şifreleme anahtarlarının türetimi için aşağıdaki bireysel KDF bölümlerine bakın.

Durumsuz Sıfırlama Oracle’ı

// incoming encrypted packet
  packet = incoming encrypted packet
  len = packet.length

  // take the next-to-last 12 bytes of the packet
  iv = packet[len-24:len-13]
  k_header_1 = header encryption key 1
  data = {0, 0, 0, 0, 0, 0, 0, 0}
  mask = ChaCha20.encrypt(k_header_1, iv, data)

  // encrypt the first part of the header by XORing with the mask
  packet[0:7] ^= mask[0:7]

  // take the last 12 bytes of the packet
  iv = packet[len-12:len-1]
  k_header_2 = header encryption key 2
  data = {0, 0, 0, 0, 0, 0, 0, 0}
  mask = ChaCha20.encrypt(k_header_2, iv, data)

  // encrypt the second part of the header by XORing with the mask
  packet[8:15] ^= mask[0:7]


  // For Session Request and Session Created only:
  iv = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}

  // encrypt the third part of the header and the ephemeral key
  packet[16:63] = ChaCha20.encrypt(k_header_2, iv, packet[16:63])


  // For Retry, Token Request, Peer Test, and Hole Punch only:
  iv = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}

  // encrypt the third part of the header
  packet[16:31] = ChaCha20.encrypt(k_header_2, iv, packet[16:31])

Bu KDF, iki ChaCha20 işlemi için IV olarak paketin son 24 baytını kullanır. Tüm paketler 16 baytlık bir MAC ile sonlandığından, bu durum tüm paket yüklerinin minimum 8 bayt olmasını gerektirir. Bu gereklilik ayrıca aşağıdaki mesaj bölümlerinde de belgelenmiştir.

Sürüm Düşürme

Header’ın ilk 8 byte’ını şifreledikten sonra, alıcı Destination Connection ID’yi bilecektir. Buradan itibaren alıcı, oturumun key phase’ine dayanarak header’ın geri kalanı için hangi header şifreleme anahtarını kullanacağını bilir.

Header’ın sonraki 8 byte’ının şifresini çözmek, mesaj tipini ortaya çıkaracak ve bunun kısa veya uzun header olduğunu belirleyebilecektir. Eğer uzun header ise, alıcı version ve netid alanlarını doğrulamalıdır. Eğer version != 2 ise veya netid != beklenen değer ise (genellikle 2, test ağları hariç), alıcı mesajı düşürmelidir.

Packet Integrity

Tüm mesajlar üç ya da dört bölüm içerir:

• Mesaj başlığı
• Yalnızca Session Request ve Session Created için, geçici bir anahtar
• ChaCha20-şifreli yük
• Poly1305 MAC

Tüm durumlarda, başlık (ve varsa, geçici anahtar) tüm mesajın bütünlüğünü sağlamak için kimlik doğrulama MAC’ine bağlanır.

• Handshake mesajları Session Request, Session Created ve Session Confirmed için, mesaj başlığı Noise işleme aşamasından önce mixHash() edilir
• Eğer varsa, ephemeral key standart bir Noise mixHash() tarafından korunur
• Noise handshake dışındaki mesajlar için, başlık ChaCha20/Poly1305 şifrelemesi için Associated Data olarak kullanılır.

Gelen paket işleyicileri, mesajı işlemeden önce her zaman ChaCha20 yükünü deşifre etmeli ve MAC’i doğrulamalıdır, bir istisna dışında: Geçersiz token içeren görünür Session Request mesajları bulunan adres-sahteciliği yapılmış paketlerden gelen DoS saldırılarını azaltmak için, bir işleyicinin tam mesajı deşifre etmeye ve doğrulamaya çalışması GEREKMEYEBİLİR (ChaCha20/Poly1305 deşifrelemesine ek olarak pahalı bir DH işlemi gerektiren). İşleyici, Session Request mesajının başlığında bulunan değerleri kullanarak bir Retry mesajı ile yanıt verebilir.

Authenticated Encryption

Üç ayrı kimlik doğrulama şifrelemesi örneği (CipherStates) vardır. Biri el sıkışma aşamasında, ikisi (gönderme ve alma) veri aşaması için. Her birinin KDF’den kendi anahtarı vardır.

Şifrelenmiş/kimlik doğrulanmış veriler şu şekilde temsil edilecektir

+----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   Encrypted and authenticated data    |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

Yönlendirme ile Hedefli Saldırılar

Şifrelenmiş ve doğrulanmış veri formatı.

Şifreleme/şifre çözme fonksiyonlarına girdiler:

k :: 32 byte cipher key, as generated from KDF

  nonce :: Counter-based nonce, 12 bytes.
           Starts at 0 and incremented for each message.
           First four bytes are always zero.
           Last eight bytes are the counter, little-endian encoded.
           Maximum value is 2**64 - 2.
           Connection must be dropped and restarted after
           it reaches that value.
           The value 2**64 - 1 must never be sent.

  ad :: In handshake phase:
        Associated data, 32 bytes.
        The SHA256 hash of all preceding data.
        In data phase:
        The packet header, 16 bytes.

  data :: Plaintext data, 0 or more bytes

Şifreleme fonksiyonunun çıktısı, şifre çözme fonksiyonunun girdisi:

+----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |       ChaCha20 encrypted data         |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +              (MAC)                    +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+

  encrypted data :: Same size as plaintext data, 0 - 65519 bytes

  MAC :: Poly1305 message authentication code, 16 bytes

ChaCha20 için, burada açıklanan şey RFC 7539‘a karşılık gelir ve bu aynı zamanda TLS RFC 7905’te de benzer şekilde kullanılır.

Trafik Analizi

• ChaCha20 bir akış şifresi olduğundan, düz metinlerin doldurulması gerekmez. Ek anahtar akışı baytları atılır.

• Şifre için anahtar (256 bit) SHA256 KDF aracılığıyla kararlaştırılır. Her mesaj için KDF detayları aşağıdaki ayrı bölümlerde yer almaktadır.

AEAD Error Handling

• Tüm mesajlarda, AEAD mesaj boyutu önceden bilinir. Bir AEAD kimlik doğrulama hatası durumunda, alıcı daha fazla mesaj işlemeyi durdurmalı ve mesajı atmalıdır.

• Bob, tekrarlanan başarısızlıkları olan IP’lerin kara listesini tutmalıdır.

KDF for Session Request

Key Derivation Function (KDF), DH sonucundan bir handshake aşaması şifre anahtarı k üretir ve RFC 2104’te tanımlandığı şekliyle HMAC-SHA256(key, data) kullanır. Bunlar InitializeSymmetric(), MixHash(), ve MixKey() fonksiyonlarıdır ve tam olarak Noise spesifikasyonunda tanımlandığı gibidir.

KDF for Initial ChainKey

// Define protocol_name.
  Set protocol_name = "Noise_XKchaobfse+hs1+hs2+hs3_25519_ChaChaPoly_SHA256"
   (52 bytes, US-ASCII encoded, no NULL termination).

  // Define Hash h = 32 bytes
  h = SHA256(protocol_name);

  Define ck = 32 byte chaining key. Copy the h data to ck.
  Set ck = h

  // MixHash(null prologue)
  h = SHA256(h);

  // up until here, can all be precalculated by Alice for all outgoing connections

  // Bob's X25519 static keys
  // bpk is published in routerinfo
  bsk = GENERATE_PRIVATE()
  bpk = DERIVE_PUBLIC(bsk)

  // Bob static key
  // MixHash(bpk)
  // || below means append
  h = SHA256(h || bpk);

  // Bob introduction key
  // bik is published in routerinfo
  bik = RANDOM(32)

  // up until here, can all be precalculated by Bob for all incoming connections

KDF for Session Request

// MixHash(header)
  h = SHA256(h || header)

  This is the "e" message pattern:

  // Alice's X25519 ephemeral keys
  aesk = GENERATE_PRIVATE()
  aepk = DERIVE_PUBLIC(aesk)

  // Alice ephemeral key X
  // MixHash(aepk)
  h = SHA256(h || aepk);

  // h is used as the associated data for the AEAD in Session Request
  // Retain the Hash h for the Session Created KDF


  End of "e" message pattern.

  This is the "es" message pattern:

  // DH(e, rs) == DH(s, re)
  sharedSecret = DH(aesk, bpk) = DH(bsk, aepk)

  // MixKey(DH())
  //[chainKey, k] = MixKey(sharedSecret)
  // ChaChaPoly parameters to encrypt/decrypt
  keydata = HKDF(chainKey, sharedSecret, "", 64)
  chainKey = keydata[0:31]

  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, payload, ad)

  // retain the chainKey for Session Created KDF


  End of "es" message pattern.

  // Header encryption keys for this message
  // bik = Bob's intro key
  k_header_1 = bik
  k_header_2 = bik

  // Header encryption keys for next message (Session Created)
  k_header_1 = bik
  k_header_2 = HKDF(chainKey, ZEROLEN, "SessCreateHeader", 32)

  // Header encryption keys for next message (Retry)
  k_header_1 = bik
  k_header_2 = bik

SessionRequest (Type 0)

Alice, Bob’a handshake’deki ilk mesaj olarak ya da bir Retry mesajına yanıt olarak gönderir. Bob bir Session Created mesajı ile yanıtlar. Boyut: 80 + payload boyutu. Minimum Boyut: 88

Alice’in geçerli bir token’ı yoksa, Session Request oluştururken asimetrik şifreleme yükünden kaçınmak için Session Request yerine Token Request mesajı göndermelidir.

Uzun başlık. Noise içeriği: Alice’in geçici anahtarı X Noise yükü: DateTime ve diğer bloklar Maksimum yük boyutu: MTU - 108 (IPv4) veya MTU - 128 (IPv6). 1280 MTU için: Maksimum yük 1172 (IPv4) veya 1152 (IPv6). 1500 MTU için: Maksimum yük 1392 (IPv4) veya 1372 (IPv6).

Payload Güvenlik Özellikleri:

XK(s, rs):           Authentication   Confidentiality
    -> e, es                  0                2

    Authentication: None (0).
    This payload may have been sent by any party, including an active attacker.

    Confidentiality: 2.
    Encryption to a known recipient, forward secrecy for sender compromise
    only, vulnerable to replay.  This payload is encrypted based only on DHs
    involving the recipient's static key pair.  If the recipient's static
    private key is compromised, even at a later date, this payload can be
    decrypted.  This message can also be replayed, since there's no ephemeral
    contribution from the recipient.

    "e": Alice generates a new ephemeral key pair and stores it in the e
         variable, writes the ephemeral public key as cleartext into the
         message buffer, and hashes the public key along with the old h to
         derive a new h.

    "es": A DH is performed between the Alice's ephemeral key pair and the
          Bob's static key pair.  The result is hashed along with the old ck to
          derive a new ck and k, and n is set to zero.

X değeri, gerekli DPI karşı önlemleri olan payload ayırt edilemezliği ve benzersizliği sağlamak için şifrelenir. Bunu başarmak için elligator2 gibi daha karmaşık ve yavaş alternatiflerin yerine ChaCha20 şifrelemesi kullanırız. Bob’un router public key’ine asimetrik şifreleme çok yavaş olurdu. ChaCha20 şifrelemesi, network database’de yayınlandığı şekliyle Bob’un intro key’ini kullanır.

ChaCha20 şifrelemesi sadece DPI direnci için kullanılır. Bob’un giriş anahtarını bilen herhangi bir taraf (bu anahtar network database’de yayınlanır) bu mesajdaki başlık ve X değerini çözebilir.

Ham içerikler:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key         +
  |    See Header Encryption KDF          |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Bob intro key n=0     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       X, ChaCha20 encrypted           +
  |       with Bob intro key n=0          |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data             |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 0                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

  X :: 32 bytes, ChaCha20 encrypted X25519 ephemeral key, little endian
          key: Bob's intro key
          n: 1
          data: 48 bytes (bytes 16-31 of the header, followed by encrypted X)

Şifrelenmemiş veri (Poly1305 kimlik doğrulama etiketi gösterilmemiştir):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                   X                   |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |     see below for allowed blocks      |
  +----+----+----+----+----+----+----+----+


  Destination Connection ID :: Randomly generated by Alice

  id :: 1 byte, the network ID (currently 2, except for test networks)

  ver :: 2

  type :: 0

  flag :: 1 byte, unused, set to 0 for future compatibility

  Packet Number :: Random 4 byte number generated by Alice, ignored

  Source Connection ID :: Randomly generated by Alice,
                          must not be equal to Destination Connection ID

  Token :: 0 if not previously received from Bob

  X :: 32 bytes, X25519 ephemeral key, little endian

Payload

• DateTime bloğu
• Options bloğu (isteğe bağlı)
• Relay Tag Request bloğu (isteğe bağlı)
• Padding bloğu (isteğe bağlı)

Minimum payload boyutu 8 byte’dır. DateTime bloğu sadece 7 byte olduğundan, en az bir başka blok daha bulunmalıdır.

Notes

• Başlangıç ChaCha20 bloğundaki benzersiz X değeri, şifreli metnin her oturum için farklı olmasını sağlar.

• Probing direncini sağlamak için Bob, Session Request mesajındaki mesaj türü, protokol sürümü ve ağ kimliği alanları geçerli olmadığı sürece Session Request mesajına yanıt olarak Retry mesajı göndermemelidir.

• Bob, zaman damgası değerinin mevcut zamandan çok uzak olduğu bağlantıları reddetmelidir. Maksimum delta zamanını “D” olarak adlandırın. Bob, daha önce kullanılmış handshake değerlerinin yerel bir önbelleğini tutmalı ve tekrar saldırılarını önlemek için duplikaları reddetmelidir. Önbellekteki değerlerin en az 2*D ömrü olmalıdır. Önbellek değerleri uygulamaya bağımlıdır, ancak 32-byte X değeri (veya şifrelenmiş eşdeğeri) kullanılabilir. Sıfır token ve sonlandırma bloğu içeren bir Retry mesajı göndererek reddedin.

• Diffie-Hellman geçici anahtarları kriptografik saldırıları önlemek için asla yeniden kullanılmamalıdır ve yeniden kullanım tekrar saldırısı olarak reddedilecektir.

• “KE” ve “auth” seçenekleri uyumlu olmalıdır, yani paylaşılan gizli anahtar K uygun boyutta olmalıdır. Daha fazla “auth” seçeneği eklenirse, bu “KE” bayrağının anlamını farklı bir KDF veya farklı bir kesme boyutu kullanacak şekilde örtük olarak değiştirebilir.

• Bob, Alice’in geçici anahtarının eğri üzerinde geçerli bir nokta olduğunu burada doğrulamalıdır.

• Padding makul bir miktarla sınırlandırılmalıdır. Bob aşırı padding içeren bağlantıları reddedebilir. Bob padding seçeneklerini Session Created içinde belirtecektir. Min/max kılavuzları belirlenmedi. Minimum 0 ila 31 bayt arası rastgele boyut? (Dağıtım belirlenecek, Ek A’ya bakın.) PMTU için minimum paket boyutu zorunlu kılınmadığı SÜRECE TODO.

• Çoğu hatada, AEAD, DH, görünür tekrar oynatma veya anahtar doğrulama hatası dahil olmak üzere, Bob daha fazla mesaj işlemeyi durdurmalı ve yanıtlamadan mesajı bırakmalıdır.

• Bob, DateTime bloğundaki zaman damgası çok fazla kaymış ise sıfır token ve saat kayması neden kodu içeren bir Termination bloğu içeren bir Retry mesajı GÖNDEREBİLİR.

• DoS Azaltma: DH nispeten pahalı bir işlemdir. Önceki NTCP protokolünde olduğu gibi, router’lar CPU veya bağlantı tükenmesini önlemek için gerekli tüm önlemleri almalıdır. Maksimum aktif bağlantılar ve devam eden maksimum bağlantı kurulumları için sınırlar koyun. Okuma zaman aşımlarını uygulayın (hem okuma başına hem de “slowloris” için toplam). Aynı kaynaktan tekrarlanan veya eşzamanlı bağlantıları sınırlayın. Tekrar tekrar başarısız olan kaynaklar için kara listeler tutun. AEAD hatasına yanıt vermeyin. Alternatif olarak, DH işlemi ve AEAD doğrulamasından önce bir Retry mesajı ile yanıt verin.

• “ver” alanı: Genel Noise protokolü, uzantıları ve yük belirtimlerini içeren SSU2 protokolü, SSU2’yi belirtir. Bu alan gelecekteki değişiklikler için destek belirtmek amacıyla kullanılabilir.

• Network ID alanı, çapraz ağ bağlantılarını hızlıca tanımlamak için kullanılır. Bu alan Bob’un network ID’si ile eşleşmiyorsa, Bob bağlantıyı kesip gelecekteki bağlantıları engellemeli.

• Bob, Kaynak Bağlantı Kimliği Hedef Bağlantı Kimliği’ne eşitse mesajı düşürmelidir.

KDF for Session Created and Session Confirmed part 1

// take h saved from Session Request KDF
  // MixHash(ciphertext)
  h = SHA256(h || encrypted Noise payload from Session Request)

  // MixHash(header)
  h = SHA256(h || header)

  This is the "e" message pattern:

  // Bob's X25519 ephemeral keys
  besk = GENERATE_PRIVATE()
  bepk = DERIVE_PUBLIC(besk)

  // h is from KDF for Session Request
  // Bob ephemeral key Y
  // MixHash(bepk)
  h = SHA256(h || bepk);

  // h is used as the associated data for the AEAD in Session Created
  // Retain the Hash h for the Session Confirmed KDF

  End of "e" message pattern.

  This is the "ee" message pattern:

  // MixKey(DH())
  //[chainKey, k] = MixKey(sharedSecret)
  sharedSecret = DH(aesk, bepk) = DH(besk, aepk)
  keydata = HKDF(chainKey, sharedSecret, "", 64)
  chainKey = keydata[0:31]

  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, payload, ad)

  // retain the chaining key ck for Session Confirmed KDF

  End of "ee" message pattern.

  // Header encryption keys for this message
  // bik = Bob's intro key
  k_header_1 = bik
  k_header_2: See Session Request KDF above

  // Header protection keys for next message (Session Confirmed)
  k_header_1 = bik
  k_header_2 = HKDF(chainKey, ZEROLEN, "SessionConfirmed", 32)

Bağlantı Geçişi

Bob, Alice’a Session Request mesajına yanıt olarak gönderir. Alice, Session Confirmed mesajıyla yanıt verir. Boyut: 80 + payload boyutu. Minimum Boyut: 88

Noise içeriği: Bob’un geçici anahtarı Y Noise yükü: DateTime, Address ve diğer bloklar Maksimum yük boyutu: MTU - 108 (IPv4) veya MTU - 128 (IPv6). 1280 MTU için: Maksimum yük 1172 (IPv4) veya 1152 (IPv6). 1500 MTU için: Maksimum yük 1392 (IPv4) veya 1372 (IPv6).

Payload Güvenlik Özellikleri:

XK(s, rs):           Authentication   Confidentiality
    <- e, ee                  2                1

    Authentication: 2.
    Sender authentication resistant to key-compromise impersonation (KCI).
    The sender authentication is based on an ephemeral-static DH ("es" or "se")
    between the sender's static key pair and the recipient's ephemeral key pair.
    Assuming the corresponding private keys are secure, this authentication cannot be forged.

    Confidentiality: 1.
    Encryption to an ephemeral recipient.
    This payload has forward secrecy, since encryption involves an ephemeral-ephemeral DH ("ee").
    However, the sender has not authenticated the recipient,
    so this payload might be sent to any party, including an active attacker.


    "e": Bob generates a new ephemeral key pair and stores it in the e variable,
    writes the ephemeral public key as cleartext into the message buffer,
    and hashes the public key along with the old h to derive a new h.

    "ee": A DH is performed between the Bob's ephemeral key pair and the Alice's ephemeral key pair.
    The result is hashed along with the old ck to derive a new ck and k, and n is set to zero.

Y değeri, DPI karşı önlemleri için gerekli olan payload ayırt edilemezliği ve benzersizliği sağlamak amacıyla şifrelenir. Bunu başarmak için elligator2 gibi daha karmaşık ve yavaş alternatiflere kıyasla ChaCha20 şifrelemeyi kullanırız. Alice’in router genel anahtarına asimetrik şifreleme çok yavaş olurdu. ChaCha20 şifreleme, network database’de yayınlandığı şekliyle Bob’un intro key’ini kullanır.

ChaCha20 şifrelemesi yalnızca DPI direnç için kullanılır. Bob’un intro anahtarını bilen (bu anahtar ağ veritabanında yayınlanmıştır) ve Session Request’in ilk 32 baytını yakalayan herhangi bir taraf, bu mesajdaki Y değerini şifresini çözebilir.

Ham içerikler:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key and     +
  | derived key, see Header Encryption KDF|
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with derived key n=0       +
  |  See Header Encryption KDF            |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       Y, ChaCha20 encrypted           +
  |       with derived key n=0            |
  +              (32 bytes)               +
  |       See Header Encryption KDF       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 data                       |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in KDF for Session Created +
  |  n = 0; see KDF for associated data   |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

  Y :: 32 bytes, ChaCha20 encrypted X25519 ephemeral key, little endian
          key: Bob's intro key
          n: 1
          data: 48 bytes (bytes 16-31 of the header, followed by encrypted Y)

Şifrelenmemiş veri (Poly1305 auth tag gösterilmiyor):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  Y                    |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |      see below for allowed blocks     |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: The Source Connection ID
                               received from Alice in Session Request

  id :: 1 byte, the network ID (currently 2, except for test networks)

  ver :: 2

  type :: 0

  flag :: 1 byte, unused, set to 0 for future compatibility

  Packet Number :: Random 4 byte number generated by Bob, ignored

  Source Connection ID :: The Destination Connection ID
                          received from Alice in Session Request

  Token :: 0 (unused)

  Y :: 32 bytes, X25519 ephemeral key, little endian

Payload

• DateTime bloğu
• Address bloğu
• Relay Tag bloğu (isteğe bağlı)
• New Token bloğu (isteğe bağlı)
• First Packet Number bloğu (isteğe bağlı)
• Options bloğu (isteğe bağlı)
• Termination bloğu (önerilmez, bunun yerine bir retry mesajında gönderin)
• Padding bloğu (isteğe bağlı)

Minimum yük boyutu 8 bayttır. DateTime ve Address blokları toplamda bundan fazla olduğu için, gereksinim yalnızca bu iki blokla karşılanır.

Notes

• Alice, Bob’un geçici anahtarının eğri üzerinde geçerli bir nokta olduğunu burada doğrulamalıdır.

• Padding makul bir miktarla sınırlandırılmalıdır. Alice aşırı padding içeren bağlantıları reddedebilir. Alice padding seçeneklerini Session Confirmed’da belirtecektir. Min/max kılavuzları TBD. Minimum 0 ile 31 bayt arası rastgele boyut? (Dağılım belirlenecek, bkz. Ek A.) TODO UNLESS PMTU için minimum paket boyutu zorunlu kılınır.

• Herhangi bir hata durumunda (AEAD, DH, timestamp, belirgin replay, veya anahtar doğrulama hatası dahil), Alice daha fazla mesaj işlemeyi durdurmalı ve yanıt vermeden bağlantıyı kapatmalıdır.

• Alice, zaman damgası değeri mevcut zamandan çok fazla sapma gösteren bağlantıları reddetmelidir. Maksimum delta zamanını “D” olarak adlandırın. Alice, daha önce kullanılmış handshake değerlerinin yerel bir önbelleğini tutmalı ve tekrar saldırılarını önlemek için kopyaları reddetmelidir. Önbellekteki değerler en az 2*D yaşam süresine sahip olmalıdır. Önbellek değerleri implementasyona bağımlıdır, ancak 32-byte Y değeri (veya şifrelenmiş eşdeğeri) kullanılabilir.

• Alice, kaynak IP ve port, Session Request’in hedef IP ve portu ile eşleşmiyorsa mesajı düşürmek zorundadır.

• Alice, Hedef ve Kaynak Bağlantı Kimliklerinin Oturum İsteğinin Kaynak ve Hedef Bağlantı Kimlikleriyle eşleşmemesi durumunda mesajı bırakmalıdır.

• Bob, Alice tarafından Session Request’te talep edilirse bir relay tag bloğu gönderir.

Issues

• Min/maks dolgu seçenekleri buraya dahil edilsin mi?

KDF for Session Confirmed part 1, using Session Created KDF

// take h saved from Session Created KDF
  // MixHash(ciphertext)
  h = SHA256(h || encrypted Noise payload from Session Created)

  // MixHash(header)
  h = SHA256(h || header)
  // h is used as the associated data for the AEAD in Session Confirmed part 1, below

  This is the "s" message pattern:

  // Alice's X25519 static keys
  ask = GENERATE_PRIVATE()
  apk = DERIVE_PUBLIC(ask)

  // AEAD parameters
  // k is from Session Request
  n = 1
  ad = h
  ciphertext = ENCRYPT(k, n++, apk, ad)

  // MixHash(ciphertext)
  h = SHA256(h || ciphertext);

  // h is used as the associated data for the AEAD in Session Confirmed part 2

  End of "s" message pattern.

  // Header encryption keys for this message
  See Session Confirmed part 2 below

KDF for Session Confirmed part 2

This is the "se" message pattern:

  // DH(ask, bepk) == DH(besk, apk)
  sharedSecret = DH(ask, bepk) = DH(besk, apk)

  // MixKey(DH())
  //[chainKey, k] = MixKey(sharedSecret)
  keydata = HKDF(chainKey, sharedSecret, "", 64)
  chainKey = keydata[0:31]

  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, payload, ad)

  // h from Session Confirmed part 1 is used as the associated data for the AEAD in Session Confirmed part 2
  // MixHash(ciphertext)
  h = SHA256(h || ciphertext);

  // retain the chaining key ck for the data phase KDF
  // retain the hash h for the data phase KDF

  End of "se" message pattern.

  // Header encryption keys for this message
  // bik = Bob's intro key
  k_header_1 = bik
  k_header_2: See Session Created KDF above

  // Header protection keys for data phase
  See data phase KDF below

SessionConfirmed (Type 2)

Alice, Session Created mesajına yanıt olarak Bob’a gönderir. Bob hemen bir ACK bloğu içeren bir Data mesajı ile yanıtlar. Boyut: 80 + payload boyutu. Minimum Boyut: Yaklaşık 500 (minimum router info blok boyutu yaklaşık 420 bayt)

Noise içeriği: Alice’in statik anahtarı Noise payload kısmı 1: Hiçbiri Noise payload kısmı 2: Alice’in RouterInfo’su ve diğer bloklar Maksimum payload boyutu: MTU - 108 (IPv4) veya MTU - 128 (IPv6). 1280 MTU için: Maksimum payload 1172 (IPv4) veya 1152 (IPv6). 1500 MTU için: Maksimum payload 1392 (IPv4) veya 1372 (IPv6).

Payload Güvenlik Özellikleri:

XK(s, rs):           Authentication   Confidentiality
    -> s, se                  2                5

    Authentication: 2.
    Sender authentication resistant to key-compromise impersonation (KCI).  The
    sender authentication is based on an ephemeral-static DH ("es" or "se")
    between the sender's static key pair and the recipient's ephemeral key
    pair.  Assuming the corresponding private keys are secure, this
    authentication cannot be forged.

    Confidentiality: 5.
    Encryption to a known recipient, strong forward secrecy.  This payload is
    encrypted based on an ephemeral-ephemeral DH as well as an ephemeral-static
    DH with the recipient's static key pair.  Assuming the ephemeral private
    keys are secure, and the recipient is not being actively impersonated by an
    attacker that has stolen its static private key, this payload cannot be
    decrypted.

    "s": Alice writes her static public key from the s variable into the
    message buffer, encrypting it, and hashes the output along with the old h
    to derive a new h.

    "se": A DH is performed between the Alice's static key pair and the Bob's
    ephemeral key pair.  The result is hashed along with the old ck to derive a
    new ck and k, and n is set to zero.

Bu iki ChaChaPoly frame içerir. İlki Alice’in şifrelenmiş statik public key’idir. İkincisi Noise payload’ıdır: Alice’in şifrelenmiş RouterInfo’su, isteğe bağlı seçenekler ve isteğe bağlı padding. Farklı anahtarlar kullanırlar, çünkü aralarında MixKey() fonksiyonu çağrılır.

Ham içerikler:

+----+----+----+----+----+----+----+----+
  |  Short Header 16 bytes, ChaCha20      |
  +  encrypted with Bob intro key and     +
  | derived key, see Header Encryption KDF|
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 frame (32 bytes)           |
  +   Encrypted and authenticated data    +
  +   Alice static key S                  +
  | k defined in KDF for Session Created  |
  +     n = 1                             +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  + Length varies (remainder of packet)   +
  |                                       |
  +   ChaChaPoly frame                    +
  |   Encrypted and authenticated         |
  +   see below for allowed blocks        +
  |                                       |
  +     k defined in KDF for              +
  |     Session Confirmed part 2          |
  +     n = 0                             +
  |     see KDF for associated data       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

  S :: 32 bytes, ChaChaPoly encrypted Alice's X25519 static key, little endian
       inside 48 byte ChaChaPoly frame

Şifrelenmemiş veri (Poly1305 auth etiketleri gösterilmiyor):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type|frag|  flags  |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |              S                        |
  +       Alice static key                +
  |          (32 bytes)                   |
  +                                       +
  |                                       |
  +                                       +
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |        Noise Payload                  |
  +        (length varies)                +
  |        see below for allowed blocks   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: As sent in Session Request,
                               or one received in Session Confirmed?

  Packet Number :: 0 always, for all fragments, even if retransmitted

  type :: 2

  frag :: 1 byte fragment info:
         bit order: 76543210 (bit 7 is MSB)
         bits 7-4: fragment number 0-14, big endian
         bits 3-0: total fragments 1-15, big endian

  flags :: 2 bytes, unused, set to 0 for future compatibility

  S :: 32 bytes, Alice's X25519 static key, little endian

Payload

• RouterInfo bloğu (ilk blok olmalıdır)
• Options bloğu (isteğe bağlı)
• New Token bloğu (isteğe bağlı)
• Relay Request bloğu (isteğe bağlı)
• Peer Test bloğu (isteğe bağlı)
• First Packet Number bloğu (isteğe bağlı)
• I2NP, First Fragment, veya Follow-on Fragment blokları (isteğe bağlı, ancak muhtemelen yer yok)
• Padding bloğu (isteğe bağlı)

Minimum payload boyutu 8 bayttır. RouterInfo bloğu bundan çok daha fazla olacağından, gereksinim sadece o blokla karşılanır.

Notes

• Bob, olağan Router Info doğrulamasını gerçekleştirmelidir. İmza türünün desteklendiğinden emin olun, imzayı doğrulayın, zaman damgasının sınırlar içinde olduğunu doğrulayın ve gerekli diğer tüm kontrolleri yapın. Fragmented Router Info’ların ele alınması hakkındaki notlar için aşağıya bakın.

• Bob, ilk çerçevede alınan Alice’in statik anahtarının Router Info’daki statik anahtarla eşleştiğini doğrulamalıdır. Bob öncelikle Router Info’da eşleşen sürüm (v) seçeneğine sahip bir NTCP veya SSU2 Router Adresi aramalıdır. Aşağıdaki Yayınlanmış Router Info ve Yayınlanmamış Router Info bölümlerine bakın. Parçalanmış Router Info’ların işlenmesiyle ilgili notlar için aşağıya bakın.

• Eğer Bob’un netdb’sinde Alice’in RouterInfo’sunun eski bir sürümü varsa, router info’da bulunan static key’in her ikisinde de aynı olduğunu doğrulayın (eğer mevcutsa) ve eski sürüm XXX’den daha az eskiyse (aşağıdaki key rotate zamanına bakın)

• Bob, Alice’in statik anahtarının burada eğri üzerinde geçerli bir nokta olduğunu doğrulamalıdır.

• Dolgu parametrelerini belirtmek için seçenekler dahil edilmelidir.

• AEAD, RI, DH, zaman damgası veya anahtar doğrulama hatası dahil olmak üzere herhangi bir hata durumunda, Bob daha fazla mesaj işlemeyi durdurmalı ve yanıt vermeden bağlantıyı kapatmalıdır.

• Message 3 part 2 çerçeve içeriği: Bu çerçevenin formatı, çerçeve uzunluğunun Alice tarafından Session Request’te gönderilmesi dışında, veri aşaması çerçeveleri formatı ile aynıdır. Veri aşaması çerçeve formatı için aşağıya bakın. Çerçeve aşağıdaki sırayla 1 ile 4 arasında blok içermelidir:

  1. Alice’in Router Info bloğu (gerekli)
  2. Options bloğu (isteğe bağlı)
  3. I2NP blokları (isteğe bağlı)
  4. Padding bloğu (isteğe bağlı) Bu çerçeve asla başka bir blok türü içermemelidir. TODO: relay ve peer test ne olacak?

• Mesaj 3 bölüm 2 dolgu bloğu önerilir.

• MTU ve Router Info boyutuna bağlı olarak I2NP blokları için hiç alan bulunmayabilir veya yalnızca küçük miktarda alan mevcut olabilir. Router Info parçalanmışsa I2NP bloklarını dahil ETMEYİN. En basit uygulama, Session Confirmed mesajında hiçbir zaman I2NP blokları dahil etmemek ve tüm I2NP bloklarını sonraki Data mesajlarında göndermek olabilir. Maksimum blok boyutu için aşağıdaki Router Info blok bölümüne bakın.

Session Confirmed Fragmentation

Session Confirmed mesajı, Bob’un gerekli birkaç kontrolü gerçekleştirebilmesi için Alice’den gelen tam imzalı Router Info’yu içermelidir:

• RI’daki statik anahtar “s”, handshake’deki statik anahtarla eşleşir
• RI’daki tanıtım anahtarı “i” çıkarılmalı ve geçerli olmalı, veri aşamasında kullanılmak üzere
• RI imzası geçerli

Ne yazık ki Router Info, RI bloğunda gzip ile sıkıştırılmış olsa bile MTU’yu aşabilir. Bu nedenle, Session Confirmed iki veya daha fazla pakete bölünebilir. Bu, SSU2 protokolünde AEAD korumalı yükün iki veya daha fazla pakete bölündüğü TEK durumdur.

Her paket için başlıklar aşağıdaki gibi oluşturulur:

• TÜM başlıklar aynı paket numarası 0 ile kısa başlıklardır
• TÜM başlıklar parça numarası ve toplam parça sayısını içeren bir “frag” alanı içerir
• Parça 0’ın şifrelenmemiş başlığı, “jumbo” mesajı için ilişkili veri (AD)‘dir
• Her başlık, O paketteki son 24 bayt veri kullanılarak şifrelenir

Paket serisini aşağıdaki şekilde oluşturun:

• Tek bir RI bloğu oluşturun (RI blok frag alanında 1’in 0’ıncı fragmanı). RI blok fragmantasyonu kullanmıyoruz, bu aynı problemin alternatif bir çözüm yöntemiydi.
• RI bloğu ve dahil edilecek diğer bloklar ile bir “jumbo” payload oluşturun
• Toplam veri boyutunu hesaplayın (header dahil değil), bu payload boyutu + statik anahtar ve iki MAC için 64 bayttır
• Her pakette mevcut alanı hesaplayın, bu MTU eksi IP header (20 veya 40), eksi UDP header (8), eksi SSU2 kısa header (16). Paket başına toplam overhead 44 (IPv4) veya 64 (IPv6)‘dır.
• Paket sayısını hesaplayın.
• Son paketteki verinin boyutunu hesaplayın. Header şifrelemenin çalışması için 24 bayt veya daha büyük olmalıdır. Çok küçükse, ya bir padding bloğu ekleyin, YA da zaten mevcutsa padding bloğunun boyutunu artırın, YA DA diğer paketlerden birinin boyutunu azaltın ki son paket yeterince büyük olsun.
• İlk paket için şifrelenmemiş header oluşturun, frag alanında toplam fragment sayısı ile, ve “jumbo” payload’ı Noise ile şifreleyin, header’ı AD olarak kullanarak, her zamanki gibi.
• Şifrelenmiş jumbo paketi fragmentlara bölün
• Her 1-n fragmenti için şifrelenmemiş header ekleyin
• Her 0-n fragmenti için header’ı şifreleyin. Her header yukarıda Session Confirmed KDF’de tanımlandığı gibi AYNI k_header_1 ve k_header_2’yi kullanır.
• Tüm fragmentları iletin

Yeniden birleştirme süreci:

Bob herhangi bir Session Confirmed mesajı aldığında, başlığın şifresini çözer, frag alanını inceler ve Session Confirmed’ın parçalanmış olduğunu belirler. Tüm parçalar alınıp yeniden birleştirilene kadar mesajın şifresini çözmez (ve çözemez).

• Fragment 0 için başlığı koruyun, çünkü Noise AD olarak kullanılır
• Yeniden birleştirmeden önce diğer fragmentlerin başlıklarını atın
• Fragment 0’ın başlığı AD olarak kullanılarak “jumbo” yükünü yeniden birleştirin ve Noise ile şifrelerini çözün
• RI bloğunu her zamanki gibi doğrulayın
• Veri aşamasına geçin ve her zamanki gibi ACK 0 gönderin

Bob’un tek tek parçaları onaylaması için bir mekanizma yoktur. Bob tüm parçaları aldığında, yeniden birleştirdiğinde, şifrelerini çözdüğünde ve içeriği doğruladığında, Bob normal şekilde split() işlemini yapar, veri fazına girer ve 0 numaralı paketin ACK’ini gönderir.

Alice, paket numarası 0’ın ACK’sini almazsa, tüm oturum onaylanmış paketleri olduğu gibi yeniden iletmelidir.

Örnekler:

IPv6 üzerinde 1500 MTU için maksimum payload 1372’dir, RI blok overhead’i 5’tir, maksimum (gzip sıkıştırılmış) RI veri boyutu 1367’dir (başka blok olmadığı varsayımıyla). İki paket ile, 2. paketin overhead’i 64’tür, bu nedenle 1436 byte daha payload taşıyabilir. Bu yüzden iki paket, 2803 byte’a kadar sıkıştırılmış bir RI için yeterlidir.

Mevcut ağda görülen en büyük sıkıştırılmış RI yaklaşık 1400 bayttır; bu nedenle pratikte, minimum 1280 MTU ile bile iki parça yeterli olmalıdır. Protokol maksimum 15 parçaya izin verir.

Güvenlik analizi:

Parçalanmış bir Session Confirmed’ın bütünlüğü ve güvenliği, parçalanmamış olanla aynıdır. Herhangi bir parçada yapılacak herhangi bir değişiklik, yeniden birleştirmeden sonra Noise AEAD’in başarısız olmasına neden olacaktır. Fragment 0’dan sonraki parçaların başlıkları yalnızca parçayı tanımlamak için kullanılır. Yol üzerindeki bir saldırgan başlığı şifrelemek için kullanılan k_header_2 anahtarına sahip olsa bile (olasılık düşük, handshake’den türetilir), bu saldırganın geçerli bir parçayı yerine koymasına izin vermez.

KDF for data phase

Veri aşaması, ilişkili veri için başlığı kullanır.

KDF, zincir anahtarı ck’den iki şifre anahtarı k_ab ve k_ba üretir, RFC 2104’te tanımlanan HMAC-SHA256(key, data) kullanarak. Bu, Noise spesifikasyonunda tam olarak tanımlandığı gibi split() fonksiyonudur.

// split()
  // chainKey = from handshake phase
  keydata = HKDF(chainKey, ZEROLEN, "", 64)
  k_ab = keydata[0:31]
  k_ba = keydata[32:63]

  // key is k_ab for Alice to Bob
  // key is k_ba for Bob to Alice

  keydata = HKDF(key, ZEROLEN, "HKDFSSU2DataKeys", 64)
  k_data = keydata[0:31]
  k_header_2 = keydata[32:63]


  // AEAD parameters
  k = k_data
  n = 4 byte packet number from header
  ad = 16 byte header, before header encryption
  ciphertext = ENCRYPT(k, n, payload, ad)

  // Header encryption keys for data phase
  // aik = Alice's intro key
  // bik = Bob's intro key
  k_header_1 = Receiver's intro key (aik or bik)
  k_header_2: from above

Data Message (Type 6)

Noise payload: Tüm blok türlerine izin verilir Maksimum payload boyutu: MTU - 60 (IPv4) veya MTU - 80 (IPv6). 1500 MTU için: Maksimum payload 1440 (IPv4) veya 1420 (IPv6).

Session Confirmed’in 2. bölümünden başlayarak, tüm mesajlar kimlik doğrulamalı ve şifrelenmiş bir ChaChaPoly yükünün içindedir. Tüm dolgu mesajın içindedir. Yükün içinde sıfır veya daha fazla “blok” içeren standart bir format bulunur. Her blok bir baytlık tür ve iki baytlık uzunluğa sahiptir. Türler arasında tarih/saat, I2NP mesajı, seçenekler, sonlandırma ve dolgu yer alır.

Not: Bob, veri aşamasında Alice’e göndereceği ilk mesaj olarak RouterInfo’sunu gönderebilir, ancak bunu yapmak zorunda değildir.

Payload Güvenlik Özellikleri:

XK(s, rs):           Authentication   Confidentiality
    <-                        2                5
    ->                        2                5

    Authentication: 2.
    Sender authentication resistant to key-compromise impersonation (KCI).
    The sender authentication is based on an ephemeral-static DH ("es" or "se")
    between the sender's static key pair and the recipient's ephemeral key pair.
    Assuming the corresponding private keys are secure, this authentication cannot be forged.

    Confidentiality: 5.
    Encryption to a known recipient, strong forward secrecy.
    This payload is encrypted based on an ephemeral-ephemeral DH as well as
    an ephemeral-static DH with the recipient's static key pair.
    Assuming the ephemeral private keys are secure, and the recipient is not being actively impersonated
    by an attacker that has stolen its static private key, this payload cannot be decrypted.

Notes

• Router, AEAD hatası olan bir mesajı düşürmek zorundadır.

+----+----+----+----+----+----+----+----+
  |  Short Header 16 bytes, ChaCha20      |
  +  encrypted with intro key and         +
  |  derived key, see Data Phase KDF      |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 data                       |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in Data Phase KDF          +
  |  n = packet number from header        |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Şifrelenmemiş veri (Poly1305 auth etiketi gösterilmemiş):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type|    flags     |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |                                       |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: As specified in session setup

  Packet Number :: 4 byte big endian integer

  type :: 6

  flags :: 3 bytes, unused, set to 0 for future compatibility

Notes

• Minimum yük boyutu 8 bayttır. Bu gereklilik herhangi bir ACK, I2NP, First Fragment veya Follow-on Fragment bloğu tarafından karşılanacaktır. Eğer gereklilik karşılanmazsa, bir Padding bloğu dahil edilmelidir.

• Her paket numarası yalnızca bir kez kullanılabilir. I2NP mesajları veya fragmanları yeniden iletilirken, yeni bir paket numarası kullanılmalıdır.

KDF for Peer Test

// AEAD parameters
  // bik = Bob's intro key
  k = bik
  n = 4 byte packet number from header
  ad = 32 byte header, before header encryption
  ciphertext = ENCRYPT(k, n, payload, ad)

  // Header encryption keys for this message
  k_header_1 = bik
  k_header_2 = bik

Peer Test (Type 7)

Charlie, Alice’e gönderir ve Alice, Charlie’ye gönderir, yalnızca Peer Test aşamaları 5-7 için. Peer Test aşamaları 1-4, bir Data mesajındaki Peer Test bloğu kullanılarak oturum içinde gönderilmelidir. Daha fazla bilgi için aşağıdaki Peer Test Block ve Peer Test Process bölümlerine bakınız.

Boyut: 48 + payload boyutu.

Noise payload: Aşağıya bakın.

Ham içerikler:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Alice or Charlie      +
  |  intro key                            |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Alice or Charlie      +
  |  intro key                            |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data             |
  +          (length varies)              +
  |                                       |
  +  see KDF for key and n                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Şifrelenmemiş veri (Poly1305 kimlik doğrulama etiketi gösterilmiyor):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |    ChaCha20 payload (block data)      |
  +          (length varies)              +
  |    see below for allowed blocks       |
  +----+----+----+----+----+----+----+----+


  Destination Connection ID :: See below

  type :: 7

  ver :: 2

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Packet Number :: Random number generated by Alice or Charlie

  Source Connection ID :: See below

  Token :: Randomly generated by Alice or Charlie, ignored

Uzun Başlık

• DateTime bloğu
• Adres bloğu (mesaj 6 ve 7 için gerekli, aşağıdaki nota bakın)
• Peer Test bloğu
• Padding bloğu (isteğe bağlı)

Minimum payload boyutu 8 bayttır. Peer Test bloğu bundan fazla bir toplam boyuta sahip olduğundan, gereksinim yalnızca bu blokla karşılanır.

5 ve 7 numaralı mesajlarda, Peer Test bloğu oturum içi 3 ve 4 numaralı mesajlardaki blok ile aynı olabilir ve Charlie tarafından imzalanan anlaşmayı içerebilir, ya da yeniden oluşturulabilir. İmza isteğe bağlıdır.

Mesaj 6’da, Peer Test bloğu, Alice tarafından imzalanmış isteği içeren oturum içi mesaj 1 ve 2’deki blokla özdeş olabilir veya yeniden oluşturulabilir. İmza isteğe bağlıdır.

Bağlantı ID’leri: İki bağlantı ID’si test nonce değerinden türetilir. Charlie’den Alice’e gönderilen 5 ve 7 numaralı mesajlar için, Hedef Bağlantı ID’si 4-byte big-endian test nonce’unun iki kopyasıdır, yani ((nonce « 32) | nonce). Kaynak Bağlantı ID’si, Hedef Bağlantı ID’sinin tersidir, yani ~((nonce « 32) | nonce). Alice’den Charlie’ye gönderilen 6 numaralı mesaj için, iki bağlantı ID’sini yer değiştirin.

Adres bloğu içerikleri:

• Mesaj 5’te: Gerekli değil.
• Mesaj 6’da: Charlie’nin RI’sinden seçilen Charlie’nin IP’si ve portu.
• Mesaj 7’de: Mesaj 6’nın alındığı Alice’in gerçek IP’si ve portu.

KDF for Retry

Retry mesajının gereksinimi, Bob’un bir Retry mesajı üretmek için Session Request mesajını çözmek zorunda olmamasıdır. Ayrıca, bu mesaj yalnızca simetrik şifreleme kullanarak hızlı bir şekilde üretilmelidir.

// AEAD parameters
  // bik = Bob's intro key
  k = bik
  n = 4 byte packet number from header
  ad = 32 byte header, before header encryption
  ciphertext = ENCRYPT(k, n, payload, ad)

  // Header encryption keys for this message
  k_header_1 = bik
  k_header_2 = bik

Retry (Type 9)

Bob, Alice’e Session Request veya Token Request mesajına yanıt olarak gönderir. Alice yeni bir Session Request ile yanıt verir. Boyut: 48 + payload boyutu.

Ayrıca bir Termination bloğu dahil edilmişse Sonlandırma mesajı (yani, “Yeniden Deneme”) olarak da hizmet eder.

Noise payload: Aşağıya bakın.

Ham içerikler:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key         +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Bob intro key         +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data             |
  +          (length varies)              +
  |                                       |
  +  see KDF for key and n                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Şifrelenmemiş veri (Poly1305 doğrulama etiketi gösterilmemiştir):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |    ChaCha20 payload (block data)      |
  +          (length varies)              +
  |    see below for allowed blocks       |
  +----+----+----+----+----+----+----+----+


  Destination Connection ID :: The Source Connection ID
                               received from Alice in Token Request
                               or Session Request

  Packet Number :: Random number generated by Bob

  type :: 9

  ver :: 2

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: The Destination Connection ID
                          received from Alice in Token Request
                          or Session Request

  Token :: 8 byte unsigned integer, randomly generated by Bob, nonzero,
           or zero if session is rejected and a termination block is included

Kısa Başlık

• DateTime bloğu
• Adres bloğu
• Seçenekler bloğu (isteğe bağlı)
• Sonlandırma bloğu (isteğe bağlı, oturum reddedilirse)
• Dolgu bloğu (isteğe bağlı)

Minimum payload boyutu 8 byte’tır. DateTime ve Address blokları toplamda bundan fazla olduğundan, gereksinim yalnızca bu iki blok ile karşılanır.

Bağlantı ID Numaralandırması

• Probing direncini sağlamak için, bir router yalnızca Request mesajındaki mesaj türü, protokol sürümü ve ağ ID alanları geçerli olmadığı sürece Session Request veya Token Request mesajına yanıt olarak Retry mesajı göndermemelidir.

• Sahte kaynak adresleri kullanılarak gerçekleştirilebilecek herhangi bir amplifikasyon saldırısının büyüklüğünü sınırlamak için, Retry mesajı büyük miktarda padding içermemelidir. Retry mesajının yanıt verdiği mesajın boyutunun üç katından daha büyük olmaması önerilir. Alternatif olarak, 1-64 bayt aralığında rastgele miktarda padding ekleme gibi basit bir yöntem kullanın.

KDF for Token Request

Bu mesaj hızlı üretilmeli ve yalnızca simetrik şifreleme kullanmalıdır.

// AEAD parameters
  // bik = Bob's intro key
  k = bik
  n = 4 byte packet number from header
  ad = 32 byte header, before header encryption
  ciphertext = ENCRYPT(k, n, payload, ad)

  // Header encryption keys for this message
  k_header_1 = bik
  k_header_2 = bik

Token Request (Type 10)

Alice Bob’a gönderir. Bob bir Retry mesajıyla yanıtlar. Boyut: 48 + payload boyutu.

Alice’in geçerli bir token’ı yoksa, Session Request oluşturmadaki asimetrik şifreleme yükünden kaçınmak için Alice Session Request yerine bu mesajı göndermelidir.

Noise payload: Aşağıya bakınız.

Ham içerikler:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key         +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Bob intro key         +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data             |
  +          (length varies)              +
  |                                       |
  +  see KDF for key and n                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Şifrelenmemiş veri (Poly1305 kimlik doğrulama etiketi gösterilmemiştir):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |    ChaCha20 payload (block data)      |
  +          (length varies)              +
  |    see below for allowed blocks       |
  +----+----+----+----+----+----+----+----+


  Destination Connection ID :: Randomly generated by Alice

  Packet Number :: Random number generated by Alice

  type :: 10

  ver :: 2

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: Randomly generated by Alice,
                          must not be equal to Destination Connection ID

  Token :: zero

Paket Numaralandırma

• DateTime bloğu
• Padding bloğu

Minimum payload boyutu 8 bayttır.

Başlık Bağlama

• Yoklama direncini sağlamak için, bir router yalnızca Token Request mesajındaki mesaj türü, protokol sürümü ve ağ kimliği alanları geçerli olmadıkça bir Token Request mesajına yanıt olarak Retry mesajı göndermemelidir.

• Bu standart bir Noise mesajı DEĞİLDIR ve el sıkışmanın bir parçası değildir. Bağlantı ID’leri dışında Session Request mesajına bağlı değildir.

• Çoğu hatada, AEAD dahil olmak üzere veya belirgin tekrar saldırılarında Bob daha fazla mesaj işlemeyi durdurmalı ve yanıt vermeden mesajı bırakmalıdır.

• Bob, zaman damgası değerinin mevcut zamandan çok uzak olduğu bağlantıları reddetmelidir. Maksimum delta zamanını “D” olarak adlandırın. Bob, daha önce kullanılmış handshake değerlerinin yerel bir önbelleğini tutmalı ve tekrar saldırılarını önlemek için kopyaları reddetmelidir. Önbellekteki değerler en az 2*D ömre sahip olmalıdır. Önbellek değerleri implementasyona bağlıdır, ancak 32-byte X değeri (veya şifrelenmiş eşdeğeri) kullanılabilir.

• Bob, DateTime bloğundaki zaman damgası çok fazla sapmışsa, sıfır token içeren bir Retry mesajı ve saat sapması neden kodu ile bir Termination bloğu GÖNDEREBİLİR.

• Minimum boyut: TBD, Session Created ile aynı kurallar mı?

KDF for Hole Punch

Bu mesaj sadece simetrik şifreleme kullanarak hızlı bir şekilde oluşturulmalıdır.

// AEAD parameters
  // aik = Alice's intro key
  k = aik
  n = 4 byte packet number from header
  ad = 32 byte header, before header encryption
  ciphertext = ENCRYPT(k, n, payload, ad)

  // Header encryption keys for this message
  k_header_1 = aik
  k_header_2 = aik

Hole Punch (Type 11)

Charlie, Bob’dan alınan bir Relay Intro’ya yanıt olarak Alice’e gönderir. Alice yeni bir Session Request ile yanıt verir. Boyut: 48 + payload boyutu.

Noise payload: Aşağıya bakın.

Ham içerik:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Alice intro key       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Alice intro key       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data             |
  +          (length varies)              +
  |                                       |
  +  see KDF for key and n                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Şifrelenmemiş veri (Poly1305 kimlik doğrulama etiketi gösterilmemiş):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |    ChaCha20 payload (block data)      |
  +          (length varies)              +
  |    see below for allowed blocks       |
  +----+----+----+----+----+----+----+----+


  Destination Connection ID :: See below

  Packet Number :: Random number generated by Charlie

  type :: 11

  ver :: 2

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: See below

  Token :: 8 byte unsigned integer, randomly generated by Charlie, nonzero.

Başlık Şifreleme

• DateTime blok
• Address blok
• Relay Response blok
• Padding blok (isteğe bağlı)

Minimum payload boyutu 8 bayttır. DateTime ve Address blokları toplamda bundan fazla olduğundan, gereksinim yalnızca bu iki blokla karşılanır.

Bağlantı ID’leri: İki bağlantı ID’si relay nonce’ından türetilir. Destination Connection ID, 4-byte’lık big-endian relay nonce’ının iki kopyasıdır, yani ((nonce « 32) | nonce). Source Connection ID ise Destination Connection ID’nin tersidir, yani ~((nonce « 32) | nonce).

Alice, başlıktaki token’ı görmezden gelmelidir. Session Request’te kullanılacak token, Relay Response bloğunda bulunmaktadır.

Noise Payload

Her Noise payload’ı sıfır veya daha fazla “blok” içerir.

Bu, NTCP2 ve ECIES spesifikasyonlarında tanımlanan aynı blok formatını kullanır. Bireysel blok türleri farklı şekilde tanımlanır. QUIC RFC 9000‘de karşılık gelen terim “frames”‘dir.

Uygulayıcıları kod paylaşmaya teşvik etmenin ayrıştırma sorunlarına yol açabileceği endişeleri bulunmaktadır. Uygulayıcılar kod paylaşmanın faydalarını ve risklerini dikkatle değerlendirmeli ve iki bağlam için sıralama ve geçerli blok kurallarının farklı olduğundan emin olmalıdır.

Güvenlik Değerlendirmeleri

Şifrelenmiş yük içinde bir veya daha fazla blok bulunur. Bir blok basit bir Tag-Length-Value (TLV) formatıdır. Her blok bir byte’lık tanımlayıcı, iki byte’lık uzunluk ve sıfır veya daha fazla byte veri içerir. Bu format NTCP2 ve ECIES ile aynıdır, ancak blok tanımları farklıdır.

Genişletilebilirlik için, alıcılar bilinmeyen tanımlayıcılara sahip blokları yok saymalı ve bunları dolgu olarak ele almalıdır.

(Poly1305 kimlik doğrulama etiketi gösterilmedi):

+----+----+----+----+----+----+----+----+
  |blk |  size   |       data             |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  |blk |  size   |       data             |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  ~               .   .   .               ~

  blk :: 1 byte, see below
  size :: 2 bytes, big endian, size of data to follow, 0 - TBD
  data :: the data

Header şifreleme, iki ChaCha20 işlemi için IV olarak paketin son 24 baytını kullanır. Tüm paketler 16 baytlık bir MAC ile bittiğinden, bu durum tüm paket yüklerinin minimum 8 bayt olmasını gerektirir. Bir yük bu gereksinimi karşılamıyorsa, bir Padding bloğu dahil edilmelidir.

Maksimum ChaChaPoly yük boyutu mesaj türü, MTU ve IPv4 veya IPv6 adres türüne bağlı olarak değişir. Maksimum yük boyutu IPv4 için MTU - 60 ve IPv6 için MTU - 80’dir. Maksimum yük verisi IPv4 için MTU - 63 ve IPv6 için MTU - 83’tür. Üst limit IPv4, 1500 MTU, Data mesajı için yaklaşık 1440 bayttır. Maksimum toplam blok boyutu maksimum yük boyutudur. Maksimum tek blok boyutu maksimum toplam blok boyutudur. Blok türü 1 bayttır. Blok uzunluğu 2 bayttır. Maksimum tek blok veri boyutu maksimum tek blok boyutu eksi 3’tür.

Notlar:

• Uygulayıcılar bir blok okurken, hatalı biçimlendirilmiş veya kötü niyetli verinin okumaların sonraki bloğa veya yük (payload) sınırının ötesine taşmasına neden olmayacağından emin olmalıdır.

• Uygulamalar, ileri uyumluluk için bilinmeyen blok türlerini görmezden gelmelidir.

Blok türleri:

Block Ordering Rules

Session Confirmed’da, Router Info ilk blok olmalıdır.

Diğer tüm mesajlarda sıralama belirtilmemiştir, aşağıdaki gereksinimler dışında: Padding (doldurma), mevcut ise, son blok olmalıdır. Termination (sonlandırma), mevcut ise, Padding dışında son blok olmalıdır. Tek bir payload içinde birden fazla Padding bloğuna izin verilmez.

Block Specifications

Başlık Şifreleme KDF

Zaman senkronizasyonu için:

+----+----+----+----+----+----+----+
  | 0  |    4    |     timestamp     |
  +----+----+----+----+----+----+----+

  blk :: 0
  size :: 2 bytes, big endian, value = 4
  timestamp :: Unix timestamp, unsigned seconds.
               Wraps around in 2106

Notlar:

• SSU 1’den farklı olarak, SSU 2’de veri aşaması için paket başlığında zaman damgası bulunmaz.
• Uygulamalar veri aşamasında düzenli olarak DateTime blokları göndermelidir.
• Uygulamalar ağda saat sapmasını önlemek için en yakın saniyeye yuvarlama yapmalıdır.

Başlık Doğrulaması

Güncellenmiş seçenekleri geçirin. Seçenekler şunları içerir: Minimum ve maksimum padding.

Seçenekler bloğu değişken uzunlukta olacaktır.

+----+----+----+----+----+----+----+----+
  | 1  |  size   |tmin|tmax|rmin|rmax|tdmy|
  +----+----+----+----+----+----+----+----+
  |tdmy|  rdmy   |  tdelay |  rdelay |    |
  ~----+----+----+----+----+----+----+    ~
  |              more_options             |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 1
  size :: 2 bytes, big endian, size of options to follow, 12 bytes minimum

  tmin, tmax, rmin, rmax :: requested padding limits
      tmin and rmin are for desired resistance to traffic analysis.
      tmax and rmax are for bandwidth limits.
      tmin and tmax are the transmit limits for the router sending this options block.
      rmin and rmax are the receive limits for the router sending this options block.
      Each is a 4.4 fixed-point float representing 0 to 15.9375
      (or think of it as an unsigned 8-bit integer divided by 16.0).
      This is the ratio of padding to data. Examples:
      Value of 0x00 means no padding
      Value of 0x01 means add 6 percent padding
      Value of 0x10 means add 100 percent padding
      Value of 0x80 means add 800 percent (8x) padding
      Alice and Bob will negotiate the minimum and maximum in each direction.
      These are guidelines, there is no enforcement.
      Sender should honor receiver's maximum.
      Sender may or may not honor receiver's minimum, within bandwidth constraints.

  tdmy: Max dummy traffic willing to send, 2 bytes big endian, bytes/sec average
  rdmy: Requested dummy traffic, 2 bytes big endian, bytes/sec average
  tdelay: Max intra-message delay willing to insert, 2 bytes big endian, msec average
  rdelay: Requested intra-message delay, 2 bytes big endian, msec average

  Padding distribution specified as additional parameters?
  Random delay specified as additional parameters?

  more_options :: Format TBD

Seçenek Sorunları:

• Seçenekler müzakeresi TBD.

RouterInfo

Alice’in RouterInfo’sunu Bob’a ilet. Yalnızca Session Confirmed bölüm 2 payload’ında kullanılır. Veri aşamasında kullanılmamalıdır; bunun yerine bir I2NP DatabaseStore Mesajı kullanın.

Minimum Boyut: Yaklaşık 420 bayt, ancak router info içindeki router kimliği ve imzası sıkıştırılabilir ise, ki bu pek olası değildir.

NOT: Router Info bloğu asla fragmente edilmez. frag alanı her zaman 0/1’dir. Daha fazla bilgi için yukarıdaki Session Confirmed Fragmentation bölümüne bakın.

+----+----+----+----+----+----+----+----+
  | 2  |  size   |flag|frag|              |
  +----+----+----+----+----+              +
  |                                       |
  +       Router Info fragment            +
  | (Alice RI in Session Confirmed)       |
  + (Alice, Bob, or third-party           +
  |  RI in data phase)                    |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 2
  size :: 2 bytes, big endian, 2 + fragment size
  flag :: 1 byte flags
         bit order: 76543210 (bit 7 is MSB)
         bit 0: 0 for local store, 1 for flood request
         bit 1: 0 for uncompressed, 1 for gzip compressed
         bits 7-2: Unused, set to 0 for future compatibility
  frag :: 1 byte fragment info:
         bit order: 76543210 (bit 7 is MSB)
         bits 7-4: fragment number, always 0
         bits 3-0: total fragments, always 1, big endian

  routerinfo :: Alice's or Bob's RouterInfo

Notlar:

• Router Info isteğe bağlı olarak gzip ile sıkıştırılır, bu flag bit 1 ile belirtilir. Bu, hiçbir zaman sıkıştırılmadığı NTCP2’den ve her zaman sıkıştırıldığı DatabaseStore Message’dan farklıdır. Sıkıştırma isteğe bağlıdır çünkü genellikle sıkıştırılabilir içeriğin az olduğu küçük Router Info’lar için çok az fayda sağlar, ancak birkaç sıkıştırılabilir Router Address içeren büyük Router Info’lar için çok faydalıdır. Sıkıştırma, bir Router Info’nun parçalama olmadan tek bir Session Confirmed paketine sığmasını sağlıyorsa önerilir.

• Session Confirmed mesajındaki ilk veya tek fragmentin maksimum boyutu: IPv4 için MTU - 113 veya IPv6 için MTU - 133. 1500 bayt varsayılan MTU’yu ve mesajda başka blok bulunmadığını varsayarsak, IPv4 için 1387 veya IPv6 için 1367. Mevcut router info’ların %97’si gzipleme olmadan 1367’den küçüktür. Mevcut router info’ların %99.9’u gziplendiğinde 1367’den küçüktür. 1280 bayt minimum MTU’yu ve mesajda başka blok bulunmadığını varsayarsak, IPv4 için 1167 veya IPv6 için 1147. Mevcut router info’ların %94’ü gzipleme olmadan 1147’den küçüktür. Mevcut router info’ların %97’si gziplendiğinde 1147’den küçüktür.

• Frag baytı artık kullanılmıyor, Router Info bloğu asla parçalanmıyor. Frag baytı parça 0, toplam parça 1 olarak ayarlanmalıdır. Daha fazla bilgi için yukarıdaki Session Confirmed Fragmentation bölümüne bakın.

• Flooding, RouterInfo içinde yayınlanmış RouterAddress’ler olmadıkça talep edilmemelidir. Alıcı router, içinde yayınlanmış RouterAddress’ler olmadıkça RouterInfo’yu flood etmemelidir.

• Bu protokol RouterInfo’nun saklandığına veya flood edildiğine dair bir onay sağlamaz. Eğer onay isteniyorsa ve alıcı floodfill ise, gönderen bunun yerine bir reply token ile standart bir I2NP DatabaseStoreMessage göndermelidir.

I2NP Message

Değiştirilmiş başlığa sahip eksiksiz bir I2NP mesajı.

Bu, NTCP2 ile aynı 9 bayt I2NP başlığını kullanır (tip, mesaj kimliği, kısa süre sonu).

+----+----+----+----+----+----+----+----+
  | 3  |  size   |type|    msg id         |
  +----+----+----+----+----+----+----+----+
  |   short exp       |     message       |
  +----+----+----+----+                   +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 3
  size :: 2 bytes, big endian, size of type + msg id + exp + message to follow
          I2NP message body size is (size - 9).
  type :: 1 byte, I2NP msg type, see I2NP spec
  msg id :: 4 bytes, big endian, I2NP message ID
  short exp :: 4 bytes, big endian, I2NP message expiration, Unix timestamp, unsigned seconds.
               Wraps around in 2106
  message :: I2NP message body

Notlar:

• Bu, NTCP2’de kullanılan aynı 9-baytlık I2NP başlık formatıdır.

• Bu, tam olarak İlk Fragment bloğu ile aynı formattadır, ancak blok türü bunun tam bir mesaj olduğunu gösterir.

• 9-baytlık I2NP başlığı dahil maksimum boyut IPv4 için MTU - 63 ve IPv6 için MTU - 83’tür.

ChaCha20/Poly1305

Değiştirilmiş başlığa sahip bir I2NP mesajının ilk parçası (parça #0).

Bu, NTCP2 ile aynı 9 baytlık I2NP başlığını kullanır (tür, mesaj id’si, kısa süre sonu).

Toplam fragment sayısı belirtilmemiş.

+----+----+----+----+----+----+----+----+
  | 4  |  size   |type|    msg id         |
  +----+----+----+----+----+----+----+----+
  |   short exp       |                   |
  +----+----+----+----+                   +
  |          partial message              |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 4
  size :: 2 bytes, big endian, size of data to follow
          Fragment size is (size - 9).
  type :: 1 byte, I2NP msg type, see I2NP spec
  msg id :: 4 bytes, big endian, I2NP message ID
  short exp :: 4 bytes, big endian, I2NP message expiration, Unix timestamp, unsigned seconds.
               Wraps around in 2106
  message :: Partial I2NP message body, bytes 0 - (size - 10)

Notlar:

• Bu, NTCP2’de kullanılan aynı 9-baytlık I2NP başlık formatıdır.

• Bu, I2NP Mesaj bloğu ile tamamen aynı formattadır, ancak blok türü bunun bir mesajın ilk parçası olduğunu belirtir.

• Kısmi mesaj uzunluğu sıfırdan büyük olmalıdır.

• SSU 1’de olduğu gibi, son parçanın ilk olarak gönderilmesi önerilir, böylece alıcı toplam parça sayısını bilir ve alma tamponlarını verimli bir şekilde tahsis edebilir.

• I2NP başlığının 9 baytlık kısmı dahil maksimum boyut IPv4 için MTU - 63 ve IPv6 için MTU - 83’tür.

Notlar

I2NP mesajının ek bir fragmanı (fragment numarası sıfırdan büyük).

+----+----+----+----+----+----+----+----+
  | 5  |  size   |frag|    msg id         |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |          partial message              |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 5
  size :: 2 bytes, big endian, size of data to follow
          Fragment size is (size - 5).
  frag :: Fragment info:
          Bit order: 76543210 (bit 7 is MSB)
          bits 7-1: fragment number 1 - 127 (0 not allowed)
          bit 0: isLast (1 = true)
  msg id :: 4 bytes, big endian, I2NP message ID
  message :: Partial I2NP message body

Notlar:

• Kısmi mesaj uzunluğu sıfırdan büyük olmalıdır.

• SSU 1’de olduğu gibi, son parçanın önce gönderilmesi önerilir, böylece alıcı toplam parça sayısını bilir ve alma tamponlarını verimli bir şekilde tahsis edebilir.

• SSU 1’de olduğu gibi, maksimum fragment numarası 127’dir, ancak pratik sınır 63 veya daha azdır. Uygulamalar maksimumu, yaklaşık 64 KB’lık maksimum I2NP mesaj boyutu için pratik olan değerle sınırlayabilir, bu da 1280 minimum MTU ile yaklaşık 55 fragment’tir. Aşağıdaki Maksimum I2NP Mesaj Boyutu bölümüne bakın.

• Maksimum kısmi mesaj boyutu (frag ve mesaj id dahil değil) IPv4 için MTU - 68 ve IPv6 için MTU - 88’dir.

AEAD Hata İşleme

Bağlantıyı kes. Bu, yükteki son padding olmayan blok olmalıdır.

+----+----+----+----+----+----+----+----+
  | 6  |  size   |    valid data packets  |
  +----+----+----+----+----+----+----+----+
      received   | rsn|     addl data     |
  +----+----+----+----+                   +
  ~               .   .   .               ~
  +----+----+----+----+----+----+----+----+

  blk :: 6
  size :: 2 bytes, big endian, value = 9 or more
  valid data packets received :: The number of valid packets received
                                (current receive nonce value)
                                0 if error occurs in handshake phase
                                8 bytes, big endian
  rsn :: reason, 1 byte:
         0: normal close or unspecified
         1: termination received
         2: idle timeout
         3: router shutdown
         4: data phase AEAD failure
         5: incompatible options
         6: incompatible signature type
         7: clock skew
         8: padding violation
         9: AEAD framing error
         10: payload format error
         11: Session Request error
         12: Session Created error
         13: Session Confirmed error
         14: Timeout
         15: RI signature verification fail
         16: s parameter missing, invalid, or mismatched in RouterInfo
         17: banned
         18: bad token
         19: connection limits
         20: incompatible version
         21: wrong net ID
         22: replaced by new session
  addl data :: optional, 0 or more bytes, for future expansion, debugging,
               or reason text.
               Format unspecified and may vary based on reason code.

Notlar:

• Tüm nedenler gerçekte kullanılmayabilir, uygulama bağımlıdır. Çoğu başarısızlık genellikle mesajın düşürülmesiyle sonuçlanır, sonlandırma ile değil. Yukarıdaki handshake mesaj bölümlerindeki notlara bakın. Listelenen ek nedenler tutarlılık, kayıt tutma, hata ayıklama veya politika değişiklikleri içindir.
• Termination bloğu ile birlikte bir ACK bloğunun dahil edilmesi önerilir.
• Veri aşamasında, “termination received” dışındaki herhangi bir nedenle, eş “termination received” nedeniyle bir termination bloğu ile yanıt vermelidir.

RelayRequest

Alice’den Bob’a, oturum içinde bir Data mesajında gönderilir. Aşağıdaki Relay Process bölümüne bakın.

+----+----+----+----+----+----+----+----+
  |  7 |  size   |flag|       nonce       |
  +----+----+----+----+----+----+----+----+
  |     relay tag     |     timestamp     |
  +----+----+----+----+----+----+----+----+
  | ver| asz|AlicePort|  Alice IP address |
  +----+----+----+----+----+----+----+----+
  |              signature                |
  +            length varies              +
  |         64 bytes for Ed25519          |
  ~                                       ~
  |                 . . .                 |
  +----+----+----+----+----+----+----+----+

  blk :: 7
  size :: 2 bytes, big endian, size of data to follow
  flag :: 1 byte flags, Unused, set to 0 for future compatibility

  The data below here is covered
  by the signature, and Bob forwards it unmodified.

  nonce :: 4 bytes, randomly generated by Alice
  relay tag :: 4 bytes, the itag from Charlie's RI
  timestamp :: Unix timestamp, unsigned seconds.
               Wraps around in 2106
  ver ::  1 byte SSU version to be used for the introduction:
         1: SSU 1
         2: SSU 2
  asz :: 1 byte endpoint (port + IP) size (6 or 18)
  AlicePort :: 2 byte Alice's port number, big endian
  Alice IP :: (asz - 2) byte representation of Alice's IP address,
              network byte order
  signature :: length varies, 64 bytes for Ed25519.
               Signature of prologue, Bob's hash,
               and signed data above, as signed by
               Alice.

Notlar:

• IP adresi her zaman dahil edilir (SSU 1’den farklı olarak) ve oturum için kullanılan IP’den farklı olabilir.

İmza:

Alice isteği imzalar ve bu bloka dahil eder; Bob bunu Relay Intro bloğunda Charlie’ye iletir. İmza algoritması: Aşağıdaki veriyi Alice’in router imzalama anahtarı ile imzalayın:

• prologue: 16 bayt “RelayRequestData”, null ile sonlandırılmaz (mesajda dahil değil)
• bhash: Bob’un 32-bayt router hash’i (mesajda dahil değil)
• chash: Charlie’nin 32-bayt router hash’i (mesajda dahil değil)
• nonce: 4 bayt nonce
• relay tag: 4 bayt relay tag
• timestamp: 4 bayt timestamp (saniye)
• ver: 1 bayt SSU sürümü
• asz: 1 bayt endpoint (port + IP) boyutu (6 veya 18)
• AlicePort: 2 bayt Alice’in port numarası
• Alice IP: (asz - 2) bayt Alice IP adresi

İlk ChainKey için KDF

Oturum içinde bir Data mesajında, Charlie’den Bob’a veya Bob’dan Alice’e VE Charlie’den Alice’e gönderilen Hole Punch mesajında gönderilir. Aşağıdaki Relay Process bölümüne bakın.

+----+----+----+----+----+----+----+----+
  |  8 |  size   |flag|code|    nonce
  +----+----+----+----+----+----+----+----+
       |     timestamp     | ver| csz|Char
  +----+----+----+----+----+----+----+----+
   Port|   Charlie IP addr |              |
  +----+----+----+----+----+              +
  |              signature                |
  +            length varies              +
  |         64 bytes for Ed25519          |
  ~                                       ~
  |                 . . .                 |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+

  blk :: 8
  size :: 2 bytes, 6
  flag :: 1 byte flags, Unused, set to 0 for future compatibility
  code :: 1 byte status code:
         0: accept
         1: rejected by Bob, reason unspecified
         2: rejected by Bob, Charlie is banned
         3: rejected by Bob, limit exceeded
         4: rejected by Bob, signature failure
         5: rejected by Bob, relay tag not found
         6: rejected by Bob, Alice RI not found
         7-63: other rejected by Bob codes TBD
         64: rejected by Charlie, reason unspecified
         65: rejected by Charlie, unsupported address
         66: rejected by Charlie, limit exceeded
         67: rejected by Charlie, signature failure
         68: rejected by Charlie, Alice is already connected
         69: rejected by Charlie, Alice is banned
         70: rejected by Charlie, Alice is unknown
         71-127: other rejected by Charlie codes TBD
         128: reject, source and reason unspecified
         129-255: other reject codes TBD

  The data below is covered by the signature if the code is 0 (accept).
  Bob forwards it unmodified.

  nonce :: 4 bytes, as received from Bob or Alice

  The data below is present only if the code is 0 (accept).

  timestamp :: Unix timestamp, unsigned seconds.
               Wraps around in 2106
  ver ::  1 byte SSU version to be used for the introduction:
         1: SSU 1
         2: SSU 2
  csz :: 1 byte endpoint (port + IP) size (0 or 6 or 18)
         may be 0 for some rejection codes
  CharliePort :: 2 byte Charlie's port number, big endian
                 not present if csz is 0
  Charlie IP :: (csz - 2) byte representation of Charlie's IP address,
                network byte order
                not present if csz is 0
  signature :: length varies, 64 bytes for Ed25519.
               Signature of prologue, Bob's hash,
               and signed data above, as signed by
               Charlie.
               Not present if rejected by Bob.
  token :: Token generated by Charlie for Alice to use
           in the Session Request.
           Only present if code is 0 (accept)

Notlar:

Token, Alice tarafından Session Request’te derhal kullanılmalıdır.

İmza:

Charlie kabul ederse (yanıt kodu 0) veya reddederse (yanıt kodu 64 veya daha yüksek), Charlie yanıtı imzalar ve bu bloğa dahil eder; Bob bunu Relay Response bloğunda Alice’e iletir. İmza algoritması: Aşağıdaki veriyi Charlie’nin router imzalama anahtarı ile imzala:

• prologue: 16 bayt “RelayAgreementOK”, null ile sonlandırılmaz (mesaja dahil değil)
• bhash: Bob’un 32-baytlık router hash’i (mesaja dahil değil)
• nonce: 4 bayt nonce
• timestamp: 4 bayt zaman damgası (saniye)
• ver: 1 bayt SSU sürümü
• csz: 1 bayt uç nokta (port + IP) boyutu (0 veya 6 veya 18)
• CharliePort: 2 bayt Charlie’nin port numarası (csz 0 ise mevcut değil)
• Charlie IP: (csz - 2) bayt Charlie IP adresi (csz 0 ise mevcut değil)

Bob reddederse (yanıt kodu 1-63), Bob yanıtı imzalar ve bu bloğa dahil eder. İmza algoritması: Aşağıdaki veriyi Bob’un router imzalama anahtarı ile imzalayın:

• prologue: 16 bayt “RelayAgreementOK”, null ile sonlandırılmamış (mesajda yer almaz)
• bhash: Bob’un 32-baytlık router hash’i (mesajda yer almaz)
• nonce: 4 bayt nonce
• timestamp: 4 bayt zaman damgası (saniye)
• ver: 1 bayt SSU sürümü
• csz: 1 bayt = 0

Oturum İsteği için KDF

Oturum içinde Bob’dan Charlie’ye Data mesajında gönderilir. Aşağıdaki Relay Process bölümüne bakın.

Bir RouterInfo bloğu veya Alice’in Router Info bilgilerini içeren I2NP DatabaseStore mesaj bloğu (veya parçası) tarafından öncülenmeli, aynı payload içinde (yer varsa) veya önceki bir mesajda bulunmalı.

+----+----+----+----+----+----+----+----+
  |  9 |  size   |flag|                   |
  +----+----+----+----+                   +
  |                                       |
  +                                       +
  |         Alice Router Hash             |
  +             32 bytes                  +
  |                                       |
  +                   +----+----+----+----+
  |                   |      nonce        |
  +----+----+----+----+----+----+----+----+
  |     relay tag     |     timestamp     |
  +----+----+----+----+----+----+----+----+
  | ver| asz|AlicePort|  Alice IP address |
  +----+----+----+----+----+----+----+----+
  |              signature                |
  +            length varies              +
  |         64 bytes for Ed25519          |
  ~                                       ~
  |                 . . .                 |
  +----+----+----+----+----+----+----+----+

  blk :: 9
  size :: 2 bytes, big endian, size of data to follow
  flag :: 1 byte flags, Unused, set to 0 for future compatibility
  hash :: Alice's 32-byte router hash,

  The data below here is covered
  by the signature, as received from Alice in the Relay Request,
  and Bob forwards it unmodified.

  nonce :: 4 bytes, as received from Alice
  relay tag :: 4 bytes, the itag from Charlie's RI
  timestamp :: Unix timestamp, unsigned seconds.
               Wraps around in 2106
  ver ::  1 byte SSU version to be used for the introduction:
         1: SSU 1
         2: SSU 2
  asz :: 1 byte endpoint (port + IP) size (6 or 18)
  AlicePort :: 2 byte Alice's port number, big endian
  Alice IP :: (asz - 2) byte representation of Alice's IP address,
              network byte order
  signature :: length varies, 64 bytes for Ed25519.
               Signature of prologue, Bob's hash,
               and signed data above, as signed by
               Alice.

Notlar:

• IPv4 için Alice’in IP adresi her zaman 4 byte’tır, çünkü Alice IPv4 üzerinden Charlie’ye bağlanmaya çalışmaktadır. IPv6 desteklenmektedir ve Alice’in IP adresi 16 byte olabilir.

• IPv4 için, bu mesaj kurulmuş bir IPv4 bağlantısı üzerinden gönderilmelidir, çünkü Bob’un Charlie’nin IPv4 adresini bilip RelayResponse_ içinde Alice’e geri döndürebilmesinin tek yolu budur. IPv6 desteklenir ve bu mesaj kurulmuş bir IPv6 bağlantısı üzerinden gönderilebilir.

• Introducers ile yayınlanan herhangi bir SSU adresi “caps” seçeneğinde “4” veya “6” içermelidir.

İmza:

Alice isteği imzalar ve Bob bunu bu blokta Charlie’ye iletir. Doğrulama algoritması: Aşağıdaki verileri Alice’in router imzalama anahtarı ile doğrulayın:

• prologue: 16 bayt “RelayRequestData”, null ile sonlandırılmamış (mesaja dahil değil)
• bhash: Bob’un 32 baytlık router hash’i (mesaja dahil değil)
• chash: Charlie’nin 32 baytlık router hash’i (mesaja dahil değil)
• nonce: 4 bayt nonce
• relay tag: 4 bayt relay tag
• timestamp: 4 bayt zaman damgası (saniye)
• ver: 1 bayt SSU sürümü
• asz: 1 bayt endpoint (port + IP) boyutu (6 veya 18)
• AlicePort: 2 bayt Alice’in port numarası
• Alice IP: (asz - 2) bayt Alice IP adresi

PeerTest

Oturum içinde bir Data mesajında veya oturum dışında bir Peer Test mesajında gönderilir. Aşağıdaki Peer Test Process bölümüne bakın.

Mesaj 2 için, Alice’in Router Info’sunu içeren bir RouterInfo bloğu veya I2NP DatabaseStore mesaj bloğu (veya fragment) ile önceden gelmiş olmalıdır; bu blok ya aynı payload içinde (yer varsa) ya da önceki bir mesajda bulunmalıdır.

Mesaj 4 için, relay kabul edilirse (sebep kodu 0), öncesinde Charlie’nin Router Info’sunu içeren bir RouterInfo bloğu veya I2NP DatabaseStore mesaj bloğu (veya fragmanı) bulunmalıdır; bu bilgi aynı payload içinde (yer varsa) veya önceki bir mesajda yer alabilir.

+----+----+----+----+----+----+----+----+
  | 10 |  size   | msg|code|flag|         |
  +----+----+----+----+----+----+         +
  | Alice router hash (message 2 only)    |
  +             or                        +
  | Charlie router hash (message 4 only)  |
  + or all zeros if rejected by Bob       +
  | Not present in messages 1,3,5,6,7     |
  +                             +----+----+
  |                             | ver|
  +----+----+----+----+----+----+----+----+
     nonce       |     timestamp     | asz|
  +----+----+----+----+----+----+----+----+
  |AlicePort|  Alice IP address |         |
  +----+----+----+----+----+----+         +
  |              signature                |
  +            length varies              +
  |         64 bytes for Ed25519          |
  ~                                       ~
  |                 . . .                 |
  +----+----+----+----+----+----+----+----+

  blk :: 10
  size :: 2 bytes, big endian, size of data to follow
  msg :: 1 byte message number 1-7
  code :: 1 byte status code:
         0: accept
         1: rejected by Bob, reason unspecified
         2: rejected by Bob, no Charlie available
         3: rejected by Bob, limit exceeded
         4: rejected by Bob, signature failure
         5: rejected by Bob, address unsupported
         6-63: other rejected by Bob codes TBD
         64: rejected by Charlie, reason unspecified
         65: rejected by Charlie, unsupported address
         66: rejected by Charlie, limit exceeded
         67: rejected by Charlie, signature failure
         68: rejected by Charlie, Alice is already connected
         69: rejected by Charlie, Alice is banned
         70: rejected by Charlie, Alice is unknown
         70-127: other rejected by Charlie codes TBD
         128: reject, source and reason unspecified
         129-255: other reject codes TBD
         reject codes only allowed in messages 3 and 4
  flag :: 1 byte flags, Unused, set to 0 for future compatibility
  hash :: Alice's or Charlie's 32-byte router hash,
          only present in messages 2 and 4.
          All zeros (fake hash) in message 4 if rejected by Bob.

  For messages 1-4, the data below here is covered
  by the signature, if present, and Bob forwards it unmodified.

  ver :: 1 byte SSU version:
         1: SSU 1 (not supported)
         2: SSU 2 (required)
  nonce :: 4 byte test nonce, big endian
  timestamp :: Unix timestamp, unsigned seconds.
               Wraps around in 2106
  asz :: 1 byte endpoint (port + IP) size (6 or 18)
  AlicePort :: 2 byte Alice's port number, big endian
  Alice IP :: (asz - 2) byte representation of Alice's IP address,
              network byte order
  signature :: length varies, 64 bytes for Ed25519.
               Signature of prologue, Bob's hash,
               and signed data above, as signed by
               Alice or Charlie.
               Only present for messages 1-4.
               Optional in message 5-7.

Notlar:

• SSU 1’den farklı olarak, mesaj 1’in Alice’in IP adresini ve portunu içermesi gerekir.

• IPv6 adreslerinin test edilmesi desteklenir, ve Alice-Bob ile Alice-Charlie iletişimi IPv6 üzerinden gerçekleştirilebilir, eğer Bob ve Charlie yayınladıkları IPv6 adresinde ‘B’ yeteneği ile destek belirtiyorlarsa. Ayrıntılar için Proposal 126’ya bakın.

Alice, test etmek istediği taşıma katmanı (IPv4 veya IPv6) üzerinden mevcut bir oturum kullanarak isteği Bob’a gönderir. Bob, Alice’den IPv4 üzerinden bir istek aldığında, Bob bir IPv4 adresi tanıtan bir Charlie seçmelidir. Bob, Alice’den IPv6 üzerinden bir istek aldığında, Bob bir IPv6 adresi tanıtan bir Charlie seçmelidir. Gerçek Bob-Charlie iletişimi IPv4 veya IPv6 üzerinden olabilir (yani Alice’in adres türünden bağımsızdır).

• Mesaj 1-4, mevcut bir oturumdaki bir Data mesajında bulunmalıdır.

• Bob, mesaj 2’yi göndermeden önce Alice’in RI’sını Charlie’ye göndermelidir.

• Bob, kabul edilirse (reason code 0) mesaj 4’ü göndermeden önce Charlie’nin RI’sını Alice’e göndermelidir.

• Mesaj 5-7, oturum dışı bir Peer Test mesajında bulunmalıdır.

• Mesaj 5 ve 7, mesaj 3 ve 4’te gönderilen aynı imzalı veriyi içerebilir veya yeni bir zaman damgası ile yeniden oluşturulabilir. İmza isteğe bağlıdır.

• Mesaj 6, mesaj 1 ve 2’de gönderilen imzalı verinin aynısını içerebilir veya yeni bir zaman damgası ile yeniden oluşturulabilir. İmza isteğe bağlıdır.

İmzalar:

Alice isteği imzalar ve 1. mesaja dahil eder; Bob bunu 2. mesajda Charlie’ye iletir. Charlie yanıtı imzalar ve 3. mesaja dahil eder; Bob bunu 4. mesajda Alice’e iletir. İmza algoritması: Aşağıdaki veriyi Alice’in veya Charlie’nin imzalama anahtarı ile imzala veya doğrula:

• prologue: 16 bayt “PeerTestValidate”, null-terminated değil (mesaja dahil değil)
• bhash: Bob’un 32-bayt router hash’i (mesaja dahil değil)
• ahash: Alice’in 32-bayt router hash’i (Yalnızca 3 ve 4 numaralı mesajlar için imzada kullanılır; 3 veya 4 numaralı mesaja dahil değil)
• ver: 1 bayt SSU sürümü
• nonce: 4 bayt test nonce’u
• timestamp: 4 bayt zaman damgası (saniye)
• asz: 1 bayt endpoint (port + IP) boyutu (6 veya 18)
• AlicePort: 2 bayt Alice’in port numarası
• Alice IP: (asz - 2) bayt Alice IP adresi

Yük

TODO yalnızca anahtarları döndürürsek

+----+----+----+----+----+----+----+----+
  | 11 |  size   |      TBD               |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 11
  size :: 2 bytes, big endian, size of data to follow

Notlar

4 byte ack through, ardından bir ack sayısı ve sıfır veya daha fazla nack/ack aralığı.

Bu tasarım QUIC’ten uyarlanmış ve basitleştirilmiştir. Tasarım hedefleri şu şekildedir:

• Onaylanmış paketleri temsil eden bir bit dizisi olan “bitfield"i verimli bir şekilde kodlamak istiyoruz.
• Bitfield çoğunlukla 1’lerden oluşur. Hem 1’ler hem de 0’lar genellikle ardışık “kümeler” halinde gelir.
• Pakette onaylar için mevcut olan alan miktarı değişkendir.
• En önemli bit en yüksek numaralı olandır. Düşük numaralı olanlar daha az önemlidir. En yüksek bitten belirli bir mesafenin altında, en eski bitler “unutulur” ve bir daha asla gönderilmez.

Aşağıda belirtilen kodlama, 1’e ayarlanmış en yüksek bitin numarasını, bundan daha düşük olan ve aynı zamanda 1’e ayarlanmış ek ardışık bitlerle birlikte göndererek bu tasarım hedeflerini gerçekleştirir. Bundan sonra, yer varsa, bundan daha düşük olan ardışık 0 bitlerin ve ardışık 1 bitlerin sayısını belirten bir veya daha fazla “aralık” eklenir. Daha fazla arka plan bilgisi için QUIC RFC 9000 bölüm 13.2.3’e bakın.

+----+----+----+----+----+----+----+----+
  | 12 |  size   |    Ack Through    |acnt|
  +----+----+----+----+----+----+----+----+
  |  range  |  range  |     .   .   .     |
  +----+----+----+----+                   +
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 12
  size :: 2 bytes, big endian, size of data to follow,
          5 minimum
  ack through :: highest packet number acked
  acnt :: number of acks lower than ack through also acked,
          0-255
  range :: If present,
           1 byte nack count followed by 1 byte ack count,
           0-255 each

Örnekler:

Sadece 10 numaralı paketi ACK yapmak istiyoruz:

• Ack Through: 10
• acnt: 0
• hiçbir aralık dahil edilmemiş

Yalnızca 8-10 numaralı paketleri ACK’lamak istiyoruz:

• Ack Through: 10
• acnt: 2
• aralık dahil edilmedi

10 9 8 6 5 2 1 0’ı ACK ve 7 4 3’ü NACK yapmak istiyoruz. ACK Block’un kodlaması şu şekildedir:

• Ack Through: 10
• acnt: 2 (ack 9 8)
• range: 1 2 (nack 7, ack 6 5)
• range: 2 3 (nack 4 3, ack 2 1 0)

Notlar:

• Aralıklar mevcut olmayabilir. Maksimum aralık sayısı belirtilmemiştir, pakete sığacak kadar çok olabilir.
• 255’ten fazla ardışık paketi onaylıyorsa range nack sıfır olabilir.
• 255’ten fazla ardışık paketi reddediyorsa range ack sıfır olabilir.
• Range nack ve ack her ikisi de sıfır olamaz.
• Son aralıktan sonra, paketler ne onaylanır ne de reddedilir. Ack bloğunun uzunluğu ve eski ack/nack’lerin nasıl işlendiği ack bloğunun gönderenine bağlıdır. Tartışma için aşağıdaki ack bölümlerine bakın.
• Ack through, alınan en yüksek paket numarası olmalıdır, ve daha yüksek paketler alınmamış demektir. Ancak, sınırlı durumlarda, “bir boşluğu dolduran” tek bir paketi onaylamak gibi veya alınan tüm paketlerin durumunu korumayan basitleştirilmiş bir uygulama gibi durumlarda daha düşük olabilir. En yüksek alınanın üzerinde, paketler ne onaylanır ne de reddedilir, ancak birkaç ack bloğundan sonra, hızlı yeniden iletim moduna geçmek uygun olabilir.
• Bu format, QUIC’teki formatın basitleştirilmiş bir versiyonudur. Çok sayıda ACK’yi, NACK patlamalarıyla birlikte verimli bir şekilde kodlamak için tasarlanmıştır.
• ACK blokları veri aşaması paketlerini onaylamak için kullanılır. Sadece oturum içi veri aşaması paketleri için dahil edilmelidirler.

Address

2 bayt port ve 4 veya 16 bayt IP adresi. Bob tarafından Alice’e gönderilen Alice’in adresi veya Alice tarafından Bob’a gönderilen Bob’un adresi.

+----+----+----+----+----+----+----+----+
  | 13 | 6 or 18 |   Port  | IP Address    
  +----+----+----+----+----+----+----+----+
       |
  +----+

  blk :: 13
  size :: 2 bytes, big endian, 6 or 18
  port :: 2 bytes, big endian
  ip :: 4 byte IPv4 or 16 byte IPv6 address,
        big endian (network byte order)

Relay Tag Request

Bu, Alice tarafından Session Request, Session Confirmed veya Data mesajında gönderilebilir. Session Created mesajında desteklenmez, çünkü Bob henüz Alice’in RI’sına sahip değildir ve Alice’in relay’i destekleyip desteklemediğini bilmez. Ayrıca, Bob gelen bir bağlantı alıyorsa, muhtemelen introducer’lara ihtiyacı yoktur (belki diğer tür ipv4/ipv6 dışında).

Session Request’te gönderildiğinde, Bob Session Created mesajında bir Relay Tag ile yanıtlayabilir veya Alice’in kimliğini doğrulamak için Session Confirmed’da Alice’in RouterInfo’sunu almayı bekleyip Data mesajında yanıtlamayı seçebilir. Bob Alice için relay yapmak istemiyorsa, Relay Tag bloğu göndermez.

+----+----+----+
  | 15 |    0    |
  +----+----+----+

  blk :: 15
  size :: 2 bytes, big endian, value = 0

Yük Verisi

Bu, Alice’den gelen Relay Tag Request’e yanıt olarak Bob tarafından bir Session Confirmed veya Data mesajında gönderilebilir.

Relay Tag Request, Session Request içinde gönderildiğinde, Bob Session Created mesajında bir Relay Tag ile yanıt verebilir veya Alice’in kimliğini doğrulamak için Session Confirmed içindeki Alice’in RouterInfo’sunu almayı bekleyip bir Data mesajında yanıtlamayı seçebilir. Eğer Bob Alice için relay yapmak istemiyorsa, Relay Tag bloğu göndermez.

+----+----+----+----+----+----+----+
  | 16 |    4    |    relay tag      |
  +----+----+----+----+----+----+----+

  blk :: 16
  size :: 2 bytes, big endian, value = 4
  relay tag :: 4 bytes, big endian, nonzero

Notlar

Sonraki bir bağlantı için. Genellikle Session Created ve Session Confirmed mesajlarında yer alır. Önceki token’ın süresi dolarsa uzun süreli bir oturumun Data mesajında da tekrar gönderilebilir.

+----+----+----+----+----+----+----+----+
  | 17 |   12    |     expires       |
  +----+----+----+----+----+----+----+----+
                  token              |
  +----+----+----+----+----+----+----+

  blk :: 17
  size :: 2 bytes, big endian, value = 12
  expires :: Unix timestamp, unsigned seconds.
             Wraps around in 2106
  token :: 8 bytes, big endian

Sorunlar

Path Response’ta döndürülecek rastgele veri ile bir Ping, keep-alive olarak veya bir IP/Port değişikliğini doğrulamak için kullanılır.

+----+----+----+----+----+----+----+----+
  | 18 |  size   |    Arbitrary Data      |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 18
  size :: 2 bytes, big endian, size of data to follow
  data :: Arbitrary data to be returned in a Path Response
          length as selected by sender

Notlar:

Rastgele veri içeren minimum 8 baytlık veri boyutu önerilir ancak zorunlu değildir.

Path Response

Path Challenge’da alınan veri ile bir Pong, Path Challenge’a yanıt olarak, keep-alive olarak veya bir IP/Port değişikliğini doğrulamak için kullanılır.

+----+----+----+----+----+----+----+----+
  | 19 |  size   |                        |
  +----+----+----+                        +
  |    Data received in Path Challenge    |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 19
  size :: 2 bytes, big endian, size of data to follow
  data :: As received in a Path Challenge

First Packet Number

İsteğe bağlı olarak her yönde el sıkışmaya dahil edilir, gönderilecek ilk paket numarasını belirtmek için. Bu, TCP’ye benzer şekilde başlık şifrelemesi için daha fazla güvenlik sağlar.

Tam olarak belirtilmemiş, şu anda desteklenmiyor.

+----+----+----+----+----+----+----+
  | 20 |  size   |  First pkt number |
  +----+----+----+----+----+----+----+

  blk :: 20
  size :: 4
  pkt num :: The first packet number to be sent in the data phase

Congestion

Bu blok, tıkanıklık kontrol bilgilerini değiş tokuş etmek için genişletilebilir bir yöntem olarak tasarlanmıştır. Tıkanıklık kontrolü karmaşık olabilir ve protokol ile canlı testlerde daha fazla deneyim kazandıkça veya tam dağıtımdan sonra gelişebilir.

Bu, yoğun kullanılan I2NP, First Fragment, Followon Fragment ve ACK bloklarında herhangi bir tıkanıklık bilgisini dışarıda tutar; bu bloklar için ayrılmış bayrak alanı bulunmamaktadır. Data paketi başlığında kullanılmayan üç bayt bayrak bulunsa da, bu da genişletilebilirlik için sınırlı alan sağlar ve daha zayıf şifreleme koruması sunar.

İki bit bilgi için 4 baytlık bir blok kullanmak bir miktar israf olsa da, bunu ayrı bir blokta yerleştirerek, mevcut pencere boyutları, ölçülen RTT veya diğer bayraklar gibi ek verilerle kolayca genişletebiliriz. Deneyim göstermiştir ki, yalnızca bayrak bitleri gelişmiş sıkışıklık kontrol şemalarının uygulanması için çoğunlukla yetersiz ve kullanışsızdır. Örneğin ACK bloğunda herhangi bir olası sıkışıklık kontrol özelliği için destek eklemeye çalışmak, alan israfına neden olur ve o bloğun ayrıştırılmasına karmaşıklık ekler.

Uygulamalar, bu spesifikasyonun gelecekteki bir sürümü tarafından uygulama zorunlu kılınmadıkça, diğer router’ın burada yer alan herhangi bir özel bayrak biti veya özelliği desteklediğini varsaymamalıdır.

Bu blok muhtemelen payload’daki son non-padding blok olmalıdır.

+----+----+----+----+
  | 21 |  size   |flag|
  +----+----+----+----+

  blk :: 21
  size :: 1 (or more if extended)
  flag :: 1 byte flags
         bit order: 76543210 (bit 7 is MSB)
         bit 0: 1 to request immediate ack
         bit 1: 1 for explicit congestion notification (ECN)
         bits 7-2: Unused, set to 0 for future compatibility

Yük

Bu, AEAD yükleri içindeki dolgu için kullanılır. Tüm mesajlar için dolgu, AEAD yükleri içindedir.

Padding kabaca müzakere edilen parametrelere uymalıdır. Bob, Session Created içinde istenen tx/rx min/max parametrelerini gönderdi. Alice, Session Confirmed içinde istenen tx/rx min/max parametrelerini gönderdi. Güncellenmiş seçenekler veri aşamasında gönderilebilir. Yukarıdaki seçenekler bloğu bilgisine bakın.

Mevcut ise, bu payload’daki son blok olmalıdır.

+----+----+----+----+----+----+----+----+
  |254 |  size   |      padding           |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 254
  size :: 2 bytes, big endian, size of padding to follow
  padding :: random data

Notlar:

• Size = 0 değerine izin verilir.

• Padding stratejileri TBD.

• Minimum padding TBD.

• Yalnızca padding içeren payload’lara izin verilir.

• Padding varsayılan değerleri TBD.

• Padding parametresi müzakeresi için options bloğuna bakınız

• Min/max padding parametreleri için options bloğuna bakınız

• MTU’yu aşmayın. Daha fazla padding gerekiyorsa, birden fazla mesaj gönderin.

• Müzakere edilmiş padding kurallarının ihlali durumunda router yanıtı implementasyon-bağımlıdır.

• Padding uzunluğu ya mesaj bazında belirlenecek ve uzunluk dağılımının tahminleri kullanılacak, ya da rastgele gecikmeler eklenecektir. Bu karşı önlemler DPI’ya direnç göstermek için dahil edilecektir, çünkü mesaj boyutları aksi takdirde I2P trafiğinin aktarım protokolü tarafından taşındığını ortaya çıkaracaktır. Kesin padding şeması gelecekteki çalışmaların bir alanıdır, NTCP2 dökümanının Ek A bölümü konu hakkında daha fazla bilgi sağlamaktadır.

Replay Prevention

SSU2, bir saldırgan tarafından yeniden oynatılan mesajların etkisini en aza indirmek için tasarlanmıştır.

Token Request, Retry, Session Request, Session Created, Hole Punch ve oturum dışı Peer Test mesajları DateTime blokları içermelidir.

Alice ve Bob, bu mesajlar için zamanın geçerli bir sapma aralığında olduğunu doğrular (önerilen +/- 2 dakika). “Probing direnci” için Bob, sapma geçersizse Token Request veya Session Request mesajlarına yanıt vermemelidir, çünkü bu mesajlar bir tekrar veya probing saldırısı olabilir.

Bob, geçerli bir skew olsa bile, Bloom filtresi veya başka bir mekanizma aracılığıyla yinelenen Token Request ve Retry mesajlarını reddetmeyi seçebilir. Ancak, bu mesajlara yanıt vermenin boyut ve CPU maliyeti düşüktür. En kötü durumda, tekrar oynatılan bir Token Request mesajı önceden gönderilmiş bir token’ı geçersiz kılabilir.

Token sistemi, tekrar oynatılan Session Request mesajlarının etkisini büyük ölçüde minimize eder. Token’lar yalnızca bir kez kullanılabileceğinden, tekrar oynatılan bir Session Request mesajı asla geçerli bir token’a sahip olmayacaktır. Bob, skew geçerli olsa bile, Bloom filtresi veya başka bir mekanizma aracılığıyla yinelenen Session Request mesajlarını reddetmeyi seçebilir. Ancak, Retry mesajıyla yanıt vermenin boyut ve CPU maliyeti düşüktür. En kötü durumda, Retry mesajı göndermek daha önce gönderilmiş bir token’ı geçersiz kılabilir.

Duplicate Session Created ve Session Confirmed mesajları doğrulanamayacaktır çünkü Noise handshake durumu bunları şifrelemek için doğru durumda olmayacaktır. En kötü durumda, bir peer görünüşte duplicate Session Created’a yanıt olarak bir Session Confirmed yeniden iletebilir.

Yeniden oynanan Hole Punch ve Peer Test mesajlarının çok az etkisi olmalı veya hiç etkisi olmamalıdır.

Router’lar, yinelenen veri aşaması mesajlarını tespit etmek ve silmek için veri mesajı paket numarasını kullanmalıdır. Her paket numarası yalnızca bir kez kullanılmalıdır. Yeniden oynatılan mesajlar göz ardı edilmelidir.

Handshake Retransmission

Session Request

Alice tarafından hiçbir Session Created veya Retry alınmadıysa:

Aynı kaynak ve bağlantı ID’lerini, geçici anahtarı ve paket numarası 0’ı koruyun. Ya da aynı şifrelenmiş paketi sakla ve yeniden ilet. Paket numarası artırılmamalıdır, çünkü bu Session Created mesajını şifrelemek için kullanılan zincirleme hash değerini değiştirir.

Önerilen yeniden iletim aralıkları: 1.25, 2.5 ve 5 saniye (ilk gönderimden sonra 1.25, 3.75 ve 8.75 saniye). Önerilen zaman aşımı: toplam 15 saniye

Session Created

Bob tarafından Session Confirmed alınmazsa:

Aynı kaynak ve bağlantı ID’lerini, ephemeral anahtarını ve paket numarası 0’ı koruyun. Ya da sadece şifrelenmiş paketi saklayın. Paket numarası artırılmamalıdır, çünkü bu Session Confirmed mesajını şifrelemek için kullanılan zincirleme hash değerini değiştirecektir.

Önerilen yeniden iletim aralıkları: 1, 2 ve 4 saniye (ilk gönderimden sonra 1, 3 ve 7 saniye). Önerilen zaman aşımı: toplamda 12 saniye

Session Confirmed

SSU 1’de Alice, Bob’dan ilk veri paketi alınana kadar veri aşamasına geçmez. Bu, SSU 1’i iki gidiş-dönüş kurulumu yapar.

SSU 2 için, Önerilen Session Confirmed yeniden iletim aralıkları: 1,25, 2,5 ve 5 saniye (ilk gönderimden sonra 1,25, 3,75 ve 8,75 saniye).

Birkaç alternatif bulunmaktadır. Hepsi 1 RTT’dir:

1. Alice, Session Confirmed mesajının alındığını varsayar, veri mesajlarını hemen gönderir, Session Confirmed mesajını asla yeniden iletmez. Sıra dışı alınan veri paketleri (Session Confirmed’dan önce) şifresi çözülemez olacaktır, ancak yeniden iletilecektir. Session Confirmed kaybolursa, gönderilen tüm veri mesajları düşürülecektir.

2. 1)‘deki gibi, veri mesajlarını hemen gönder, ancak bir veri mesajı alınana kadar Session Confirmed’ı da yeniden ilet.

3. Handshake’te sadece iki mesaj olduğu için XK yerine IK kullanabiliriz, ancak ekstra bir DH kullanır (3 yerine 4).

Önerilen uygulama 2. seçenektir. Alice, Session Confirmed mesajını yeniden iletmek için gerekli bilgileri saklamalıdır. Alice ayrıca Session Confirmed mesajı yeniden iletildikten sonra tüm Data mesajlarını da yeniden iletmelidir.

Session Confirmed yeniden iletirken, aynı kaynak ve bağlantı kimliklerini, ephemeral anahtarı ve paket numarası 1’i koruyun. Ya da sadece şifreli paketi saklayın. Paket numarası artırılmamalıdır, çünkü bu split() fonksiyonu için girdi olan zincirleme hash değerini değiştirecektir.

Bob, Session Confirmed mesajı alınmadan önce aldığı veri mesajlarını saklayabilir (kuyruğa alabilir). Ne başlık koruma anahtarları ne de şifre çözme anahtarları Session Confirmed mesajı alınmadan önce mevcut değildir, bu nedenle Bob bunların veri mesajları olduğunu bilmez, ancak bu varsayılabilir. Session Confirmed mesajı alındıktan sonra, Bob kuyruktaki Veri mesajlarını şifresini çözebilir ve işleyebilir. Bu çok karmaşıksa, Bob şifresi çözülemeyen Veri mesajlarını bırakabilir, çünkü Alice bunları yeniden iletecektir.

Not: Eğer session confirmed paketleri kaybolursa, Bob session created’ı yeniden iletecektir. Session created başlığı Alice’in intro key’i ile şifresi çözülemeyecektir, çünkü Bob’un intro key’i ile ayarlanmıştır (Bob’un intro key’i ile fallback şifre çözme işlemi gerçekleştirilmediği sürece). Bob, daha önce ack alınmamışsa session confirmed paketlerini hemen yeniden iletebilir ve şifresi çözülemeyen bir paket alınırsa.

Token Request

Alice tarafından Retry alınmazsa:

Aynı kaynak ve bağlantı kimliklerini koruyun. Bir uygulama yeni bir rastgele paket numarası oluşturabilir ve yeni bir paket şifreleyebilir; Ya da aynı paket numarasını yeniden kullanabilir veya sadece aynı şifrelenmiş paketi saklayıp yeniden iletebilir. Paket numarası artırılmamalıdır, çünkü bu Session Created mesajını şifrelemek için kullanılan zincirleme hash değerini değiştirir.

Önerilen yeniden iletim aralıkları: 3 ve 6 saniye (ilk gönderimden sonra 3 ve 9 saniye). Önerilen zaman aşımı: toplam 15 saniye

Retry

Bob tarafından hiçbir Session Request alınmadıysa:

Yeniden deneme mesajı, sahte kaynak adreslerinin etkilerini azaltmak için zaman aşımında yeniden iletilmez.

Ancak, orijinal (geçersiz) token ile tekrarlanan bir Session Request mesajının alınmasına yanıt olarak veya tekrarlanan bir Token Request mesajına yanıt olarak bir Retry mesajı yeniden iletilebilir. Her iki durumda da bu, Retry mesajının kaybolduğunu gösterir.

Farklı ancak yine geçersiz bir token ile ikinci bir Session Request mesajı alınırsa, bekleyen oturumu bırakın ve yanıt vermeyin.

Retry mesajını yeniden gönderirken: Aynı kaynak ve bağlantı ID’lerini ve token’ı koruyun. Bir uygulama yeni rastgele bir paket numarası oluşturabilir ve yeni bir paket şifreleyebilir; Ya da aynı paket numarasını yeniden kullanabilir veya aynı şifrelenmiş paketi saklayıp yeniden iletebilir.

Total Timeout

Handshake için önerilen toplam zaman aşımı süresi 20 saniyedir.

Duplicates and Error Handling

Üç Noise el sıkışma mesajının duplikatları Session Request, Session Created ve Session Confirmed, başlığın MixHash() işleminden önce tespit edilmelidir. Bundan sonra Noise AEAD işleminin muhtemelen başarısız olacağı varsayılsa da, el sıkışma hash’i zaten bozulmuş olacaktır.

Üç mesajdan herhangi biri bozulur ve AEAD başarısız olursa, handshake daha sonra yeniden iletim ile bile kurtarılamaz, çünkü MixHash() zaten bozuk mesaj üzerinde çağrılmış olur.

Tokens

Session Request başlığındaki Token, DoS saldırılarını azaltmak, kaynak adres sahteciliğini önlemek ve tekrar saldırılarına karşı direnç sağlamak için kullanılır.

Eğer Bob, Session Request mesajındaki token’ı kabul etmezse, Bob mesajı şifrelemez, çünkü bu pahalı bir DH işlemi gerektirir. Bob sadece yeni bir token ile bir Retry mesajı gönderir.

Eğer daha sonra bu token ile bir Session Request mesajı alınırsa, Bob bu mesajı şifresini çözmeye devam eder ve handshake ile devam eder.

Token, eğer token üreteticisi değerleri ve ilişkili IP ve port’u (bellekte veya kalıcı olarak) saklarsa, rastgele oluşturulmuş 8 bayt değeri olmalıdır. Üretici, bellekte saklanmaya ihtiyaç duymayan token’lar oluşturmak için IP, port ve mevcut saat veya günün SipHash’ini (gizli seed K0, K1 ile) kullanarak opak bir değer üretemez, çünkü bu yöntem yeniden kullanılan token’ları ve tekrar saldırılarını reddetmeyi zorlaştırır.

Token’lar yalnızca bir kez kullanılabilir. Bob’dan Alice’e Retry mesajında gönderilen bir token hemen kullanılmalıdır ve birkaç saniye içinde sona erer. Kurulmuş bir oturumda New Token bloğunda gönderilen bir token sonraki bağlantıda kullanılabilir ve o blokta belirtilen zamanda sona erer. Son kullanma tarihi gönderen tarafından belirlenir; önerilen değerler minimum bir saat, maksimum birkaç saattir.

Bir router’ın IP’si veya portu değişirse, eski IP veya port için kaydedilmiş tüm token’ları (hem gelen hem de giden) silmesi gerekir, çünkü artık geçerli değildirler. Token’lar isteğe bağlı olarak router yeniden başlatmaları arasında kalıcı hale getirilebilir, bu implementasyona bağlıdır. Süresi dolmamış bir token’ın kabulü garanti edilmez; eğer Bob kaydettiği token’ları unutmuş veya silmişse, Alice’e bir Retry gönderecektir. Bir router token depolamasını sınırlandırmayı seçebilir ve süresi dolmamış olsa bile en eski depolanmış token’ları kaldırabilir.

Yeni Token blokları Alice’ten Bob’a veya Bob’tan Alice’e gönderilebilir. Bunlar genellikle oturum kurulumu sırasında veya kısa bir süre sonra bir kez gönderilir. Token, süresi dolmadan önce veya sonra yeni bir sona erme zamanıyla yeniden gönderilebilir veya yeni bir token gönderilebilir. Router’lar yalnızca alınan son token’ın geçerli olduğunu varsaymalıdır; aynı IP/port için birden fazla gelen veya giden token depolama gereksinimi yoktur.

Bir token, kaynak IP/port ve hedef IP/port kombinasyonuna bağlıdır. IPv4 üzerinde alınan bir token IPv6 için kullanılamaz veya tam tersi.

Oturum sırasında herhangi bir peer yeni bir IP’ye veya port’a taşınırsa (Connection Migration bölümüne bakın), önceden değiştirilen tüm token’lar geçersiz hale gelir ve yeni token’ların değiştirilmesi gerekir.

Uygulamalar, token’ları diske kaydedebilir ve yeniden başlatma sırasında yeniden yükleyebilir, ancak bunu yapmak zorunda değildirler. Token’lar kalıcı hale getirilirse, uygulama onları yeniden yüklemeden önce IP ve port’un kapatma işleminden bu yana değişmediğinden emin olmalıdır.

I2NP Message Fragmentation

SSU 1’den Farklar

Not: SSU 1’de olduğu gibi, ilk fragment toplam fragment sayısı veya toplam uzunluk hakkında bilgi içermez. Takip eden fragmentler kendi offset bilgilerini içermez. Bu, gönderene paketteki mevcut alana göre “anında” parçalama esnekliği sağlar. (Java I2P bunu yapmaz; ilk fragment gönderilmeden önce “ön-parçalama” yapar) Ancak bu, alıcıya sıra dışı alınan fragmentleri depolama ve tüm fragmentler alınana kadar yeniden birleştirmeyi geciktirme yükü getirir.

SSU 1’de olduğu gibi, parçaların herhangi bir yeniden iletiminde parçanın önceki iletiminin uzunluğu (ve örtük ofset) korunmalıdır.

SSU 2, işlem verimliliğini artırmak için üç durumu (tam mesaj, başlangıç fragmanı ve devam fragmanı) üç farklı blok türüne ayırır.

I2NP Message Duplication

Bu protokol I2NP mesajlarının çoğaltılarak teslim edilmesini tamamen engellemez. IP katmanı çoğaltmaları veya tekrar saldırıları SSU2 katmanında tespit edilecektir, çünkü her paket numarası sadece bir kez kullanılabilir.

I2NP mesajları veya parçaları yeni paketlerde yeniden iletildiğinde, bu durum SSU2 katmanında tespit edilemez. Router, I2NP süre aşımını (hem çok eski hem de gelecekte çok uzak olanları) zorlamalı ve I2NP mesaj kimliğine dayalı Bloom filtresi veya başka bir mekanizma kullanmalıdır.

Router tarafından veya SSU2 implementasyonunda, kopyaları tespit etmek için ek mekanizmalar kullanılabilir. Örneğin, SSU2 yakın zamanda alınan mesaj ID’lerinin bir önbelleğini tutabilir. Bu implementasyona bağlıdır.

Congestion Control

Bu öneri, paket numaralandırma ve ACK blokları için protokolü belirtir. Bu, bir verici için verimli ve duyarlı bir tıkanıklık kontrol algoritması uygulaması için yeterli gerçek zamanlı bilgi sağlarken, bu uygulamada esneklik ve yenilikçiliğe olanak tanır. Bu bölüm uygulama hedeflerini tartışır ve öneriler sunar. Genel rehberlik RFC 9002‘de bulunabilir. Yeniden iletim zamanlayıcıları hakkında rehberlik için RFC 6298’e de bakınız.

Yalnızca ACK içeren veri paketleri, uçuştaki bayt veya paket sayısına dahil edilmemeli ve tıkanıklık kontrolüne tabi tutulmamalıdır. TCP’den farklı olarak, SSU2 bu paketlerin kaybını tespit edebilir ve bu bilgi tıkanıklık durumunu ayarlamak için kullanılabilir. Ancak, bu dokümanda bunu yapacak bir mekanizma belirtilmemiştir.

İstenirse, başka veri-dışı bloklar içeren paketler de tıkanıklık kontrolünden hariç tutulabilir, bu uygulama-bağımlıdır. Örneğin:

• Eş Test
• Aktarım isteği/giriş/yanıt
• Yol sınaması/yanıt

TCP RFC’leri ve QUIC RFC 9002 rehberliğini takip ederek, tıkanıklık kontrolünün paket sayısı değil, bayt sayısı temel alınarak yapılması önerilir. Kernel’da veya middlebox’larda buffer overflow’u önlemek için ek bir paket sayısı sınırı da yararlı olabilir, ancak bu implementasyona bağlıdır ve önemli ölçüde karmaşıklık ekleyebilir. Eğer oturum başına ve/veya toplam paket çıktısı bant genişliği ile sınırlandırılmış ve/veya tempolu ise, bu paket sayısı sınırlaması ihtiyacını azaltabilir.

Packet Numbers

SSU 1’de, ACK’lar ve NACK’lar I2NP mesaj numaralarını ve fragment bit maskelerini içeriyordu. Vericiler, giden mesajların (ve bunların fragmentlarının) ACK durumunu takip ediyor ve gerektiğinde fragmentları yeniden iletiyordu.

SSU 2’de, ACK’lar ve NACK’lar paket numaraları içerir. Verici taraflar, paket numaralarının içeriklerine eşlendiği bir veri yapısını muhafaza etmelidir. Bir paket ACK veya NACK aldığında, verici o pakette hangi I2NP mesajları ve parçalarının bulunduğunu belirlemeli ve neyin yeniden iletileceğine karar vermelidir.

Session Confirmed ACK

Bob, paket 0’ın ACK’ını gönderir, bu da Session Confirmed mesajını onaylar ve Alice’in veri fazına geçmesine izin verir, ayrıca olası yeniden iletim için saklanan büyük Session Confirmed mesajının atılmasını sağlar. Bu, SSU 1’de Bob tarafından gönderilen DeliveryStatusMessage’ı değiştirir.

Bob, Session Confirmed mesajını aldıktan sonra mümkün olan en kısa sürede bir ACK göndermelidir. Küçük bir gecikme (50 ms’den fazla değil) kabul edilebilir, çünkü Session Confirmed mesajından hemen sonra en az bir Data mesajının gelmesi gerekir, böylece ACK hem Session Confirmed hem de Data mesajını onaylayabilir. Bu, Bob’un Session Confirmed mesajını yeniden iletmek zorunda kalmasını önleyecektir.

Generating ACKs

Tanım: Ack-eliciting paketleri: Ack-eliciting blokları içeren paketler, alıcıdan maksimum onay gecikmesi içinde bir ACK talep eder ve ack-eliciting paketleri olarak adlandırılır.

Router’lar aldıkları ve işledikleri tüm paketleri onaylar. Ancak, yalnızca onay gerektiren paketler maksimum onay gecikmesi içinde bir ACK bloğunun gönderilmesine neden olur. Onay gerektirmeyen paketler yalnızca diğer nedenlerle bir ACK bloğu gönderildiğinde onaylanır.

Herhangi bir nedenle paket gönderirken, bir endpoint yakın zamanda gönderilmemiş ise bir ACK bloğu eklemeye çalışmalıdır. Bunu yapmak, peer’da zamanında kayıp tespitine yardımcı olur.

Genel olarak, bir alıcıdan gelen sık geri bildirim kayıp ve tıkanıklık yanıtını iyileştirir, ancak bu durum her ack-eliciting paketine yanıt olarak bir ACK bloğu gönderen bir alıcının oluşturduğu aşırı yüke karşı dengelenmelidir. Aşağıda sunulan rehberlik bu dengeyi kurmaya çalışır.

Aşağıdakiler DIŞINDA herhangi bir blok içeren oturum içi veri paketleri ack-eliciting’dir:

• ACK bloğu
• Adres bloğu
• DateTime bloğu
• Padding bloğu
• Termination bloğu
• Termination bloğu ile aynı paketteki herhangi bir blok
• Diğerleri?

“Termination received” dışında bir nedenle Termination bloğu içeren paketler, “termination received” içeren bir Termination bloğu bulunan paket ile onaylanır.

Oturum dışı paketler, el sıkışma mesajları ve eş test mesajları 5-7 dahil olmak üzere, kendi onaylama mekanizmalarına sahiptir. Aşağıya bakınız.

Handshake ACKs

Bunlar özel durumlar:

• Token Request, Retry tarafından dolaylı olarak onaylanır
• Session Request, Session Created veya Retry tarafından dolaylı olarak onaylanır
• Retry, Session Request tarafından dolaylı olarak onaylanır
• Session Created, Session Confirmed tarafından dolaylı olarak onaylanır
• Session Confirmed hemen onaylanmalıdır

Sending ACK Blocks

ACK blokları, veri aşaması paketlerini onaylamak için kullanılır. Bunlar yalnızca oturum içi veri aşaması paketleri için dahil edilmelidir.

Her paket en az bir kez onaylanmalıdır ve ack-eliciting paketleri maksimum gecikme süresi içinde en az bir kez onaylanmalıdır.

Bir endpoint, aşağıdaki istisna dışında, tüm ack-eliciting handshake paketlerini maksimum gecikme süresi içinde derhal onaylamalıdır. Handshake onayından önce, bir endpoint alındıkları zaman paketlerin şifresini çözmek için packet header şifreleme anahtarlarına sahip olmayabilir. Bu nedenle bunları arabelleğe alabilir ve gerekli anahtarlar kullanılabilir hale geldiğinde onaylayabilir.

Yalnızca ACK blokları içeren paketler tıkanıklık kontrolüne tabi olmadığından, bir uç nokta ack-eliciting paket almasına yanıt olarak bu tür paketlerden birden fazlasını göndermemelidir.

Bir uç nokta, alınan paketten önce gelen paket boşlukları olsa bile, ack-gerektirmeyen bir pakete yanıt olarak ack-gerektirmeyen bir paket göndermemelidir. Bu, bağlantının hiçbir zaman boşta kalmasını engelleyebilecek sonsuz bir onay geri bildirim döngüsünü önler. Ack-gerektirmeyen paketler, uç nokta diğer olaylara yanıt olarak bir ACK bloğu gönderdiğinde sonunda onaylanır.

Yalnızca ACK blokları gönderen bir endpoint, bu onaylamalar ack-eliciting bloklar içeren paketlere dahil edilmedikçe eşinden onaylama alamaz. Bir endpoint, onaylanacak yeni ack-eliciting paketler olduğunda diğer bloklarla birlikte bir ACK blok göndermelidir. Yalnızca non-ack-eliciting paketlerin onaylanması gerektiğinde, bir endpoint ack-eliciting bir paket alınana kadar giden bloklarla birlikte ACK blok göndermemeyi seçebilir.

Yalnızca non-ack-eliciting paketler gönderen bir endpoint, bir acknowledgment aldığından emin olmak için bu paketlere zaman zaman bir ack-eliciting block eklemeyi seçebilir. Bu durumda, sonsuz bir acknowledgment geri bildirim döngüsünden kaçınmak için endpoint, aksi takdirde non-ack-eliciting olacak tüm paketlerde ack-eliciting block göndermemelidir (MUST NOT).

Gönderici tarafında kayıp tespit işlemine yardımcı olmak için, bir uç nokta aşağıdaki durumlardan herhangi birinde ack-eliciting paket aldığında gecikme olmaksızın bir ACK bloğu oluşturmalı ve göndermelidir:

• Alınan paket, daha önce alınmış başka bir ack-eliciting paketten daha küçük bir paket numarasına sahip olduğunda

• Paket, alınan en yüksek numaralı ack-eliciting paketten daha büyük bir paket numarasına sahip olduğunda ve bu paket ile söz konusu paket arasında eksik paketler bulunduğunda.

• Paket başlığındaki ack-immediate bayrağı ayarlandığında

Algoritmalar, yukarıda sunulan rehberliği takip etmeyen alıcılara karşı dayanıklı olması beklenmektedir. Ancak, bir uygulama bu gereksinimlerden yalnızca endpoint tarafından yapılan bağlantılar ve ağın diğer kullanıcıları için bir değişikliğin performans etkilerini dikkatli bir şekilde değerlendirdikten sonra sapmalıdır.

ACK Frequency

Bir alıcı, ack-eliciting paketlerine yanıt olarak ne sıklıkla onay gönderileceğini belirler. Bu belirleme bir değiş tokuş içerir.

Uç noktalar kayıpları tespit etmek için zamanında onay alınmasına dayanır. Pencere tabanlı tıkanıklık denetleyicileri, tıkanıklık pencerelerini yönetmek için onayları kullanır. Her iki durumda da, onayların gecikmesi performansı olumsuz etkileyebilir.

Öte yandan, yalnızca onayları taşıyan paketlerin sıklığını azaltmak, her iki uç noktada da paket iletimi ve işleme maliyetini düşürür. Bu, ciddi şekilde asimetrik bağlantılarda bağlantı verimini artırabilir ve geri dönüş yolu kapasitesini kullanan onay trafiği hacmini azaltabilir; RFC 3449 Bölüm 3’e bakınız.

Bir alıcı, en az iki ack-eliciting paket aldıktan sonra bir ACK bloğu göndermelidir. Bu öneri genel niteliktedir ve TCP endpoint davranışı için önerilerle tutarlıdır RFC 5681. Ağ koşulları bilgisi, eşin tıkanıklık denetleyicisi hakkındaki bilgi veya daha fazla araştırma ve deneyimleme, daha iyi performans özelliklerine sahip alternatif onaylama stratejileri önerebilir.

Bir alıcı, yanıt olarak bir ACK bloğu gönderip göndermeyeceğini belirlemeden önce mevcut birden fazla paketi işleyebilir. Genel olarak, alıcı bir ACK’yi RTT / 6’dan veya maksimum 150 ms’den fazla geciktirmemelidir.

Veri paketi başlığındaki ack-immediate bayrağı, alıcının alımdan kısa bir süre sonra, muhtemelen birkaç ms içinde bir ack göndermesi talebidir. Genel olarak, alıcı anında ACK’yi RTT / 16’dan veya maksimum 5 ms’den fazla geciktirmemelidir.

Immediate ACK Flag

Alıcı, gönderenin gönderme penceresi boyutunu bilmez ve bu nedenle ACK göndermeden önce ne kadar bekleyeceğini bilemez. Veri paketi başlığındaki anında ACK bayrağı, etkili RTT’yi en aza indirerek maksimum verimliği sürdürmenin önemli bir yoludur. Anında ACK bayrağı başlık byte’ı 13, bit 0’dır, yani (header[13] & 0x01). Ayarlandığında, anında ACK istenir. Ayrıntılar için yukarıdaki kısa başlık bölümüne bakın.

Bir gönderici, immediate-ack bayrağını ne zaman ayarlayacağını belirlemek için birkaç olası strateji kullanabilir:

• Her N pakette bir kez ayarlanır, küçük bir N değeri için
• Bir paket patlamasındaki son pakette ayarlanır
• Gönderme penceresi neredeyse dolduğunda ayarlanır, örneğin 2/3’ünden fazla dolduğunda
• Yeniden iletilen fragmanları olan tüm paketlerde ayarlanır

Anında ACK bayrakları yalnızca I2NP mesajları veya mesaj parçaları içeren veri paketlerinde gerekli olmalıdır.

ACK Block Size

Bir ACK bloğu gönderildiğinde, onaylanmış paketlerin bir veya daha fazla aralığı dahil edilir. Eski paketler için onaylamaların dahil edilmesi, daha büyük ACK blokları pahasına, daha önce gönderilen ACK bloklarının kaybedilmesinden kaynaklanan sahte yeniden iletimlerin olasılığını azaltır.

ACK blokları her zaman en son alınan paketleri onaylamalıdır ve paketler ne kadar düzensizse, eşin bir paketi kaybolmuş olarak ilan etmesini ve içerdiği blokları gereksiz yere yeniden iletmesini önlemek için güncellenmiş bir ACK bloğunu hızlıca göndermek o kadar önemlidir. Bir ACK bloğu tek bir paket içine sığmalıdır. Sığmıyorsa, eski aralıklar (en küçük paket numaralarına sahip olanlar) çıkarılır.

Bir alıcı, hem ACK bloklarının boyutunu sınırlamak hem de kaynak tükenmesini önlemek için hatırladığı ve ACK bloklarında gönderdiği ACK aralıklarının sayısını sınırlar. Bir ACK bloğu için onaylamaları aldıktan sonra, alıcı bu onaylanmış ACK aralıklarını izlemeyi bırakmalıdır. Gönderenler çoğu paket için onaylamaları bekleyebilir, ancak bu protokol alıcının işlediği her paket için onaylama alınacağını garanti etmez.

Çok sayıda ACK aralığının tutulması, bir ACK bloğunun çok büyük hale gelmesine neden olabilir. Alıcı, ACK blok boyutunu sınırlamak için onaylanmamış ACK Aralıklarını atabilir, ancak bu gönderenden artan yeniden iletimlerin bedeli ile olur. Bu, bir ACK bloğunun bir pakete sığmayacak kadar büyük olması durumunda gereklidir. Alıcılar ayrıca diğer bloklar için yer ayırmak veya onaylamaların tükettiği bant genişliğini sınırlamak amacıyla ACK blok boyutunu daha da sınırlayabilir.

Bir alıcı, o aralıktaki numaralara sahip paketleri sonradan kabul etmeyeceğini garanti edebilmedikçe bir ACK aralığını korumalıdır. Aralıklar atıldıkça artan minimum bir paket numarası sürdürmek, bunu minimal durum ile başarmanın bir yoludur.

Alıcılar tüm ACK aralıklarını atabilir, ancak başarıyla işlenmiş olan en büyük paket numarasını saklamalıdır, çünkü bu sonraki paketlerden paket numaralarını kurtarmak için kullanılır.

Aşağıdaki bölüm, her ACK bloğunda hangi paketlerin onaylanacağını belirlemek için örnek bir yaklaşımı açıklar. Bu algoritmanın amacı işlenen her paket için bir onay üretmek olsa da, onayların kaybolması hala mümkündür.

Limiting Ranges by Tracking ACK Blocks

Bir ACK bloğu içeren paket gönderildiğinde, o bloktaki Ack Through alanı kaydedilebilir. Bir ACK bloğu içeren paket onaylandığında, alıcı gönderilen ACK bloğundaki Ack Through alanından küçük veya ona eşit paketleri onaylamayı durdurabilir.

Yalnızca ACK blokları gibi onay gerektirmeyen paketler gönderen bir alıcı, uzun süre boyunca bir onay alamayabilir. Bu durum, alıcının çok sayıda ACK bloğu için uzun süre boyunca durum bilgisi tutmasına neden olabilir ve gönderdiği ACK blokları gereksiz yere büyük olabilir. Böyle bir durumda, alıcı eşten bir ACK almak için ara sıra, örneğin gidiş dönüş başına bir kez, bir PING veya başka küçük bir onay gerektiren blok gönderebilir.

ACK blok kaybının olmadığı durumlarda, bu algoritma minimum 1 RTT yeniden sıralama için izin verir. ACK blok kaybı ve yeniden sıralamanın olduğu durumlarda, bu yaklaşım her onaylamanın artık ACK blokuna dahil edilmeden önce gönderici tarafından görülmesini garanti etmez. Paketler sıra dışı alınabilir ve bunları içeren sonraki tüm ACK blokları kaybolabilir. Bu durumda, kayıp kurtarma algoritması sahte yeniden iletimlere neden olabilir, ancak gönderici ilerleme kaydetmeye devam edecektir.

Congestion

I2P transport’ları, I2NP mesajlarının sıralı teslimatını garanti etmez. Bu nedenle, bir veya daha fazla I2NP mesajı ya da parçası içeren bir Data mesajının kaybı, diğer I2NP mesajlarının teslim edilmesini engellemez; head-of-line blocking yoktur. Uygulamalar, gönderim penceresi izin veriyorsa, kayıp kurtarma aşamasında yeni mesajlar göndermeye devam etmelidir.

Retransmission

Bir gönderici, özdeş şekilde yeniden iletilmek üzere bir mesajın tam içeriğini saklamamalıdır (handshake mesajları hariç, yukarıya bakın). Bir gönderici, her mesaj gönderişinde güncel bilgileri (ACK’ler, NACK’ler ve onaylanmamış veri) içeren mesajları oluşturmalıdır. Bir gönderici, mesajlardan gelen bilgileri bir kez onaylandıktan sonra yeniden iletmekten kaçınmalıdır. Bu, kayıp olarak ilan edildikten sonra onaylanan mesajları da içerir ve bu durum ağ yeniden sıralaması varlığında gerçekleşebilir.

Window

Belirlenmedi. Genel rehberlik RFC 9002‘de bulunabilir.

Connection Migration

Bir peer’ın IP’si veya portu bir oturum süresince değişebilir. Bir IP değişikliği IPv6 geçici adres rotasyonu, ISS tarafından yönlendirilen periyodik IP değişikliği, WiFi ve hücresel IP’ler arasında geçiş yapan mobil bir istemci veya diğer yerel ağ değişiklikleri nedeniyle olabilir. Bir port değişikliği ise önceki bağlama zaman aşımına uğradıktan sonra NAT yeniden bağlanması nedeniyle olabilir.

Bir peer’in IP’si veya portu, paketleri değiştirme veya enjekte etme dahil olmak üzere çeşitli yol üzerinde ve yol dışında saldırılar nedeniyle değişmiş gibi görünebilir.

Bağlantı migrasyonu, doğrulanmamış değişiklikleri önlerken yeni bir kaynak endpoint’inin (IP+port) doğrulandığı süreçtir. Bu süreç, QUIC RFC 9000‘de tanımlananın basitleştirilmiş bir versiyonudur. Bu süreç yalnızca bir oturumun veri aşaması için tanımlanmıştır. Handshake sırasında migrasyon izin verilmez. Tüm handshake paketleri, daha önce gönderilen ve alınan paketlerle aynı IP ve port’tan geldiği doğrulanmalıdır. Başka bir deyişle, bir peer’ın IP’si ve port’u handshake sırasında sabit olmalıdır.

Threat Model

(QUIC RFC 9000‘dan uyarlanmıştır)

Notlar

Bir peer, bir endpoint’in isteksiz bir sunucuya aşırı miktarda veri göndermesine neden olmak için kaynak adresini taklit edebilir. Endpoint, taklit eden peer’dan önemli ölçüde daha fazla veri gönderirse, bağlantı geçişi bir saldırganın bir kurbana karşı üretebileceği veri hacmini artırmak için kullanılabilir.

Oturum Onaylandı Parçalama

Yol üzerindeki bir saldırgan, sahte adresli bir paketi kopyalayıp ileterek ve bu paketin orijinal paketten önce ulaşmasını sağlayarak sahte bir bağlantı migrasyonuna neden olabilir. Sahte adresli paket göç eden bir bağlantıdan geliyormuş gibi görünecek ve orijinal paket tekrar eden paket olarak algılanıp düşürülecektir. Sahte bir migrasyondan sonra, kaynak adres doğrulaması başarısız olacaktır çünkü kaynak adresteki varlık, istese bile kendisine gönderilen Path Challenge’ı okumak veya yanıtlamak için gerekli kriptografik anahtarlara sahip değildir.

Off-Path Packet Forwarding

Paketleri gözlemleyebilen yol-dışı bir saldırgan, gerçek paketlerin kopyalarını uç noktalara iletebilir. Kopyalanan paket gerçek paketten önce ulaşırsa, bu bir NAT yeniden bağlanması olarak görünür. Gerçek paket duplikat olarak atılır. Saldırgan paket iletmeye devam edebilirse, saldırgan üzerinden geçen bir yola geçişe neden olabilir. Bu, saldırgana sonraki tüm paketleri gözlemleme veya düşürme yetisi vererek onu yol-üstü konuma getirir.

Privacy Implications

QUIC RFC 9000, ağ yollarını değiştirirken bağlantı kimliklerinin değiştirilmesini belirtmiştir. Birden fazla ağ yolunda kararlı bir bağlantı kimliği kullanmak, pasif bir gözlemcinin bu yollar arasındaki etkinliği ilişkilendirmesine izin verir. Ağlar arasında hareket eden bir uç nokta, etkinliklerinin eşi dışındaki herhangi bir varlık tarafından ilişkilendirilmesini istemeyebilir. Ancak, QUIC başlıktaki bağlantı kimliklerini şifrelemez. SSU2 bunu yapar, dolayısıyla gizlilik sızıntısı pasif gözlemcinin aynı zamanda bağlantı kimliğini çözmek için gerekli giriş anahtarını elde etmek üzere ağ veritabanına erişimine sahip olmasını gerektirir. Giriş anahtarıyla bile bu güçlü bir saldırı değildir ve biz SSU2’de göçten sonra bağlantı kimliklerini değiştirmiyoruz, çünkü bu önemli bir karmaşıklık olurdu.

Initiating Path Validation

Veri aşamasında, peer’lar aldıkları her veri paketinin kaynak IP’sini ve portunu kontrol etmelidir. Eğer IP veya port daha önce alınandan farklıysa VE paket tekrarlanan bir paket numarası değilse VE paket başarılı bir şekilde şifre çözülüyorsa, oturum yol doğrulama aşamasına geçer.

Ek olarak, bir peer yeni IP ve port’un yerel doğrulama kurallarına göre geçerli olduğunu doğrulamalıdır (engellenmiş değil, yasak portlar değil, vb.). Peer’lar IPv4 ve IPv6 arasındaki migration’ı desteklemek zorunda DEĞİLDİR ve diğer adres ailesindeki yeni bir IP’yi geçersiz olarak değerlendirebilir, çünkü bu beklenen bir davranış değildir ve önemli uygulama karmaşıklığı ekleyebilir. Geçersiz bir IP/port’tan paket aldığında, bir uygulama bunu basitçe düşürebilir veya eski IP/port ile bir path validation başlatabilir.

Yol doğrulama aşamasına girdikten sonra, aşağıdaki adımları izleyin:

• Birkaç saniye veya mevcut RTO’nun birkaç katı kadar bir yol doğrulama zaman aşımı zamanlayıcısı başlat (TBD)
• Tıkanıklık penceresini minimuma düşür
• PMTU’yu minimuma düşür (1280)
• Yeni IP ve porta bir Path Challenge bloğu, bir Address bloğu (yeni IP/port içeren), ve genellikle bir ACK bloğu içeren bir veri paketi gönder. Bu paket mevcut oturumla aynı bağlantı kimliğini ve şifreleme anahtarlarını kullanır. Path Challenge bloğu verisi yeterli entropi içermelidir (en az 8 bayt) böylece taklit edilemez.
• İsteğe bağlı olarak, eski IP/porta da farklı blok verisi ile bir Path Challenge gönder. Aşağıya bakın.
• Mevcut RTO’ya dayalı bir Path Response zaman aşımı zamanlayıcısı başlat (genellikle RTT + RTTdev’in katları)

Yol doğrulama aşamasındayken, oturum gelen paketleri işlemeye devam edebilir. Eski veya yeni IP/port’tan olsun fark etmez. Oturum ayrıca veri paketleri göndermeye ve onaylamaya da devam edebilir. Ancak, sahte bir adrese büyük miktarda trafik göndererek hizmet reddi saldırıları için kullanılmasını önlemek amacıyla, tıkanıklık penceresi ve PMTU’nun yol doğrulama aşaması boyunca minimum değerlerde kalması gerekir.

Bir uygulama, aynı anda birden fazla yolu doğrulamaya çalışabilir ancak bunu yapmak zorunda değildir. Bu muhtemelen karmaşıklığa değmez. Önceki bir IP/port’u zaten doğrulanmış olarak hatırlayabilir ve bir peer önceki IP/port’una geri dönerse yol doğrulamasını atlayabilir, ancak bunu yapmak zorunda değildir.

Path Response alınırsa ve Path Challenge’da gönderilen verilerle aynı veriyi içeriyorsa, Path Validation başarılı olmuştur. Path Response mesajının kaynak IP/port’unun Path Challenge’ın gönderildiği adresle aynı olması gerekmez.

Path Response timer süresi dolmadan önce bir Path Response alınmazsa, başka bir Path Challenge gönder ve Path Response timer süresini ikiye katla.

Path Validation zamanlayıcısının süresi dolmadan önce bir Path Response alınmazsa, Path Validation başarısız olmuştur.

Message Contents

Data mesajları aşağıdaki blokları içermelidir. Padding’in son olması dışında sıra belirtilmemiştir:

• Path Validation veya Path Response bloğu. Path Validation opak veri içerir, minimum 8 bayt önerilir. Path Response, Path Validation’dan gelen veriyi içerir.
• Alıcının görünen IP’sini içeren Address bloğu
• DateTime bloğu
• ACK bloğu
• Padding bloğu

Mesaja başka bloklar (örneğin I2NP) dahil etmek önerilmez.

Path Response içeren mesajda, diğer yönde bir doğrulama başlatmak için bir Path Validation bloğu dahil etmek mümkündür.

Path Challenge ve Path Response blokları ACK-tetikleyicidir. Path Challenge, Path Response ve ACK bloklarını içeren bir Data mesajı tarafından ACK’lenecektir. Path Response, bir ACK bloğu içeren bir Data mesajı tarafından ACK’lenmelidir.

Routing during Path Validation

QUIC spesifikasyonu, yol doğrulama sırasında veri paketlerinin nereye gönderileceği konusunda - eski veya yeni IP/port’a - net değildir. IP/port değişikliklerine hızla yanıt vermek ile sahte adreslere trafik göndermemek arasında bir denge kurulmalıdır. Ayrıca, sahte paketlerin mevcut bir oturumu önemli ölçüde etkilemesine izin verilmemelidir. Yalnızca port değişiklikleri muhtemelen boşta kalma süresinden sonra NAT yeniden bağlanmasından kaynaklanır; IP değişiklikleri bir veya her iki yönde yüksek trafik aşamaları sırasında gerçekleşebilir.

Stratejiler araştırma ve iyileştirmeye tabidir. Olasılıklar şunları içerir:

• Yeni IP/port doğrulanana kadar veri paketleri gönderilmemesi
• Yeni IP/port doğrulanana kadar eski IP/port’a veri paketleri gönderilmeye devam edilmesi
• Eski IP/port’un aynı anda yeniden doğrulanması
• Eski veya yeni IP/port’tan biri doğrulanana kadar hiç veri gönderilmemesi
• Sadece port değişikliği için IP değişikliğinden farklı stratejiler
• Geçici adres rotasyonundan kaynaklanması muhtemel aynı /32 içindeki IPv6 değişikliği için farklı stratejiler

Responding to Path Challenge

Bir Path Challenge alındığında, peer Path Challenge’dan gelen verilerle birlikte Path Response içeren bir veri paketi ile yanıt vermelidir. TODO Belki???: Path Response, Path Challenge’ın alındığı IP/port adresine gönderilmelidir. Bu, peer için önceden kurulmuş olan IP/port adresi ile MUTLAKA AYNI OLMAK ZORUNDA DEĞİLDİR. Bu, bir peer tarafından yapılan path validation’ın yalnızca yol her iki yönde de işlevsel ise başarılı olmasını sağlar. Aşağıdaki Yerel Değişiklik Sonrası Doğrulama bölümüne bakın.

IP/port, peer için daha önce bilinen IP/port’tan farklı olmadıkça, Path Challenge’ı basit bir ping olarak değerlendirin ve koşulsuz olarak Path Response ile yanıtlayın. Alıcı, alınan Path Challenge’a dayalı olarak herhangi bir durum tutmaz veya değiştirmez. IP/port farklıysa, bir peer yeni IP ve port’un yerel doğrulama kurallarına göre geçerli olduğunu doğrulamalıdır (engellenmiş değil, yasak portlar değil, vb.). Peer’ların IPv4 ve IPv6 arasında çapraz adres ailesi yanıtlarını desteklemesi GEREKLİ DEĞİLDİR ve diğer adres ailesindeki yeni bir IP’yi geçersiz olarak değerlendirebilirler, çünkü bu beklenen davranış değildir.

Tıkanıklık kontrolü tarafından kısıtlanmadığı sürece, Path Response hemen gönderilmelidir. Uygulamalar gerekirse Path Response’ları veya kullanılan bant genişliğini hız sınırlaması yapmak için önlemler almalıdır.

Bir Path Challenge bloğuna genellikle aynı mesajda bir Address bloğu eşlik eder. Eğer address bloğu yeni bir IP/port içeriyorsa, bir peer bu IP/port’u doğrulayabilir ve o yeni IP/port’un peer testini, session peer’ı veya herhangi bir başka peer ile başlatabilir. Eğer peer’ın firewall arkasında olduğunu düşünüyorsa ve sadece port değiştiyse, bu değişiklik muhtemelen NAT rebinding’den kaynaklanıyordur ve daha fazla peer testine muhtemelen gerek yoktur.

Successful Path Validation

Başarılı yol doğrulamasında, bağlantı tamamen yeni IP/port’a taşınır. Başarı durumunda:

• Path doğrulama aşamasından çık
• Tüm paketler yeni IP ve porta gönderilir.
• Tıkanıklık penceresi ve PMTU üzerindeki kısıtlamalar kaldırılır ve artışlarına izin verilir. Yeni path farklı özelliklere sahip olabileceğinden, bunları eski değerlere basitçe geri yüklemeyin.
• IP değiştiyse, hesaplanan RTT ve RTO’yu başlangıç değerlerine ayarlayın. Yalnızca port değişiklikleri genellikle NAT rebinding veya diğer middlebox aktivitesinin sonucu olduğundan, peer bunun yerine başlangıç değerlerine dönmek yerine bu durumlarda tıkanıklık kontrol durumunu ve gidiş-dönüş tahminini koruyabilir.
• Eski IP/port için gönderilen veya alınan tüm token’ları sil (geçersiz kıl) (isteğe bağlı)
• Yeni IP/port için yeni bir token bloğu gönder (isteğe bağlı)

Cancelling Path Validation

Yol doğrulama aşamasındayken, eski IP/port’tan alınan ve başarıyla şifrelenmiş olan geçerli, tekrar etmeyen paketler Yol Doğrulamasının iptal edilmesine neden olur. Sahte bir paket nedeniyle iptal edilen bir yol doğrulamasının, geçerli bir oturumun sonlandırılmasına veya önemli ölçüde kesintiye uğramasına neden olmaması önemlidir.

İptal edilen yol doğrulaması üzerine:

• Yol doğrulama aşamasından çık
• Tüm paketler eski IP ve port’a gönderilir.
• Tıkanıklık penceresi ve PMTU üzerindeki kısıtlamalar kaldırılır ve bunların artmasına izin verilir, ya da isteğe bağlı olarak önceki değerler geri yüklenir
• Daha önce yeni IP/port’a gönderilen veri paketlerini eski IP/port’a yeniden ilet.

Failed Path Validation

Sahte bir paket nedeniyle başarısız olan yol doğrulamasının, geçerli bir oturumun sonlandırılmasına veya önemli ölçüde kesintiye uğramasına neden olmaması önemlidir.

Başarısız yol doğrulamasında:

• Path validation aşamasından çık
• Tüm paketler eski IP ve port’a gönderilir.
• Congestion window ve PMTU üzerindeki kısıtlamalar kaldırılır ve artışlarına izin verilir.
• İsteğe bağlı olarak, eski IP ve port üzerinde path validation başlat. Başarısız olursa, oturumu sonlandır.
• Aksi takdirde, standart oturum timeout ve sonlandırma kurallarını izle.
• Daha önce yeni IP/port’a gönderilmiş olan veri paketlerini eski IP/port’a yeniden ilet.

Validation After Local Change

Yukarıdaki süreç, değişen IP/port’tan paket alan eş düğümler (peer) için tanımlanmıştır. Ancak bu süreç, IP veya port’unun değiştiğini tespit eden bir eş düğüm tarafından diğer yönde de başlatılabilir. Bir eş düğüm yerel IP’sinin değiştiğini tespit edebilir; ancak NAT yeniden bağlanması nedeniyle port’unun değiştiğini tespit etmesi çok daha az olasıdır. Bu nedenle, bu isteğe bağlıdır.

IP’si veya portu değişmiş bir eşten path challenge aldığında, diğer eş karşı yönde bir path challenge başlatmalıdır.

Röle Güvenliği

Path Validation ve Path Response blokları her zaman Ping/Pong paketleri olarak kullanılabilir. Path Validation bloğunun alınması, farklı bir IP/port’tan alınmadığı sürece alıcıda herhangi bir durum değişikliğine neden olmaz.

Multiple Sessions

Eş düğümler aynı eş düğümle, ister SSU 1 ister 2 olsun, veya aynı ya da farklı IP adresleriyle birden fazla oturum kurmamalıdır. Ancak bu durum hatalar nedeniyle, önceki bir oturum sonlandırma mesajının kaybolması nedeniyle veya sonlandırma mesajının henüz ulaşmadığı bir yarış durumunda gerçekleşebilir.

Bob’un Alice ile mevcut bir oturumu varsa, Bob Alice’den Session Confirmed mesajını aldığında, el sıkışmayı tamamlayıp yeni bir oturum kurduğunda, Bob şunları yapmalıdır:

• Eski oturumdan yeni oturuma gönderilmemiş veya onaylanmamış giden I2NP mesajlarını taşı
• Eski oturum üzerinde sebep kodu 22 ile sonlandırma gönder
• Eski oturumu kaldır ve yerine yenisini koy

Session Termination

Peer Test Güvenliği

Handshake aşamasındaki oturumlar genellikle basitçe zaman aşımına uğrayarak veya daha fazla yanıt vermeyerek sonlandırılır. İsteğe bağlı olarak, yanıtta bir Termination bloğu dahil ederek sonlandırılabilirler, ancak çoğu hataya kriptografik anahtarların eksikliği nedeniyle yanıt vermek mümkün değildir. Termination bloğu içeren bir yanıt için anahtarlar mevcut olsa bile, yanıt için DH gerçekleştirmek genellikle CPU’ya değmez. Bir istisna, oluşturması ucuz olan bir yeniden deneme mesajındaki Termination bloğu OLABİLİR.

Relay ve Peer Test Tasarım Hedefleri

Veri fazındaki oturumlar, bir Termination bloğu içeren bir veri mesajı gönderilerek sonlandırılır. Bu mesaj ayrıca bir ACK bloğu da içermelidir. Eğer oturum, daha önce gönderilmiş bir token’ın süresi dolacak kadar uzun süre aktifse, bir New Token bloğu da içerebilir. Bu mesaj ack-eliciting değildir. “Termination Received” dışında herhangi bir nedenle Termination bloğu aldığında, eş, “Termination Received” nedenini içeren bir Termination bloğu barındıran bir veri mesajıyla yanıt verir.

Bir Termination bloğu gönderdikten veya aldıktan sonra, oturum belirlenecek maksimum süre boyunca kapanış aşamasına girmelidir. Kapanış durumu, Termination bloğunu içeren paketin kaybolmasına ve diğer yöndeki uçuşta olan paketlere karşı koruma sağlamak için gereklidir. Kapanış aşamasındayken, alınan ek paketlerin işlenmesi zorunlu değildir. Kapanış durumundaki bir oturum, oturuma atfettiği herhangi bir gelen pakete yanıt olarak Termination bloğu içeren bir paket gönderir. Bir oturum, kapanış durumunda ürettiği paket hızını sınırlamalıdır. Örneğin, bir oturum alınan paketlere yanıt vermeden önce giderek artan sayıda alınan paket veya zaman miktarı bekleyebilir.

Kapanan bir oturum için bir router’ın koruduğu durumu minimize etmek için, oturumlar alınan herhangi bir pakete yanıt olarak aynı paket numarasıyla tamamen aynı paketi gönderebilir, ancak bunu yapmak zorunda değildir. Not: Sonlandırma paketinin yeniden iletilmesine izin verilmesi, her paket için yeni bir paket numarası kullanılması gerekliliğinin bir istisnasıdır. Yeni paket numaraları göndermek öncelikle kayıp kurtarma ve tıkanıklık kontrolü için avantajlıdır, bunların kapalı bir bağlantı için gerekli olması beklenmez. Son paketi yeniden iletmek daha az durum gerektirir.

“Termination Received” nedeniyle bir Termination bloğu aldıktan sonra, oturum kapanma aşamasından çıkabilir.

Cleanup

Normal veya anormal sonlandırma durumlarında, router’lar bellekteki tüm geçici verileri sıfırlamalıdır; bu veriler handshake geçici anahtarları, simetrik kripto anahtarları ve ilgili bilgileri içerir.

MTU

Gereksinimler, yayınlanan adresin SSU 1 ile paylaşılıp paylaşılmamasına bağlı olarak değişir. Mevcut SSU 1 IPv4 minimumu 620’dir, bu kesinlikle çok küçük.

Minimum SSU2 MTU değeri hem IPv4 hem de IPv6 için 1280’dir ve bu RFC 9000‘de belirtilen değerle aynıdır. Aşağıya bakınız. Minimum MTU değerinin artırılmasıyla, 1 KB tunnel mesajları ve kısa tunnel build mesajları tek bir datagram’a sığacak ve böylece tipik fragmentation miktarı büyük ölçüde azalacaktır. Bu aynı zamanda maksimum I2NP mesaj boyutunda artış yapılmasına da olanak tanır. 1820 byte’lık streaming mesajları iki datagram’a sığmalıdır.

Bir router, o adres için MTU en az 1280 olmadıkça SSU2’yi etkinleştirmemeli veya bir SSU2 adresi yayınlamamalıdır.

Router’lar her SSU veya SSU2 router adresinde varsayılan olmayan bir MTU yayınlamalıdır.

Özet

SSU 1 ile paylaşılan adres, SSU 1 kurallarını takip etmelidir. IPv4: Varsayılan ve maksimum 1484’tür. Minimum 1292’dir. (IPv4 MTU + 4) 16’nın katı olmalıdır. IPv6: Yayınlanmalıdır, minimum 1280 ve maksimum 1488’dir. IPv6 MTU 16’nın katı olmalıdır.

Teslimat Garantileri

IPv4: Varsayılan ve maksimum 1500’dür. Minimum 1280’dir. IPv6: Varsayılan ve maksimum 1500’dür. Minimum 1280’dir. 16’nın katı kuralları yoktur, ancak muhtemelen en azından 2’nin katı olmalıdır.

Noise Protocol Framework

SSU 1 için, mevcut Java I2P PMTU keşfini küçük paketlerle başlayarak ve boyutu kademeli olarak artırarak veya alınan paket boyutuna göre artırarak gerçekleştirir. Bu yöntem kabadır ve verimliliği büyük ölçüde azaltır. Bu özelliğin SSU 2’de devam ettirilmesi henüz belirlenmemiştir.

Son çalışmalar PMTU, IPv4 için 1200 veya daha yüksek bir minimum değerin bağlantıların %99’undan fazlası için işe yarayacağını öne sürüyor. QUIC RFC 9000, minimum 1280 bayt IP paket boyutu gerektiriyor.

RFC 9000‘dan alıntı:

Maksimum datagram boyutu, tek bir UDP datagramı kullanarak bir ağ yolu üzerinden gönderilebilecek en büyük UDP payload boyutu olarak tanımlanır. Ağ yolu en az 1200 bayt maksimum datagram boyutunu destekleyemiyorsa QUIC KULLANILMAMALIDIR.

QUIC en az 1280 bayt boyutunda minimum IP paket boyutu varsayar. Bu IPv6 minimum boyutudur [IPv6] ve ayrıca çoğu modern IPv4 ağı tarafından da desteklenir. IPv6 için 40 bayt ve IPv4 için 20 bayt olan minimum IP başlık boyutunu ve 8 bayt UDP başlık boyutunu varsayarsak, bu IPv6 için 1232 bayt ve IPv4 için 1252 bayt maksimum datagram boyutu ile sonuçlanır. Bu nedenle, modern IPv4 ve tüm IPv6 ağ yollarının QUIC’i destekleyebilmesi beklenir.

Not: 1200 bayt UDP yükünü destekleme gerekliliği, yol yalnızca 1280 baytlık IPv6 minimum MTU’sunu destekliyorsa, IPv6 uzantı başlıkları için mevcut alanı 32 bayt ile veya IPv4 seçenekleri için 52 bayt ile sınırlar. Bu durum Initial paketlerini ve yol doğrulamasını etkiler.

alıntı sonu

Framework’e Eklemeler

QUIC, amplifikasyon saldırılarını önlemek ve PMTU’nun her iki yönde de bunu desteklediğinden emin olmak için her iki yöndeki İlk datagramların en az 1200 bayt olmasını gerektirir.

Bunu Session Request ve Session Created için gerekli kılabiliriz, ancak bant genişliğinde önemli bir maliyetle. Belki bunu sadece bir token’ımız yoksa veya bir Retry mesajı alındıktan sonra yapabiliriz. TBD

QUIC, Bob’un istemci adresi doğrulanana kadar alınan veri miktarının üç katından fazlasını göndermemesini gerektirir. SSU2 bu gereksinimi doğal olarak karşılar, çünkü Retry mesajı Token Request mesajı ile yaklaşık aynı boyuttadır ve Session Request mesajından daha küçüktür. Ayrıca, Retry mesajı yalnızca bir kez gönderilir.

İşleme yükü tahmini

QUIC, PATH_CHALLENGE veya PATH_RESPONSE blokları içeren mesajların amplifikasyon saldırılarını önlemek için en az 1200 bayt olmasını gerektirir ve PMTU’nun bunu her iki yönde de desteklediğinden emin olur.

Bunu da gerekli kılabilirdik, ancak bant genişliği açısından önemli bir maliyetle. Bununla birlikte, bu durumlar nadir olmalıdır. TBD

Max I2NP Message Size

IPv4: IP parçalama varsayılmamaktadır. IP + datagram başlığı 28 bayttır. Bu IPv4 seçeneklerinin olmadığını varsayar. Maksimum mesaj boyutu MTU - 28’dir. Veri fazı başlığı 16 bayt ve MAC 16 bayttır, toplamda 32 bayt. Yük boyutu MTU - 60’tır. Maksimum veri fazı yükü maksimum 1500 MTU için 1440’tır. Maksimum veri fazı yükü minimum 1280 MTU için 1220’dir.

IPv6: IP fragmentasyonuna izin verilmez. IP + datagram başlığı 48 bayttır. Bu, IPv6 uzantı başlıklarının olmadığını varsayar. Maksimum mesaj boyutu MTU - 48’dir. Veri fazı başlığı 16 bayt ve MAC 16 bayttır, toplam 32 bayt. Payload boyutu MTU - 80’dir. Maksimum veri fazı payload’u maksimum 1500 MTU için 1420’dir. Maksimum veri fazı payload’u minimum 1280 MTU için 1200’dür.

SSU 1’de yönergeler, 64 maksimum fragment ve 620 minimum MTU’ya dayanan bir I2NP mesajı için yaklaşık 32 KB’lık katı bir maksimum sınırdı. Paketlenmiş LeaseSet’ler ve oturum anahtarları için ek yük nedeniyle, uygulama seviyesindeki pratik sınır yaklaşık 6KB daha düşüktü, yani yaklaşık 26KB. SSU 1 protokolü 128 fragment’a izin verir ancak mevcut uygulamalar bunu 64 fragment ile sınırlar.

Minimum MTU’yu 1280’e çıkararak, yaklaşık 1200’lük bir veri aşaması yükü ile, SSU 2 mesajının 64 parçada yaklaşık 76 KB ve 128 parçada 152 KB olması mümkündür. Bu, kolayca maksimum 64 KB’a izin verir.

Tünellerdeki parçalanma ve SSU 2’deki parçalanma nedeniyle, mesaj kaybı olasılığı mesaj boyutuyla üssel olarak artar. I2NP datagramları için uygulama katmanında yaklaşık 10 KB’lık pratik bir sınır öneriyi sürdürüyoruz.

Peer Test Process

SSU1 Peer Test ve SSU2 Peer Test hedefleri analizi için yukarıdaki Peer Test Güvenliği bölümüne bakın.

Alice                     Bob                  Charlie
1. PeerTest ------------------->
                              Alice RI ------------------->
2.                          PeerTest ------------------->
3.                             <------------------ PeerTest
          <---------------- Charlie RI
4.      <------------------ PeerTest

5.      <----------------------------------------- PeerTest
6. PeerTest ----------------------------------------->
7.      <----------------------------------------- PeerTest

Bob tarafından reddedildiğinde:

Alice                     Bob                  Charlie
1. PeerTest ------------------->
4.      <------------------ PeerTest (reject)

Charlie tarafından reddedildiğinde:

Alice                     Bob                  Charlie
1. PeerTest ------------------->
                              Alice RI ------------------->
2.                          PeerTest ------------------->
3.                             <------------------ PeerTest (reject)
                        (optional: Bob could try another Charlie here)
4.      <------------------ PeerTest (reject)

NOT: RI, I2NP blokları içinde I2NP Database Store mesajları olarak ya da (yeterince küçükse) RI blokları olarak gönderilebilir. Bunlar, yeterince küçükse, peer test blokları ile aynı paketlerde bulunabilir.

Mesajlar 1-4, bir Veri mesajındaki Peer Test blokları kullanılarak oturum içinde gerçekleşir. Mesajlar 5-7, bir Peer Test mesajındaki Peer Test blokları kullanılarak oturum dışında gerçekleşir.

NOT: SSU 1’de olduğu gibi, mesaj 4 ve 5 herhangi bir sırada gelebilir. Alice güvenlik duvarının arkasındaysa mesaj 5 ve/veya 7 hiç alınamayabilir. Mesaj 5, mesaj 4’ten önce geldiğinde, Alice derhal mesaj 6’yı gönderemez çünkü henüz başlığı şifrelemek için Charlie’nin intro key’ine sahip değildir. Mesaj 4, mesaj 5’ten önce geldiğinde, Alice derhal mesaj 6’yı göndermemelidir çünkü mesaj 6 ile güvenlik duvarını açmadan önce mesaj 5’in gelip gelmeyeceğini beklemesi gerekir.

Versions

Sürümler arası peer testi desteklenmez. İzin verilen tek sürüm kombinasyonu, tüm peer’ların sürüm 2 olduğu durumdur.

Oturum Kurulumu

Mesajlar 1-4 oturum içindedir ve veri aşaması ACK ve yeniden iletim süreçleri tarafından kapsanır. Peer Test blokları ack-tetikleyicidir.

Mesajlar 5-7 değiştirilmeden yeniden iletilebilir.

Paket Başlığı

SSU 1’de olduğu gibi, IPv6 adreslerinin test edilmesi desteklenir ve Bob ile Charlie, yayınladıkları IPv6 adresinde ‘B’ yeteneği ile destek belirtirse, Alice-Bob ve Alice-Charlie iletişimi IPv6 üzerinden olabilir. Ayrıntılar için Proposal 126’ya bakınız.

0.9.50 öncesi SSU 1’de olduğu gibi, Alice isteği test etmek istediği transport (IPv4 veya IPv6) üzerinden mevcut bir oturum kullanarak Bob’a gönderir. Bob, Alice’den IPv4 üzerinden bir istek aldığında, Bob bir IPv4 adresi yayınlayan bir Charlie seçmelidir. Bob, Alice’den IPv6 üzerinden bir istek aldığında, Bob bir IPv6 adresi yayınlayan bir Charlie seçmelidir. Gerçek Bob-Charlie iletişimi IPv4 veya IPv6 üzerinden olabilir (yani Alice’in adres tipinden bağımsız). Bu, karışık IPv4/v6 isteklerine izin verilen 0.9.50 itibariyle SSU 1’in davranışı DEĞİLDİR.

Processing by Bob

SSU 1’den farklı olarak, Alice istenen test IP’sini ve portunu mesaj 1’de belirtir. Bob bu IP ve portu doğrulamalı ve geçersizse kod 5 ile reddetmelidir. Önerilen IP doğrulaması, IPv4 için Alice’in IP’siyle eşleşmesi ve IPv6 için IP’nin en az ilk 8 baytının eşleşmesidir. Port doğrulaması ayrıcalıklı portları ve bilinen protokoller için portları reddetmelidir.

Relay Process

SSU1 Relay analizi ve SSU2 Relay hedefleri için yukarıdaki Relay Güvenliği bölümüne bakın.

Alice                         Bob                  Charlie
     lookup Bob RI

     SessionRequest -------------------->
          <------------  SessionCreated
     SessionConfirmed  ----------------->

1. RelayRequest ---------------------->
                                           Alice RI  ------------>
2.                                       RelayIntro ----------->
3.                                  <-------------- RelayResponse
4.      <-------------- RelayResponse

5.      <-------------------------------------------- HolePunch
6. SessionRequest -------------------------------------------->
7.      <-------------------------------------------- SessionCreated
8. SessionConfirmed ------------------------------------------>

Bob tarafından reddedildiğinde:

Alice                         Bob                  Charlie
     lookup Bob RI

     SessionRequest -------------------->
          <------------  SessionCreated
     SessionConfirmed  ----------------->

1. RelayRequest ---------------------->
4.      <-------------- RelayResponse

Charlie tarafından reddedildiğinde:

Alice                         Bob                  Charlie
     lookup Bob RI

     SessionRequest -------------------->
          <------------  SessionCreated
     SessionConfirmed  ----------------->

1. RelayRequest ---------------------->
                                           Alice RI  ------------>
2.                                       RelayIntro ----------->
3.                                  <-------------- RelayResponse
4.      <-------------- RelayResponse

NOT: RI ya I2NP bloklarında I2NP Database Store mesajları olarak ya da (yeterince küçükse) RI blokları olarak gönderilebilir. Bunlar, yeterince küçükse, relay blokları ile aynı paketlerde bulunabilir.

SSU 1’de, Charlie’nin router bilgisi her introducer’ın IP’sini, portunu, intro anahtarını, relay etiketini ve son kullanma tarihini içerir.

SSU 2’de, Charlie’nin router bilgisi her introducer için router hash, relay tag ve expiration bilgilerini içerir.

Alice, öncelikle zaten bağlantısı olan bir introducer (Bob) seçerek gerekli gidiş-dönüş sayısını azaltmalıdır. İkinci olarak, eğer böyle biri yoksa, router bilgisine zaten sahip olduğu bir introducer seçmelidir.

Sürümler arası aktarım da mümkünse desteklenmelidir. Bu, SSU 1’den SSU 2’ye kademeli geçişi kolaylaştıracaktır. İzin verilen sürüm kombinasyonları şunlardır (TODO):

Retransmissions

Relay Request, Relay Intro ve Relay Response’un tümü oturum içindedir ve veri fazı ACK ve yeniden iletim süreçleri tarafından kapsanır. Relay Request, Relay Intro ve Relay Response blokları ack-eliciting’dir.

Hole punch, SSU 1’de olduğu gibi yeniden iletilebilir.

IPv4/v6

SSU 1 relay’in tüm özellikleri desteklenir, bunlara Proposal 158 içinde belgelenen ve 0.9.50 sürümünden itibaren desteklenen özellikler dahildir. IPv4 ve IPv6 introduction’ları desteklenir. Bir Relay Request, IPv6 introduction için IPv4 oturumu üzerinden gönderilebilir ve bir Relay Request, IPv4 introduction için IPv6 oturumu üzerinden gönderilebilir.

Processing by Alice

Aşağıda SSU 1’den farklılıklar ve SSU 2 implementasyonu için öneriler bulunmaktadır.

Notlar

SSU 1’de, introduction nispeten ucuzdur ve Alice genellikle tüm introducer’lara Relay Request’leri gönderir. SSU 2’de, introduction daha pahalıdır çünkü önce bir introducer ile bağlantı kurulması gerekir. Introduction gecikmesini ve yükünü minimize etmek için önerilen işleme adımları şu şekildedir:

• Adreste yer alan iexp değerine göre süresi dolmuş olan herhangi bir introducer’ı yok say
• Bir veya daha fazla introducer’a SSU2 bağlantısı zaten kurulmuşsa, birini seç ve Relay Request’i sadece o introducer’a gönder.
• Aksi takdirde, bir veya daha fazla introducer için Router Info yerel olarak biliniyorsa, birini seç ve sadece o introducer’a bağlan.
• Aksi takdirde, tüm introducer’lar için Router Info’ları ara, Router Info’su ilk alınan introducer’a bağlan.

Notlar

Hem SSU 1 hem de SSU 2’de, Relay Response ve Hole Punch herhangi bir sırada alınabilir veya hiç alınmayabilir.

SSU 1’de, Alice genellikle Hole Punch’tan (1 1/2 RTT) önce Relay Response’u (1 RTT) alır. Bu spesifikasyonlarda iyi belgelenmemiş olabilir, ancak Alice Charlie’nin IP’sini almak için devam etmeden önce Bob’dan Relay Response’u almalıdır. Hole Punch önce alınırsa, Alice bunu tanımayacaktır çünkü veri içermez ve kaynak IP tanınmaz. Relay Response’u aldıktan sonra, Alice Charlie ile handshake’i başlatmadan önce Charlie’den Hole Punch’ı almayı YA DA kısa bir gecikmeyi (önerilen 500 ms) beklemelidir.

SSU 2’de, Alice genellikle Hole Punch’ı (1 1/2 RTT) Relay Response’tan (2 RTT) önce alacaktır. SSU 2 Hole Punch, SSU 1’dekinden daha kolay işlenir, çünkü tanımlanmış bağlantı ID’leri (relay nonce’dan türetilmiş) ve Charlie’nin IP’si dahil içeriklerle tam bir mesajdır. Relay Response (Data mesajı) ve Hole Punch mesajı aynı imzalanmış Relay Response bloğunu içerir. Bu nedenle, Alice ya Charlie’den Hole Punch aldıktan SONRA ya da Bob’dan Relay Response aldıktan SONRA Charlie ile handshake’i başlatabilir.

Hole Punch’ın imza doğrulaması, tanıtıcının (Bob’un) router hash’ini içerir. Eğer Relay Request’leri birden fazla tanıtıcıya gönderildiyse, imzayı doğrulamak için birkaç seçenek vardır:

• Bir isteğin gönderildiği her hash’i dene
• Her introducer için farklı nonce’lar kullan ve bunu bu Hole Punch’ın hangi introducer’a yanıt olduğunu belirlemek için kullan
• Eğer içerik daha önce alınmış olan Relay Response’dakiyle aynıysa, imzayı yeniden doğrulama
• İmzayı hiç doğrulama

Charlie simetrik NAT arkasındaysa, Relay Response ve Hole Punch mesajlarında bildirdiği port doğru olmayabilir. Bu nedenle, Alice Hole Punch mesajının UDP kaynak portunu kontrol etmeli ve eğer bildirilen porttan farklıysa onu kullanmalıdır.

Tag Requests by Bob

SSU 1’de, yalnızca Alice bir etiket talep edebilirdi, Session Request içinde. Bob asla bir etiket talep edemezdi ve Alice, Bob için relay yapamazdı.

SSU2’de, Alice genellikle Session Request’te bir etiket ister, ancak hem Alice hem de Bob veri aşamasında da etiket isteyebilir. Bob genellikle gelen bir istek aldıktan sonra güvenlik duvarının arkasında değildir, ancak bir relay sonrasında olabilir veya Bob’un durumu değişebilir ya da diğer adres türü (IPv4/v6) için bir introducer isteyebilir. Bu nedenle, SSU2’de hem Alice’in hem de Bob’un aynı anda diğer taraf için relay olması mümkündür.

Published Router Info

Address Properties

Aşağıdaki adres özellikleri, API 0.9.50 itibariyle desteklenen Proposal 158‘deki değişiklikler dahil olmak üzere, SSU 1’den değiştirilmeden yayınlanabilir:

• caps: [B,C,4,6] yetenekleri

• host: IP (IPv4 veya IPv6). Kısaltılmış IPv6 adresi (”::” ile) kullanılabilir. Güvenlik duvarı arkasındaysa mevcut olabilir veya olmayabilir. Host isimleri kullanılamaz.

• iexp[0-2]: Bu tanıtıcının sona erme süresi. ASCII rakamları, epoch’tan bu yana saniye cinsinden. Yalnızca güvenlik duvarı arkasındaysa ve tanıtıcılar gerekliyse mevcut. İsteğe bağlı (bu tanıtıcı için diğer özellikler mevcut olsa bile).

• ihost[0-2]: Tanıtıcının IP adresi (IPv4 veya IPv6). Kısaltılmış IPv6 adresi (”::”) kullanılabilir. Yalnızca güvenlik duvarının arkasında ve tanıtıcılar gerekli olduğunda bulunur. Host adlarına izin verilmez. Yalnızca SSU adresi.

• ikey[0-2]: Introducer’ın Base 64 tanıtım anahtarı. Yalnızca güvenlik duvarı arkasındaysa ve introducer’lar gerekiyorsa mevcut. Yalnızca SSU adresi.

• iport[0-2]: Introducer’ın portu 1024 - 65535. Sadece güvenlik duvarının arkasındaysa ve introducer’lar gerekliyse mevcut. Sadece SSU adresi.

• itag[0-2]: Introducer’ın etiketi 1 - (2**32 - 1) ASCII rakamları. Yalnızca güvenlik duvarı arkasındaysa ve introducer’lar gerekiyorsa mevcut.

• key: Base 64 giriş anahtarı.

• mtu: İsteğe bağlı. Yukarıdaki MTU bölümüne bakın.

• port: 1024 - 65535 Güvenlik duvarı arkasındaysa mevcut olabilir veya olmayabilir.

Published Addresses

Yayınlanan RouterAddress (RouterInfo’nun bir parçası), “SSU” veya “SSU2” protokol tanımlayıcısına sahip olacaktır.

RouterAddress, SSU2 desteğini belirtmek için üç seçenek içermelidir:

• s=(Base64 key) Bu RouterAddress için mevcut Noise statik genel anahtar (s). Standart I2P Base 64 alfabesi kullanılarak Base 64 formatında kodlanmış. İkili sistemde 32 byte, Base 64 kodlamalı olarak 44 byte, little-endian X25519 genel anahtarı.

• i=(Base64 key) Bu RouterAddress için başlıkları şifrelemek amacıyla kullanılan mevcut introduction anahtarı. Standart I2P Base 64 alfabesi kullanılarak Base 64 kodlaması yapılmıştır. Binary formatında 32 byte, Base 64 kodlamasında 44 byte, big-endian ChaCha20 anahtarı.

• v=2 Mevcut sürüm (2). “SSU” olarak yayımlandığında, sürüm 1 için ek destek ima edilir. Gelecekteki sürümler için destek virgülle ayrılmış değerlerle olacak, örn. v=2,3 Uygulama, virgül varsa birden fazla sürüm dahil olmak üzere uyumluluğu doğrulamalıdır. Virgülle ayrılmış sürümler sayısal sırada olmalıdır.

Alice, SSU2 protokolünü kullanarak bağlanmadan önce üç seçeneğin de mevcut ve geçerli olduğunu doğrulamalıdır.

“s”, “i” ve “v” seçenekleri ile birlikte “host” ve “port” seçenekleri ile “SSU” olarak yayınlandığında, router hem SSU hem de SSU2 protokolleri için o host ve port üzerinden gelen bağlantıları kabul etmeli ve protokol sürümünü otomatik olarak algılamalıdır.

“s”, “i”, ve “v” seçenekleri ile ve “host” ve “port” seçenekleri ile “SSU2” olarak yayınlandığında, router o host ve port üzerinde yalnızca SSU2 protokolü için gelen bağlantıları kabul eder.

Bir router hem SSU1 hem de SSU2 bağlantılarını destekliyorsa ancak gelen bağlantılar için otomatik versiyon algılamayı uygulamıyorsa, hem “SSU” hem de “SSU2” adreslerini duyurmalı ve SSU2 seçeneklerini yalnızca “SSU2” adresine dahil etmelidir. Router, SSU2’nin tercih edilmesi için “SSU2” adresinde “SSU” adresinden daha düşük bir maliyet değeri (daha yüksek öncelik) ayarlamalıdır.

Aynı RouterInfo içinde birden fazla SSU2 RouterAddress (“SSU” veya “SSU2” olarak) yayınlanırsa (ek IP adresleri veya portlar için), aynı portu belirten tüm adresler özdeş SSU2 seçenekleri ve değerleri içermelidir. Özellikle, tümü aynı statik anahtar “s” ve tanıtım anahtarı “i” içermelidir.

Introducers

SSU veya SSU2 olarak introducers ile yayınlandığında, aşağıdaki seçenekler mevcuttur:

• ih[0-2]=(Base64 hash) Bir introducer için router hash’i. Standart I2P Base 64 alfabesi kullanılarak Base 64 ile kodlanmıştır. Binary olarak 32 byte, Base 64 kodlaması olarak 44 byte

• iexp[0-2]: Bu introducer’ın sona erme süresi. SSU 1’den değiştirilmemiş.

• itag[0-2]: Tanıtıcının etiketi 1 - (2**32 - 1) SSU 1’den değişmemiştir.

Aşağıdaki seçenekler yalnızca SSU içindir ve SSU2 için kullanılmaz. SSU2’de Alice bu bilgiyi bunun yerine Charlie’nin RI’sinden alır.

• ihost[0-2]
• ikey[0-2]
• itag[0-2]

Bir router, introducer yayınlarken adreste host veya port yayınlamamalıdır. Bir router, IPv4 ve/veya IPv6 desteğini belirtmek için introducer yayınlarken adreste 4 ve/veya 6 caps yayınlamalıdır. Bu, güncel SSU 1 adresleri için mevcut uygulamayla aynıdır.

Not: SSU olarak yayınlanırsa ve SSU 1 ile SSU2 introducer’ların karışımı varsa, eski router’larla uyumluluk için SSU 1 introducer’lar daha düşük indekslerde, SSU2 introducer’lar ise daha yüksek indekslerde olmalıdır.

Unpublished SSU2 Address

Alice, gelen bağlantılar için SSU2 adresini (“SSU” veya “SSU2” olarak) yayınlamıyorsa, Bob’un Session Confirmed bölüm 2’de Alice’in RouterInfo’sunu aldıktan sonra anahtarı doğrulayabilmesi için yalnızca statik anahtarını ve SSU2 sürümünü içeren bir “SSU2” router adresi yayınlamalıdır.

• s=(Base64 anahtar) Yayınlanan adresler için yukarıda tanımlandığı gibi.

• i=(Base64 key) Yukarıda yayınlanan adresler için tanımlandığı gibi.

• v=2 Yayınlanan adresler için yukarıda tanımlandığı gibi.

Bu router adresi “host” veya “port” seçeneklerini içermeyecektir, çünkü bunlar giden SSU2 bağlantıları için gerekli değildir. Bu adres için yayınlanan maliyet kesin olarak önemli değildir, çünkü sadece gelen bağlantılar içindir; ancak, maliyet diğer adreslerden daha yüksek (daha düşük öncelik) olarak ayarlanırsa diğer router’lar için yararlı olabilir. Önerilen değer 14’tür.

Alice ayrıca mevcut yayınlanmış bir “SSU” adresine basitçe “i”, “s” ve “v” seçeneklerini ekleyebilir.

Paket Bütünlüğü

NTCP2 ve SSU2 için aynı statik anahtarları kullanmak izin verilir, ancak önerilmez.

RouterInfo’ların önbelleğe alınması nedeniyle, router’lar router çalışır durumdayken, yayınlanmış bir adreste olsun ya da olmasın, statik public key veya IV’yi döndürmemelidir. Router’lar bu key ve IV’yi hemen yeniden başlatma sonrasında yeniden kullanım için kalıcı olarak saklamalıdır, böylece gelen bağlantılar çalışmaya devam edecek ve yeniden başlatma süreleri açığa çıkmayacaktır. Router’lar, başlangıçta önceki kesinti süresinin hesaplanabilmesi için son kapatılma zamanını kalıcı olarak saklamalı veya başka şekilde belirlemelidir.

Yeniden başlatma sürelerinin açığa çıkması konusundaki endişeler doğrultusunda, router’lar daha önce bir süre (en az birkaç gün) kapalı kalmışsa başlangıçta bu anahtarı veya IV’yi döndürebilir.

Router’ın yayımlanmış SSU2 RouterAddress’leri varsa (SSU veya SSU2 olarak), rotasyon öncesi minimum çalışmama süresi çok daha uzun olmalıdır, örneğin bir ay, yerel IP adresi değişmedikçe veya router “rekey” yapmadıkça.

Router’ın yayınlanmış SSU RouterAddress’leri varsa ancak SSU2’si yoksa (SSU veya SSU2 olarak), rotasyon öncesi minimum kesinti süresi daha uzun olmalıdır, örneğin bir gün, yerel IP adresi değişmedikçe veya router “rekey” işlemi yapmadıkça. Bu, yayınlanmış SSU adresinin introducer’ları olsa bile geçerlidir.

Router’ın herhangi bir yayınlanmış RouterAddress’i (SSU, SSU2 veya SSU) yoksa, router “rekeys” yapmadığı sürece, IP adresi değişse bile, rotasyon öncesi minimum kesinti süresi iki saat kadar kısa olabilir.

Router farklı bir Router Hash’e “rekey” yaparsa, yeni bir noise anahtarı ve intro anahtarı da üretmelidir.

Uygulamalar, statik public key veya IV’yi değiştirmenin, eski bir RouterInfo’yu önbelleğe almış router’lardan gelen SSU2 bağlantılarını engelleyeceğinin farkında olmalıdır. RouterInfo yayınlama, tunnel peer seçimi (hem OBGW hem de IB en yakın hop dahil), sıfır-hop tunnel seçimi, transport seçimi ve diğer uygulama stratejileri bunu hesaba katmalıdır.

Intro anahtar rotasyonu, anahtar rotasyonu ile aynı kurallara tabidir.

Not: Yeniden anahtarlama öncesi minimum kesinti süresi, ağ sağlığını sağlamak ve orta düzeyde bir süre kapalı kalan bir router’ın yeniden tohum almasını önlemek amacıyla değiştirilebilir.

Identity Hiding

İnkar edilebilirlik bir hedef değildir. Yukarıdaki genel bakışa bakın.

Her desen, başlatıcının statik genel anahtarına ve yanıtlayıcının statik genel anahtarına sağlanan gizliliği tanımlayan özellikler atanır. Temel varsayımlar, geçici özel anahtarların güvenli olduğu ve tarafların güvenmedikleri diğer taraftan statik genel anahtar aldıkları durumda el sıkışma işlemini iptal ettikleridir.

Bu bölüm yalnızca el sıkışmalardaki statik açık anahtar alanları aracılığıyla kimlik sızıntısını ele alır. Tabii ki, Noise katılımcılarının kimlikleri yük alanları, trafik analizi veya IP adresleri gibi meta veriler dahil olmak üzere başka yollarla da açığa çıkabilir.

Alice: (8) Kimliği doğrulanmış tarafa ileri gizlilik ile şifrelenmiş.

Bob: (3) İletilmez, ancak pasif bir saldırgan yanıtlayıcının özel anahtarı için adayları kontrol edebilir ve adayın doğru olup olmadığını belirleyebilir.

Bob, statik genel anahtarını netDb’de yayınlar. Alice yayınlamayabilir, ancak Bob’a gönderilen RI’da bunu dahil etmelidir.

Packet Guidelines

Kimlik Doğrulamalı Şifreleme

Handshake mesajları (Session Request/Created/Confirmed, Retry) temel adımları, sırasıyla:

• 16 veya 32 byte başlık oluştur
• Payload oluştur
• Başlığı mixHash() et (Retry hariç)
• Payload’ı Noise kullanarak şifrele (Retry hariç, başlığı AD olarak kullanarak ChaChaPoly kullan)
• Başlığı şifrele ve Session Request/Created için ephemeral anahtarı şifrele

Veri aşaması mesajlarının temel adımları, sırasıyla:

• 16-byte başlık oluştur
• Payload oluştur
• Başlığı AD olarak kullanarak ChaChaPoly ile payload’ı şifrele
• Başlığı şifrele

Inbound Packet Handling

Yük

Tüm gelen mesajların ilk işlenmesi:

• Başlığın ilk 8 baytını (Hedef Bağlantı ID’si) intro anahtarı ile şifrele
• Hedef Bağlantı ID’sine göre bağlantıyı ara
• Bağlantı bulunursa ve veri aşamasındaysa, veri aşaması bölümüne git
• Bağlantı bulunamazsa, handshake bölümüne git
• Not: Peer Test ve Hole Punch mesajları da test veya relay nonce’undan oluşturulan Hedef Bağlantı ID’si ile aranabilir.

Handshake mesajları (Session Request/Created/Confirmed, Retry, Token Request) ve diğer oturum-dışı mesajların (Peer Test, Hole Punch) işlenmesi:

• Header’ın 8-15 baytlarını (paket türü, sürüm ve ağ ID’si) intro anahtarı ile deşifre et. Eğer geçerli bir Session Request, Token Request, Peer Test veya Hole Punch ise devam et
• Geçerli bir mesaj değilse, paket kaynak IP/portuna göre bekleyen giden bağlantıyı ara, paketi Session Created veya Retry olarak ele al. Header’ın ilk 8 baytını doğru anahtarla ve header’ın 8-15 baytlarını (paket türü, sürüm ve ağ ID’si) yeniden deşifre et. Eğer geçerli bir Session Created veya Retry ise devam et
• Geçerli bir mesaj değilse, başarısız ol veya olası sıra-dışı veri fazı paketi olarak kuyruğa al
• Session Request/Created, Retry, Token Request, Peer Test ve Hole Punch için header’ın 16-31 baytlarını deşifre et
• Session Request/Created için geçici anahtarı deşifre et
• Tüm header alanlarını doğrula, geçerli değilse dur
• Header’ı mixHash() et
• Session Request/Created/Confirmed için payload’ı Noise kullanarak deşifre et
• Retry ve veri fazı için payload’ı ChaChaPoly kullanarak deşifre et
• Header ve payload’ı işle

Veri fazı mesaj işleme:

• Başlığın 8-15 baytlarını (paket türü, sürüm ve ağ kimliği) doğru anahtar ile şifrele
• Başlığı AD olarak kullanarak ChaChaPoly ile yükü şifrele
• Başlığı ve yükü işle

Details

SSU 1’de gelen paket sınıflandırması zordur, çünkü oturum numarasını belirten bir başlık yoktur. Router’lar önce kaynak IP ve portu mevcut bir eş durumu ile eşleştirmeli, bulunamazsa uygun eş durumunu bulmak veya yeni bir tane başlatmak için farklı anahtarlarla birden fazla şifre çözme denemesi yapmalıdır. Mevcut bir oturum için kaynak IP veya portun, muhtemelen NAT davranışı nedeniyle değişmesi durumunda, router paketi mevcut bir oturumla eşleştirmeye ve içeriği kurtarmaya çalışmak için pahalı sezgisel yöntemler kullanabilir.

SSU 2, DPI direncini ve yol üzerindeki diğer tehditleri korurken gelen paket sınıflandırma çabasını minimize edecek şekilde tasarlanmıştır. Connection ID numarası tüm mesaj türleri için başlıkta yer alır ve bilinen bir anahtar ve nonce kullanarak ChaCha20 ile şifrelenir (gizlenir). Ek olarak, mesaj türü de başlıkta yer alır (bilinen bir anahtara başlık koruması ile şifrelenir ve ardından ChaCha20 ile gizlenir) ve ek sınıflandırma için kullanılabilir. Hiçbir durumda bir paketi sınıflandırmak için deneme DH veya diğer asimetrik kripto işlemleri gerekli değildir.

Neredeyse tüm eşlerden gelen tüm mesajlar için, Connection ID şifrelemesi için kullanılan ChaCha20 anahtarı, netDb’de yayınlanan hedef router’ın introduction anahtarıdır.

İstisnalar sadece Bob’dan Alice’e gönderilen ilk mesajlardır (Session Created veya Retry) ki bu durumda Alice’in introduction key’i henüz Bob tarafından bilinmemektedir. Bu durumlarda, Bob’un introduction key’i anahtar olarak kullanılır.

Protokol, birden fazla geri dönüş adımında ek kripto işlemleri veya karmaşık buluşsal yöntemler gerektirebilecek paket sınıflandırma işlemlerini en aza indirmek için tasarlanmıştır. Ek olarak, alınan paketlerin büyük çoğunluğu kaynak IP/port ile (potansiyel olarak maliyetli) bir geri dönüş araması ve ikinci bir başlık şifre çözme işlemi gerektirmeyecektir. Yalnızca Session Created ve Retry (ve muhtemelen TBD olan diğerleri) geri dönüş işlemini gerektirecektir. Bir uç nokta, oturum oluşturulduktan sonra IP veya port değiştirirse, oturum aramak için hâlâ bağlantı kimliği kullanılır. Örneğin aynı IP’ye sahip ancak farklı porta sahip farklı bir oturum arayarak, oturumu bulmak için buluşsal yöntemler kullanmak asla gerekli değildir.

Bu nedenle, alıcı döngü mantığında önerilen işleme adımları şunlardır:

1. Yerel introduction key kullanarak ChaCha20 ile ilk 8 baytı çözün, Destination Connection ID’yi kurtarmak için. Connection ID mevcut veya beklemede olan bir gelen oturumla eşleşirse:

a) Uygun anahtarı kullanarak, başlık baytları 8-15’i şifrele

  to recover the version, net ID, and message type.

b) Eğer mesaj türü Session Confirmed ise, bu uzun bir başlıktır.

  Verify the net ID and protocol version are valid.
  Decrypt the bytes 15-31 of the header with ChaCha20
  using the local intro key. Then MixHash() the
  decrypted 32 byte header and decrypt the message with Noise.

c) Mesaj türü geçerliyse ancak Session Confirmed değilse,

  it is a short header.
  Verify the net ID and protocol version are valid.
  decrypt the rest of the message with ChaCha20/Poly1305
  using the session key, using the decrypted 16-byte header
  as the AD.

d) (isteğe bağlı) Bağlantı ID’si bekleyen bir gelen oturum ise

  awaiting a Session Confirmed message,
  but the net ID, protocol, or message type is not valid,
  it could be a Data message received out-of-order before the
  Session Confirmed, so the data phase header protection keys are not yet known,
  and the header bytes 8-15 were incorrectly decrypted.
  Queue the message, and attempt to decrypt it once the
  Session Confirmed message is received.

e) Eğer b) veya c) başarısız olursa, mesajı düşür.

2. Bağlantı kimliği mevcut bir oturumla eşleşmiyorsa: 8-15 baytlarındaki düz metin başlığının geçerli olduğunu kontrol edin (herhangi bir başlık koruma işlemi yapmadan). Ağ kimliği ve protokol sürümünün geçerli olduğunu doğrulayın ve mesaj türünün Session Request veya oturum dışında izin verilen diğer mesaj türü (TBD) olduğunu kontrol edin.

a) Eğer her şey geçerliyse ve mesaj türü Session Request ise,

  decrypt bytes 16-31 of the header and the 32-byte X value
  with ChaCha20 using the local intro key.

• Başlık baytları 24-31’deki token kabul edilirse, şifrelenmiş 32 baytlık başlığı MixHash() ile işle ve mesajı Noise ile şifrele. Yanıt olarak Session Created gönder.
  • Token kabul edilmezse, kaynak IP/port’a token ile birlikte Retry mesajı gönder. DDoS saldırılarından kaçınmak için mesajı Noise ile şifrelemeyi deneme.

b) Mesaj türü geçerli olan başka bir mesaj ise

  out-of-session, presumably with a short header,
  decrypt the rest of the message with ChaCha20/Poly1305
  using the intro key, and using the decrypted 16-byte header
  as the AD. Process the message.

c) Eğer a) veya b) başarısız olursa, adım 3’e geçin)

3. Paketin kaynak IP/port’una göre bekleyen bir giden oturumu arayın.

a) Bulunursa, ilk 8 baytı Bob’un tanıtım anahtarını kullanarak ChaCha20 ile yeniden şifrele

  to recover the Destination Connection ID.

b) Bağlantı kimliği bekleyen oturumla eşleşirse:

  Using the correct key, decrypt bytes 8-15 of the header
  to recover the version, net ID, and message type.
  Verify the net ID and protocol version are valid, and
  the message type is Session Created or Retry, or other message type
  allowed out-of-session (TBD).

   - Tüm veriler geçerli ve mesaj türü Session Created ise,
     başlığın sonraki 16 baytını ve 32 baytlık Y değerini
     Bob'un intro anahtarını kullanarak ChaCha20 ile şifresini çöz.
     Ardından şifresi çözülmüş 32 baytlık başlığı MixHash() yap ve
     mesajın şifresini Noise ile çöz.
     Yanıt olarak bir Session Confirmed gönder.
   - Tüm veriler geçerli ve mesaj türü Retry ise,
     başlığın 16-31 baytlarının şifresini
     Bob'un intro anahtarını kullanarak ChaCha20 ile çöz.
     TBD'yi anahtar olarak ve TBD'yi nonce olarak kullanarak ve şifresi çözülmüş 32 baytlık başlığı AD olarak kullanarak
     ChaCha20/Poly1305 ile mesajın şifresini çöz ve doğrula.
     Yanıt olarak alınan token ile bir Session Request'i yeniden gönder.
   - Mesaj türü oturum dışında geçerli olan başka bir mesaj ise,
     muhtemelen kısa başlıklı,
     intro anahtarını kullanarak mesajın geri kalanının şifresini ChaCha20/Poly1305 ile çöz
     ve şifresi çözülmüş 16 baytlık başlığı
     AD olarak kullan. Mesajı işle.

c) If a pending outbound session is not found,
   or the connection ID does not match the pending session, drop the message,
   unless the port is shared with SSU 1.

4. Aynı port üzerinde SSU 1 çalıştırıyorsa, mesajı bir SSU 1 paketi olarak işlemeye çalış.

Error Handling

Genel olarak, beklenmeyen bir mesaj türüne sahip paket alındıktan sonra bir oturum (handshake veya veri fazında) asla yok edilmemelidir. Bu, paket enjeksiyon saldırılarını önler. Bu paketler ayrıca, başlık şifre çözme anahtarlarının artık geçerli olmadığı durumlarda, bir handshake paketinin yeniden iletiminden sonra yaygın olarak alınacaktır.

Çoğu durumda, paketi basitçe düşürün. Bir uygulama, yanıt olarak önceden gönderilen paketi (handshake mesajı veya ACK 0) yeniden iletebilir, ancak bunu yapmak zorunda değildir.

Bob olarak Session Created gönderildikten sonra, beklenmeyen paketler genellikle Session Confirmed paketlerinin kaybolması veya sıra dışı gelmesi nedeniyle şifresi çözülemeyen Data paketleridir. Paketleri kuyruğa alın ve Session Confirmed paketlerini aldıktan sonra şifrelerini çözmeye çalışın.

Bob olarak Session Confirmed aldıktan sonra, beklenmeyen paketler genellikle yeniden iletilen Session Confirmed paketleridir, çünkü Session Confirmed’ın ACK 0’ı kaybolmuştur. Beklenmeyen paketler düşürülebilir. Bir uygulama yanıt olarak ACK bloğu içeren bir Data paketi gönderebilir, ancak bunu yapmak zorunda değildir.

Notes

Session Created ve Session Confirmed için, implementasyonlar header üzerinde mixHash() çağrısı yapmadan ve Noise AEAD ile payload’ı deşifre etmeye çalışmadan ÖNCE tüm deşifre edilmiş header alanlarını (Connection ID’ler, paket numarası, paket türü, sürüm, id, frag ve flag’ler) dikkatli bir şekilde doğrulamalıdır. Eğer Noise AEAD deşifreleme başarısız olursa, implementasyon hash state’ini saklayıp “geri almadıkça”, mixHash() handshake state’ini bozacağından dolayı daha fazla işlem yapılamaz.

Version Detection

Aynı gelen bağlantı noktasında gelen paketlerin sürüm 1 veya 2 olup olmadığını verimli bir şekilde tespit etmek mümkün olmayabilir. Yukarıdaki adımlar, her iki protokol sürümünü de kullanarak deneme DH işlemlerini gerçekleştirmeyi önlemek için SSU 1 işlemeden önce yapılması mantıklı olabilir.

Gerekirse belirlenecek.

Recommended Constants

• Giden el sıkışma yeniden iletim zaman aşımı: 1.25 saniye, üstel geri çekilme ile (1.25, 3.75 ve 8.75 saniyede yeniden iletimler)
• Toplam giden el sıkışma zaman aşımı: 15 saniye
• Gelen el sıkışma yeniden iletim zaman aşımı: 1 saniye, üstel geri çekilme ile (1, 3 ve 7 saniyede yeniden iletimler)
• Toplam gelen el sıkışma zaman aşımı: 12 saniye
• Yeniden deneme gönderildikten sonra zaman aşımı: 9 saniye
• ACK gecikmesi: max(10, min(rtt/6, 150)) ms
• Anında ACK gecikmesi: min(rtt/16, 5) ms
• Maksimum ACK aralıkları: 256?
• Maksimum ACK derinliği: 512?
• Dolgu dağılımı: 0-15 bayt veya daha fazla

Variants, Fallbacks, and General Issues

TBD

Packet Overhead Analysis

IPv4 varsayılmıştır, ekstra dolgu dahil değildir, IP ve UDP başlık boyutları dahil değildir. Dolgu yalnızca SSU 1 için mod-16 dolgudur.

SSU 1