SSU2

Stav

Plán zavádění:

Přehled

Tento návrh popisuje protokol pro ověřené dohodnutí klíčů za účelem zlepšení odolnosti SSU proti různým formám automatické identifikace a útoků.

Návrh je organizován následovně: nejprve jsou představeny bezpečnostní cíle, následuje diskuze základního protokolu. Dále je uvedena kompletní specifikace všech zpráv protokolu. Nakonec jsou probrány adresy routerů a identifikace verzí.

Stejně jako ostatní I2P transporty je SSU2 definován pro point-to-point (router-to-router) přenos I2NP zpráv. Není to obecný datový kanál. Podobně jako SSU také poskytuje dvě dodatečné služby: Relaying pro průchod NAT a Peer Testing pro určení dostupnosti příchozích spojení. Poskytuje také třetí službu, která není v SSU, pro migraci spojení, když peer změní IP nebo port.

Motivace

SSU je jediná zbývající protokolová vrstva, která vyžaduje ElGamal, který je velmi pomalý. Řízení toku pro SSU je složité a nefunguje dobře. Části SSU jsou zranitelné vůči útokům spoofingu adres. Handshake nepoužívá Noise.

Cíle návrhu

• Snížit využití CPU eliminací ElGamal. Použít X25519 pro DH.

• Udržovat funkce Peer Test a Relay a zvýšit jejich bezpečnost.

• Usnadnit implementaci umožněním standardních algoritmů řízení toku.

• Snížit latenci při navazování spojení. Střední doba navazování je v současnosti přibližně 135 ms pro NTCP2 a 187 ms pro SSU, i když NTCP2 má dodatečný round trip; nahrazení ElGamal v SSU2 by ji mělo snížit, ale pomoct mohou i další změny.

• Udržet nebo zvýšit maximální propustnost ve sравnání s SSU 1, jak je měřena přes rozsah simulovaných latencí a procent zahazování paketů na testovací síti.

• Zabránit útokům pomocí zesílení provozu a chybného směrování ze spoofovaných zdrojových adres prostřednictvím “ověřování adres”.

• Usnadnit identifikaci paketů, aby se snížila závislost na záložních řešeních a heuristikách, které činí kód příliš složitým.

• Formalizovat a vylepšit migraci spojení, když se změní IP adresa nebo port protějšku. Nemigrovat spojení, dokud není dokončena validace adresy, aby se předešlo útokům. Některé implementace SSU 1 používají nákladné heuristiky pro zpracování změn portů kvůli NAT rebindingu. Žádné známé implementace SSU 1 nedokážou vůbec zpracovat změny IP adres.

• Podporuje SSU 1 i 2 na jednom portu, automatická detekce a publikováno jako jeden “transport” (tj. RouterAddress) v NetDB.

• Publikovat podporu pouze pro verzi 1, pouze pro verzi 2, nebo 1+2 v NetDB v samostatném poli a výchozí nastavení na pouze verzi 1 (nevázat podporu verzí na konkrétní verzi routeru)

• Zajistit, že všechny implementace (Java/i2pd/Go) mohou přidat podporu verze 2 (nebo ne) podle svých vlastních harmonogramů

• Přidat náhodné výplně do všech zpráv včetně handshake a datových zpráv. Veškeré výplně musí být kryty MAC, na rozdíl od výplní na konci paketu v SSU 1. Poskytnout mechanismus možností pro obě strany k vyžádání minimálních a maximálních výplní a/nebo distribuce výplní. Podrobnosti distribuce výplní jsou závislé na implementaci a mohou nebo nemusí být specifikovány v samotném protokolu.

• Zamaskovat hlavičky a obsah zpráv, které nejsou plně šifrované, dostatečně tak, aby je DPI zařízení a AV signatury nemohly snadno klasifikovat. Také zajistit, aby zprávy směřující k jednomu peer nebo sadě peer neměly podobný vzor bitů.

• Oprava ztráty bitů v DH kvůli formátu Java Ticket1112 a zrychlení DH přechodem na X25519.

• Přepnout na skutečnou funkci pro odvození klíčů (KDF) namísto přímého použití výsledku DH

• Přidat “odolnost proti sondování” (jak to nazývá Tor); zahrnuje to odolnost proti replay útokům.

• Udržovat obousměrnou autentizovanou výměnu klíčů (2W-AKE). 1W-AKE není pro naši aplikaci dostatečná.

• Spoléhat se na statický veřejný klíč publikovaný v RouterInfo jako další část autentifikace.

• Přidat options/version do handshake pro budoucí rozšiřitelnost.

• Neznamená výrazné navýšení výpočetního výkonu procesoru potřebného pro navázání spojení; pokud možno jej dokonce výrazně sníží.

• Odstranit požadavek na doplnění na násobek 16 bajtů vyžadovaný AES šifrováním v SSU 1.

• Použít standardní ChaCha/Poly1305 pro šifrování a MAC, nahrazující AES šifrování a nestandardní HMAC-MD5-128 MAC používané v SSU 1.

• Použijte oddělené šifrovací klíče pro odesílání a přijímání, namísto společných klíčů pro oba směry používaných v SSU 1.

• Použijte 3-zprávu, jednokolový handshake, jako v NTCP2. Odstraňte zpoždění čekání na datové zprávy, které dělá z SSU efektivně dvoukolový handshake.

• Dramaticky zlepšit efektivitu ACK a NACK, která je v SSU 1 hrozná. Snížit šířku pásma potřebnou pro ACK a NACK a zvětšit velikost paketu dostupnou pro data. Efektivně zakódovat NACK pro shluk chybějících zpráv, což je běžné přes WiFi.

• Snížit složitost potřebnou pro implementaci fragmentace I2NP zpráv. Obejít mechanismy fragmentace a kódování pro kompletní I2NP zprávy.

• Minimalizujte protokolovou režii před paddingem, zejména u ACK. Ačkoli bude přidán padding, režie před paddingem je stále režie. Uzly s nízkou šířkou pásma musí být schopny používat SSU2.

• Udržovat časové značky pro detekci opakování a časového posunu.

• Vyhnout se jakýmkoliv problémům roku 2038 v časových razítkách, musí fungovat minimálně do roku 2106.

• Zvýšit minimální MTU z 620 na 1280 pro efektivitu, snadnější implementaci a zvětšení maximální velikosti I2NP zpráv. Fragmentace a opětovné sestavení je poměrně nákladné. Poskytnutím prostoru pro 1028bajtové tunnel zprávy nebude většina I2NP zpráv vyžadovat fragmentaci.

• Zvýšit maximální MTU z 1488 (1484 pro IPv6) na 1500 pro efektivitu. Odstranit požadavek, aby MTU bylo násobkem 16.

• Zvýšit maximální velikost I2NP zprávy z přibližně 32K v SSU 1 na přibližně 64 KB jako v NTCP2.

• Odebrat podpis polí IP a portu z handshaku, aby se routery, které neznají svou externí IP a port, mohly připojit.

• Zachovat mechanismus zjišťování IP/portu z SSU 1 v handshaku, aby si routery mohly zjistit svoji externí IP a port.

• Zahrnout zástupce vývojářů routerů v jazycích Java, C++ a Go do návrhu.

Non-Goals

• Neprůstřelná odolnost vůči DPI… to by byly pluggable transports, Návrh 109.

• TLS-založený (nebo HTTPS-podobný) transport… to by byl Proposal 104.

• Odolnost proti DPI založené na časování (časování/zpoždění mezi zprávami může být závislé na implementaci; zpoždění uvnitř zpráv lze zavést v jakémkoli bodě, včetně před odesláním náhodného paddingu, například). Umělá zpoždění (co obfs4 nazývá IAT nebo inter-arrival time) jsou nezávislá na samotném protokolu.

• Popiratelnost účasti v relaci (jsou tam podpisy).

Necíle, které mohou být částečně přehodnoceny nebo projednány:

• Míra ochrany proti Deep Packet Inspection (DPI)

• Post-Quantum (PQ) zabezpečení

• Popíratelnost

Security Goals

Uvažujeme tři strany:

• Alice, která si přeje navázat novou relaci.
• Bob, se kterým si Alice přeje navázat relaci.
• Mallory, “útočník uprostřed” mezi Alice a Bobem.

Nejvýše dva účastníci mohou provádět aktivní útoky.

Alice a Bob oba vlastní statický pár klíčů, který je obsažen v jejich RouterIdentity.

Navrhovaný protokol se pokouší umožnit Alici a Bobovi dohodnout se na sdíleném tajném klíči (K) za následujících požadavků:

1. Bezpečnost privátního klíče: ani Bob ani Mallory se nedozví nic o Alicině statickém privátním klíči. Symetricky, Alice se nedozví nic o Bobově statickém privátním klíči.

2. Klíč relace K zná pouze Alice a Bob.

3. Dokonalá dopředná bezpečnost: dohodnutý klíč relace zůstává tajný i v budoucnu, i když jsou statické privátní klíče Alice a/nebo Boba odhaleny po tom, co byl klíč dohodnut.

4. Obousměrné ověřování: Alice si je jistá, že navázala relaci s Bobem, a naopak.

5. Ochrana proti online DPI: Zajistit, že není triviální detekovat, že Alice a Bob jsou zapojeni do protokolu pouze pomocí jednoduchých technik hlubokého průzkumu paketů (DPI). Viz níže.

6. Omezená popíratelnost: ani Alice ani Bob nemohou popřít účast v protokolu, ale pokud kterákoli strana prozradí sdílený klíč, může druhá strana popřít autenticitu obsahu přenášených dat.

Současný návrh se pokouší poskytnout všech pět požadavků založených na protokolu Station-To-Station (STS). Upozorňujeme, že tento protokol je také základem pro protokol SSU.

Additional DPI Discussion

Předpokládáme dvě DPI komponenty:

Online DPI

Online DPI kontrolující všechny toky v reálném čase. Připojení mohou být blokována nebo jinak narušována. Data připojení nebo metadata mohou být identifikována a uložena pro offline analýzu. Online DPI nemá přístup k databázi I2P sítě. Online DPI má pouze omezenou výpočetní schopnost v reálném čase, včetně výpočtu délky, kontroly polí a jednoduchých výpočtů jako je XOR. Online DPI má schopnost rychlých kryptografických funkcí v reálném čase jako jsou ChaCha20, AEAD a hashování, ale tyto by byly příliš nákladné pro aplikaci na většinu nebo všechny toky. Jakákoliv aplikace těchto kryptografických operací by se vztahovala pouze na toky v kombinacích IP/Port předem identifikovaných offline analýzou. Online DPI nemá schopnost kryptografických funkcí s vysokou zátěží jako jsou DH nebo elligator2. Online DPI není navrženo speciálně k detekci I2P, i když může mít omezená klasifikační pravidla pro tento účel.

Cílem je zabránit identifikaci protokolu pomocí online DPI.

Pojem online nebo “přímočaré” DPI zde zahrnuje následující schopnosti protivníka:

1. Schopnost kontrolovat veškerá data odeslaná nebo přijatá cílem.

2. Schopnost provádět operace s pozorovanými daty, jako je aplikace blokových šifer nebo hash funkcí.

3. Schopnost ukládat a porovnávat s dříve odeslanými zprávami.

4. Schopnost upravovat, zpožďovat nebo fragmentovat pakety.

Nicméně se předpokládá, že online DPI má následující omezení:

5. Nemožnost mapovat IP adresy na hashe routerů. Zatímco toto je triviální při přístupu k síťové databázi v reálném čase, vyžadovalo by to DPI systém specificky navržený pro cílení na I2P.

6. Nemožnost použít informace o časování k detekci protokolu.

7. Obecně řečeno, online DPI toolbox neobsahuje žádné vestavěné nástroje, které jsou specificky navržené pro detekci I2P. To zahrnuje vytváření “honeypotů”, které by například obsahovaly nenáhodné vyplnění ve svých zprávách. Všimněte si, že to nevylučuje systémy strojového učení nebo vysoce konfigurovatelné DPI nástroje, pokud splňují ostatní požadavky.

Pro boj proti analýze datové části se zajišťuje, že všechny zprávy jsou nerozeznatelné od náhodných dat. To také vyžaduje, aby jejich délka byla náhodná, což je složitější než pouhé přidání náhodného vyplnění. Ve skutečnosti v Dodatku A autoři argumentují, že naivní (tj. uniformní) schéma vyplnění problém neřeší. Dodatek A proto navrhuje zahrnout buď náhodná zpoždění, nebo vyvinout alternativní schéma vyplnění, které může poskytnout rozumnou ochranu proti navrženému útoku.

Pro ochranu proti šestému bodu výše by implementace měly zahrnovat náhodná zpoždění v protokolu. Takové techniky nejsou pokryty tímto návrhem, ale mohly by také vyřešit problémy s délkou paddingu. Shrnutí: návrh poskytuje dobrou ochranu proti analýze payload (když se vezmou v úvahu úvahy v Příloze A), ale pouze omezenou ochranu proti flow analýze.

Offline DPI

Offline DPI kontrolující data uložená online DPI pro pozdější analýzu. Offline DPI může být navržena specificky pro detekci I2P. Offline DPI nemá přístup k síťové databázi I2P v reálném čase. Offline DPI má přístup k této a dalším I2P specifikacím. Offline DPI má neomezené výpočetní možnosti, včetně všech kryptografických funkcí definovaných v této specifikaci.

Offline DPI nemá schopnost blokovat existující spojení. Offline DPI má schopnost provádět téměř v reálném čase (do několika minut od nastavení) odesílání na host/port stran pomocí injektáže paketů. Offline DPI má schopnost provádět téměř v reálném čase (do několika minut od nastavení) opakované přehrávání předchozích zpráv (upravených či nikoliv) za účelem “sondování” nebo z jiných důvodů.

Není cílem zabránit identifikaci protokolu pomocí offline DPI. Veškeré dekódování zamlžených dat v prvních dvou zprávách, které implementují I2P routery, může být také implementováno offline DPI.

Cílem je odmítnout pokusy o spojení využívající opakování předchozích zpráv.

Address Validation

Následující je zkopírováno z QUIC RFC 9000. Pro každou sekci proveďte kontrolu a úpravy.

Validace adres zajišťuje, že endpoint nemůže být použit pro útok amplifikace provozu. Při takovém útoku je packet odeslán na server s falešnými informacemi o zdrojové adrese, které identifikují oběť. Pokud server vygeneruje více nebo větší packety v odpovědi na tento packet, útočník může použít server k odeslání více dat směrem k oběti, než by byl schopen odeslat sám.

Primární obranou proti amplifikačním útokům je ověření, že peer je schopen přijímat pakety na transportní adrese, kterou uvádí. Proto po přijetí paketů z adresy, která ještě nebyla validována, MUSÍ koncový bod omezit množství dat, které posílá na nevalidovanou adresu, na trojnásobek množství dat přijatých z této adresy. Toto omezení velikosti odpovědí je známé jako anti-amplifikační limit.

Validace adres se provádí jak během navazování spojení (viz sekce 8.1), tak během migrace spojení (viz sekce 8.2).

Address Validation during Connection Establishment

Navázání spojení implicitně poskytuje validaci adresy pro oba koncové body. Konkrétně příjem paketu chráněného Handshake klíči potvrzuje, že partner úspěšně zpracoval Initial paket. Jakmile koncový bod úspěšně zpracuje Handshake paket od partnera, může považovat adresu partnera za validovanou.

Kromě toho MŮŽE endpoint považovat adresu protějšku za ověřenou, pokud protějšek používá connection ID zvolené endpointem a connection ID obsahuje alespoň 64 bitů entropie.

Pro klienta umožňuje hodnota pole Destination Connection ID v jeho prvním Initial paketu validovat adresu serveru jako součást úspěšného zpracování jakéhokoliv paketu. Initial pakety od serveru jsou chráněny klíči, které jsou odvozeny z této hodnoty (viz Sekce 5.2 QUIC-TLS). Alternativně je hodnota echována serverem v Version Negotiation paketech (Sekce 6) nebo zahrnuta v Integrity Tag v Retry paketech (Sekce 5.8 QUIC-TLS).

Před validací klientské adresy NESMÍ servery odeslat více než třikrát tolik bajtů, kolik bajtů obdržely. To omezuje rozsah jakéhokoli amplifikačního útoku, který lze provést pomocí falešných zdrojových adres. Pro účely zabránění amplifikaci před validací adresy MUSÍ servery počítat všechny bajty užitečného obsahu přijaté v datagramech, které jsou jednoznačně přiřazeny k jednomu spojení. To zahrnuje datagramy obsahující pakety, které jsou úspěšně zpracovány, i datagramy obsahující pakety, které jsou všechny zahozeny.

Klienti MUSÍ zajistit, že UDP datagramy obsahující Initial pakety mají UDP payloady o délce alespoň 1200 bajtů, v případě potřeby přidávají PADDING rámce. Klient, který odesílá vyplněné datagramy, umožňuje serveru odeslat více dat před dokončením validace adresy.

Ztráta Initial nebo Handshake paketu ze serveru může způsobit deadlock, pokud klient neodešle další Initial nebo Handshake pakety. Deadlock by mohl nastat, když server dosáhne svého anti-amplification limitu a klient obdržel potvrzení pro veškerá data, která odeslal. V tomto případě, když klient nemá důvod odeslat další pakety, server nebude moci odeslat více dat, protože nevalidoval adresu klienta. Pro předejití tomuto deadlocku MUSÍ klienti odeslat paket při Probe Timeout (PTO); viz sekce 6.2 QUIC-RECOVERY. Konkrétně, klient MUSÍ odeslat Initial paket v UDP datagramu, který obsahuje alespoň 1200 bajtů, pokud nemá Handshake klíče, a jinak odeslat Handshake paket.

Server může chtít ověřit adresu klienta před zahájením kryptografického handshake. QUIC používá token v Initial paketu k poskytnutí ověření adresy před dokončením handshake. Tento token je doručen klientovi během ustanovení spojení pomocí Retry paketu (viz sekce 8.1.2) nebo v předchozím spojení pomocí NEW_TOKEN frame (viz sekce 8.1.3).

Kromě omezení odesílání uložených před validací adresy jsou servery také omezeny v tom, co mohou odesílat, limity stanovenými řadičem zahlcení. Klienti jsou omezeni pouze řadičem zahlcení.

Token Construction

Token odeslaný v NEW_TOKEN rámci nebo v Retry paketu MUSÍ být zkonstruován způsobem, který umožňuje serveru identifikovat, jak byl poskytnut klientovi. Tyto tokeny jsou přenášeny ve stejném poli, ale vyžadují od serverů odlišné zacházení.

Address Validation Using Retry Packets

Po obdržení počátečního paketu klienta může server požádat o ověření adresy odesláním paketu Retry (Sekce 17.2.5) obsahujícího token. Tento token MUSÍ být opakován klientem ve všech počátečních paketech, které odešle pro toto spojení poté, co obdrží paket Retry.

V reakci na zpracování Initial paketu obsahujícího token, který byl poskytnut v Retry paketu, nemůže server odeslat další Retry paket; může pouze spojení odmítnout nebo mu povolit pokračování.

Dokud není možné, aby útočník vygeneroval platný token pro svou vlastní adresu (viz sekce 8.1.4) a klient je schopen tento token vrátit, dokazuje to serveru, že token obdržel.

Server může také použít Retry paket k odložení stavu a nákladů na zpracování při navazování spojení. Vyžadování od serveru poskytnutí jiného connection ID, spolu s transportním parametrem original_destination_connection_id definovaným v sekci 18.2, nutí server prokázat, že on nebo entita, se kterou spolupracuje, obdržel původní Initial paket od klienta. Poskytnutí jiného connection ID také dává serveru určitou kontrolu nad tím, jak jsou následující pakety směrovány. To lze použít k přesměrování spojení na jinou instanci serveru.

Pokud server obdrží klientský Initial, který obsahuje neplatný Retry token, ale je jinak platný, ví, že klient nepřijme další Retry token. Server může takový paket zahodit a nechat klienta, aby vypršel časový limit pro detekci selhání handshaku, ale to by mohlo způsobit značné zpoždění pro klienta. Místo toho by server MĚLA okamžitě uzavřít (Sekce 10.2) spojení s chybou INVALID_TOKEN. Všimněte si, že server v tomto bodě nevytvořil žádný stav pro spojení, a proto nevstupuje do uzavírací periody.

Průběh ukazující použití paketu Retry je znázorněn na obrázku 9.

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

Server MŮŽE poskytnout klientům token pro validaci adresy během jednoho spojení, který lze použít při následujícím spojení. Validace adresy je obzvláště důležitá u 0-RTT, protože server potenciálně posílá významné množství dat klientovi v odpovědi na 0-RTT data.

Server používá rámec NEW_TOKEN (Sekce 19.7) k poskytnutí klientovi tokenu pro validaci adresy, který lze použít k validaci budoucích připojení. V budoucím připojení klient zahrne tento token do Initial paketů pro poskytnutí validace adresy. Klient MUSÍ zahrnout token do všech Initial paketů, které odesílá, pokud Retry nenahradí token novějším. Klient NESMÍ použít token poskytnutý v Retry pro budoucí připojení. Servery MOHOU zahodit jakýkoli Initial paket, který nenese očekávaný token.

Na rozdíl od tokenu, který je vytvořen pro Retry paket a používá se okamžitě, token odeslaný v NEW_TOKEN rámci lze použít až po uplynutí určité doby. Proto by token MĚL mít dobu vypršení, která může být buď explicitní doba vypršení, nebo časové razítko vydání, které lze použít k dynamickému výpočtu doby vypršení. Server může uložit dobu vypršení nebo ji zahrnout v zašifrované podobě do tokenu.

Token vydaný s NEW_TOKEN NESMÍ obsahovat informace, které by umožnily pozorovateli propojit hodnoty se spojením, na kterém byl vydán. Například nemůže obsahovat předchozí ID spojení nebo adresní informace, pokud nejsou tyto hodnoty šifrované. Server MUSÍ zajistit, že každý NEW_TOKEN frame, který odešle, je jedinečný napříč všemi klienty, s výjimkou těch odeslaných k opravě ztrát dříve odeslaných NEW_TOKEN framů. Informace, které umožňují serveru rozlišovat mezi tokeny z Retry a NEW_TOKEN, MOHOU být přístupné jiným entitám než serveru.

Je nepravděpodobné, že by číslo portu klienta bylo stejné u dvou různých připojení; validace portu proto pravděpodobně nebude úspěšná.

Token obdržený v rámci NEW_TOKEN je použitelný pro jakýkoli server, pro který je spojení považováno za autoritativní (např. názvy serverů uvedené v certifikátu). Při připojování k serveru, pro který si klient ponechává použitelný a nepoužitý token, MĚL BY tento token zahrnout do pole Token svého počátečního paketu. Zahrnutí tokenu může umožnit serveru validovat adresu klienta bez dodatečné zpáteční cesty. Klient NESMÍ zahrnout token, který není použitelný pro server, ke kterému se připojuje, pokud klient nemá vědomost, že server, který token vydal, a server, ke kterému se klient připojuje, společně spravují tokeny. Klient MŮŽE použít token z jakéhokoli předchozího spojení k danému serveru.

Token umožňuje serveru korelovat aktivitu mezi připojením, kde byl token vydán, a jakýmkoli připojením, kde je použit. Klienti, kteří chtějí přerušit kontinuitu identity se serverem, mohou zahodit tokeny poskytnuté pomocí rámce NEW_TOKEN. Ve srovnání s tím musí být token získaný v paketu Retry použit okamžitě během pokusu o připojení a nelze jej použít v následných pokusech o připojení.

Klient by NEMĚL znovu používat token z rámce NEW_TOKEN pro různé pokusy o připojení. Opětovné použití tokenu umožňuje propojení připojení entitami na síťové cestě; viz sekce 9.5.

Klienti mohou obdržet více tokenů na jediném připojení. Kromě zamezení možnosti propojování lze jakýkoliv token použít při jakémkoliv pokusu o připojení. Servery mohou poslat další tokeny buď pro umožnění validace adresy pro více pokusů o připojení, nebo pro nahrazení starších tokenů, které by mohly přestat být platné. Pro klienta tato nejednoznačnost znamená, že odeslání nejnovějšího nepoužitého tokenu má pravděpodobně největší šanci na úspěch. Ačkoliv uložení a použití starších tokenů nemá žádné negativní důsledky, klienti mohou považovat starší tokeny za méně pravděpodobně užitečné pro server při validaci adresy.

Když server obdrží Initial paket s adresním validačním tokenem, MUSÍ se pokusit token validovat, pokud již nedokončil adresní validaci. Pokud je token neplatný, server BY MĚL pokračovat, jako by klient neměl validovanou adresu, včetně případného odeslání Retry paketu. Tokeny poskytnuté s NEW_TOKEN rámci a Retry pakety mohou být servery rozlišeny (viz sekce 8.1.1) a ty druhé mohou být validovány přísněji. Pokud validace uspěje, server BY MĚEL následně umožnit pokračování handshaku.

Poznámka: Důvodem pro zacházení s klientem jako s nevalidovaným místo zahození paketu je, že klient mohl obdržet token v předchozím připojení pomocí rámce NEW_TOKEN, a pokud server ztratil stav, nemusí být schopen token vůbec validovat, což by vedlo k selhání připojení, pokud by byl paket zahozen.

Ve stavovém návrhu může server použít šifrované a autentizované tokeny k předání informací klientům, které může server později obnovit a použít k ověření adresy klienta. Tokeny nejsou integrovány do kryptografického handshaku, a proto nejsou autentizované. Například klient může být schopen znovu použít token. Aby se zabránilo útokům, které využívají této vlastnosti, může server omezit své použití tokenů pouze na informace potřebné k ověření adres klientů.

Klienti MOHOU použít tokeny získané na jednom připojení pro jakýkoliv pokus o připojení používající stejnou verzi. Při výběru tokenu, který se má použít, klienti nemusí zvažovat jiné vlastnosti připojení, které je pokusem navázáno, včetně volby možných aplikačních protokolů, session tickets nebo jiných vlastností připojení.

Address Validation Token Integrity

Token pro validaci adresy MUSÍ být obtížně uhádnutelný. Zahrnutí náhodné hodnoty s alespoň 128 bity entropie do tokenu by bylo dostatečné, ale to závisí na tom, že si server pamatuje hodnotu, kterou poslal klientům.

Schéma založené na tokenech umožňuje serveru přesunout jakýkoliv stav spojený s validací na klienta. Aby tento návrh fungoval, token MUSÍ být chráněn integritou proti modifikaci nebo falšování ze strany klientů. Bez ochrany integrity by škodlivý klienti mohli generovat nebo uhodnout hodnoty pro tokeny, které by server přijal. Pouze server vyžaduje přístup ke klíči pro ochranu integrity tokenů.

Není potřeba jediného dobře definovaného formátu pro token, protože server, který token generuje, ho také zpracovává. Tokeny odeslané v Retry paketech BY MĚLY obsahovat informace, které umožní serveru ověřit, že zdrojová IP adresa a port v klientských paketech zůstávají konstantní.

Tokeny odeslané v rámcích NEW_TOKEN MUSÍ obsahovat informace, které umožní serveru ověřit, že IP adresa klienta se nezměnila od okamžiku vydání tokenu. Servery mohou použít tokeny z rámců NEW_TOKEN při rozhodování neodeslat paket Retry, i když se adresa klienta změnila. Pokud se IP adresa klienta změnila, server MUSÍ dodržet limit proti amplifikaci; viz Sekce 8. Všimněte si, že při přítomnosti NAT nemusí tento požadavek být dostatečný k ochraně ostatních hostitelů, kteří sdílejí NAT, před amplifikačními útoky.

Útočníci by mohli opakovat tokeny, aby použili servery jako zesilovače v DDoS útocích. Pro ochranu proti takovým útokům MUSÍ servery zajistit, že opakování tokenů je zabráněno nebo omezeno. Servery BY MĚLY zajistit, že tokeny odeslané v Retry paketech jsou přijímány pouze po krátkou dobu, protože jsou klienty vráceny okamžitě. Tokeny, které jsou poskytovány v NEW_TOKEN rámcích (Sekce 19.7), musí být platné déle, ale NEMĚLY BY být přijímány vícekrát. Servery jsou povzbuzovány, aby umožnily použití tokenů pouze jednou, pokud je to možné; tokeny MOHOU obsahovat dodatečné informace o klientech pro další zúžení použitelnosti nebo opětovného použití.

Online DPI

Validace cesty je používána oběma partnery během migrace připojení (viz Sekce 9) k ověření dosažitelnosti po změně adresy. Při validaci cesty koncové body testují dosažitelnost mezi specifickou lokální adresou a specifickou adresou partnera, kde adresa je 2-tuple IP adresy a portu.

Validace cesty testuje, že pakety odeslané po cestě k protějšku jsou tímto protějškem přijaty. Validace cesty se používá k zajištění toho, že pakety přijaté od migrujícího protějšku nenesou falešnou zdrojovou adresu.

Validace cesty neověřuje, že peer může odesílat ve zpětném směru. Potvrzení nelze použít pro validaci zpětné cesty, protože obsahují nedostatečnou entropii a mohou být falšována. Koncové body nezávisle určují dostupnost v každém směru cesty, a proto zpětná dostupnost může být ustanovena pouze daným peerem.

Validace cesty může být použita kdykoli kterýmkoli koncovým bodem. Například koncový bod může zkontrolovat, že peer stále vlastní svou adresu po období nečinnosti.

Validace cesty není navržena jako mechanismus pro překonání NAT. Ačkoli mechanismus zde popsaný může být efektivní pro vytváření NAT vazeb, které podporují překonání NAT, očekává se, že jeden koncový bod je schopen přijímat pakety, aniž by nejprve musel odeslat paket po této cestě. Efektivní překonání NAT potřebuje dodatečné synchronizační mechanismy, které zde nejsou poskytovány.

Endpoint MŮŽE zahrnout další rámce s rámci PATH_CHALLENGE a PATH_RESPONSE používanými pro validaci cesty. Konkrétně může endpoint zahrnout rámce PADDING s rámcem PATH_CHALLENGE pro Path Maximum Transmission Unit Discovery (PMTUD); viz sekce 14.2.1. Endpoint může také zahrnout svůj vlastní rámec PATH_CHALLENGE při odesílání rámce PATH_RESPONSE.

Koncový bod používá nové connection ID pro sondy odeslané z nové lokální adresy; viz sekce 9.5. Při testování nové cesty může koncový bod zajistit, že jeho protějšek má k dispozici nepoužité connection ID pro odpovědi. Odeslání NEW_CONNECTION_ID a PATH_CHALLENGE rámců ve stejném paketu, pokud to active_connection_id_limit protějška umožňuje, zajistí, že nepoužité connection ID bude pro protějšek k dispozici při odesílání odpovědi.

Koncový bod si může zvolit současné sondování více cest. Počet současných cest používaných pro sondy je omezen počtem dodatečných connection ID, které jeho protějšek dříve poskytl, protože každá nová místní adresa používaná pro sondu vyžaduje dříve nepoužité connection ID.

Offline DPI

Pro zahájení validace cesty endpoint odešle rámec PATH_CHALLENGE obsahující nepředvídatelný payload po cestě, která má být validována.

Koncový bod MŮŽE poslat více rámců PATH_CHALLENGE jako ochranu proti ztrátě paketů. Koncový bod však NEMĚL poslat více rámců PATH_CHALLENGE v jediném paketu.

Koncový bod by NEMĚL testovat novou cestu pomocí paketů obsahujících rámec PATH_CHALLENGE častěji, než by odesílal počáteční paket. Tím se zajistí, že migrace připojení nevytváří na nové cestě větší zátěž než vytvoření nového připojení.

Koncový bod MUSÍ použít nepředvídatelná data v každém PATH_CHALLENGE rámci tak, aby mohl přiřadit odpověď protějšku k odpovídajícímu PATH_CHALLENGE.

Endpoint MUSÍ rozšířit datagramy, které obsahují rámec PATH_CHALLENGE, na nejméně nejmenší povolenou maximální velikost datagramu 1200 bajtů, pokud limit proti amplifikaci pro danou cestu nebrání odeslání datagramu této velikosti. Odesílání UDP datagramů této velikosti zajišťuje, že síťová cesta z endpointu k protějšku může být použita pro QUIC; viz Sekce 14.

Když koncový bod není schopen rozšířit velikost datagramu na 1200 bajtů kvůli limitu proti zesílení, MTU cesty nebude validováno. Aby se zajistilo, že MTU cesty je dostatečně velké, koncový bod MUSÍ provést druhou validaci cesty odesláním PATH_CHALLENGE rámce v datagramu o velikosti nejméně 1200 bajtů. Tato dodatečná validace může být provedena po úspěšném přijetí PATH_RESPONSE nebo když bylo na cestě přijato dostatek bajtů tak, že odeslání většího datagramu nebude mít za následek překročení limitu proti zesílení.

Na rozdíl od jiných případů, kdy jsou datagramy rozšiřovány, koncové body NESMÍ zahazovat datagramy, které se zdají být příliš malé, pokud obsahují PATH_CHALLENGE nebo PATH_RESPONSE.

Path Validation Responses

Při přijetí rámce PATH_CHALLENGE musí koncový bod odpovědět opakováním dat obsažených v rámci PATH_CHALLENGE v rámci PATH_RESPONSE. Koncový bod NESMÍ zpozdit přenos paketu obsahujícího rámec PATH_RESPONSE, pokud není omezen řízením zahlcení.

Rámec PATH_RESPONSE MUSÍ být odeslán po síťové cestě, kde byl přijat rámec PATH_CHALLENGE. To zajišťuje, že validace cesty protějškem uspěje pouze tehdy, když je cesta funkční v obou směrech. Tento požadavek NESMÍ být vynucován koncovým bodem, který iniciuje validaci cesty, protože by to umožnilo útok na migraci; viz sekce 9.3.3.

Koncový bod MUSÍ rozšířit datagramy, které obsahují rámec PATH_RESPONSE, na nejméně nejmenší povolenou maximální velikost datagramu 1200 bajtů. Tím se ověří, že cesta je schopna přenášet datagramy této velikosti v obou směrech. Koncový bod však NESMÍ rozšířit datagram obsahující PATH_RESPONSE, pokud by výsledná data překročila limit proti zesílení. Očekává se, že k tomu dojde pouze v případě, že přijatý PATH_CHALLENGE nebyl odeslán v rozšířeném datagramu.

Koncový bod NESMÍ odeslat více než jeden PATH_RESPONSE rámec v odpovědi na jeden PATH_CHALLENGE rámec; viz sekce 13.3. Očekává se, že protistrana odešle další PATH_CHALLENGE rámce podle potřeby k vyvolání dalších PATH_RESPONSE rámců.

Validace adres během navazování spojení

Validace cesty je úspěšná, když je přijat rámec PATH_RESPONSE, který obsahuje data odeslaná v předchozím rámci PATH_CHALLENGE. Rámec PATH_RESPONSE přijatý na jakékoli síťové cestě validuje cestu, na které byl odeslán PATH_CHALLENGE.

Pokud endpoint odešle PATH_CHALLENGE frame v datagramu, který není rozšířen na alespoň 1200 bytů, a pokud odpověď na něj validuje adresu protějšku, cesta je validována, ale ne path MTU. V důsledku toho může endpoint nyní odeslat více než trojnásobek množství dat, která obdržel. Endpoint však MUSÍ zahájit další path validation s rozšířeným datagramem, aby ověřil, že cesta podporuje požadované MTU.

Přijetí potvrzení pro paket obsahující frame PATH_CHALLENGE není dostatečnou validací, protože potvrzení může být falšováno škodlivým peerem.

Konstrukce tokenu

Validace cesty selže pouze tehdy, když koncový bod pokoušející se o validaci cesty opustí svůj pokus o validaci cesty.

Endpoints by měly ukončit validaci cesty na základě časovače. Při nastavování tohoto časovače jsou implementace upozorněny, že nová cesta může mít delší dobu odezvy než původní. Doporučuje se hodnota trojnásobku většího z aktuálního PTO nebo PTO pro novou cestu (za použití kInitialRtt, jak je definováno v QUIC-RECOVERY).

Tento timeout umožňuje vypršení více PTO před selháním validace cesty, takže ztráta jediného PATH_CHALLENGE nebo PATH_RESPONSE rámce nezpůsobí selhání validace cesty.

Vezměte na vědomí, že endpoint může přijímat pakety obsahující další rámce na nové cestě, ale pro úspěšné ověření cesty je vyžadován rámec PATH_RESPONSE s odpovídajícími daty.

Když koncový bod opustí validaci cesty, určí, že cesta je nepoužitelná. To nemusí nutně znamenat selhání spojení – koncové body mohou pokračovat v odesílání paketů po jiných cestách podle potřeby. Pokud nejsou k dispozici žádné cesty, koncový bod může čekat na dostupnost nové cesty nebo ukončit spojení. Koncový bod, který nemá platnou síťovou cestu ke svému protějšku, MŮŽE toto signalizovat pomocí chyby spojení NO_VIABLE_PATH, přičemž je třeba poznamenat, že to je možné pouze v případě, že síťová cesta existuje, ale nepodporuje požadované MTU (sekce 14).

Validace cesty může být opuštěna z jiných důvodů než selhání. Především k tomu dochází, pokud je zahájena migrace spojení na novou cestu, zatímco probíhá validace cesty na staré cestě.

Connection Migration

Následující je zkopírováno z QUIC RFC 9000. Pro každou sekci proveďte revizi a úpravu.

Použití ID připojení umožňuje připojením přežít změny adres koncových bodů (IP adresa a port), jako jsou ty způsobené migrací koncového bodu do nové sítě. Tato sekce popisuje proces, kterým koncový bod migruje na novou adresu.

Návrh QUIC spoléhá na to, že endpointy si zachovají stabilní adresu po celou dobu handshaku. Endpoint NESMÍ iniciovat migraci připojení před potvrzením handshaku, jak je definováno v sekci 4.1.2 QUIC-TLS.

Pokud peer odeslal transportní parametr disable_active_migration, endpoint také NESMÍ odesílat pakety (včetně sondážních paketů; viz sekce 9.1) z jiné místní adresy na adresu, kterou peer použil během handshake, pokud endpoint nepřijal opatření na základě transportního parametru preferred_address od peera. Pokud peer poruší tento požadavek, endpoint MUSÍ buď zahodit příchozí pakety na této cestě bez generování Stateless Reset, nebo pokračovat s validací cesty a umožnit peerovi migraci. Generování Stateless Reset nebo uzavření spojení by umožnilo třetím stranám v síti způsobit uzavření spojení pomocí spoofingu nebo jiné manipulace pozorovaného provozu.

Ne všechny změny adresy protějšku jsou úmyslné nebo aktivní migrace. Protějšek může zažít NAT rebinding: změnu adresy způsobenou middleboxem, obvykle NAT, který alokuje nový odchozí port nebo dokonce novou odchozí IP adresu pro tok. Koncový bod MUSÍ provést path validation (Sekce 8.2), pokud detekuje jakoukoliv změnu adresy protějšku, pokud tuto adresu dříve nevalidoval.

Když koncový bod nemá validovanou cestu pro odesílání paketů, MŮŽE zahodit stav spojení. Koncový bod schopný migrace spojení MŮŽE čekat na dostupnost nové cesty před zahozením stavu spojení.

Tento dokument omezuje migraci spojení na nové klientské adresy, s výjimkou případů popsaných v sekci 9.6. Klienti jsou odpovědní za zahájení všech migrací. Servery neposílají neprobíhající pakety (viz sekce 9.1) směrem ke klientské adrese, dokud neuvidí neprobíhající paket z této adresy. Pokud klient obdrží pakety z neznámé serverové adresy, klient MUSÍ tyto pakety zahodit.

Ověření adresy pomocí retry paketů

Endpoint MŮŽE testovat dostupnost peeru z nové lokální adresy pomocí validace cesty (sekce 8.2) před migrací připojení na novou lokální adresu. Selhání validace cesty jednoduše znamená, že nová cesta není použitelná pro toto připojení. Selhání validace cesty nezpůsobí ukončení připojení, pokud nejsou k dispozici žádné platné alternativní cesty.

PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID a PADDING rámce jsou “testovací rámce” a všechny ostatní rámce jsou “netestovací rámce”. Paket obsahující pouze testovací rámce je “testovací paket” a paket obsahující jakýkoli jiný rámec je “netestovací paket”.

Ověření adresy pro budoucí připojení

Koncový bod může migrovat připojení na novou lokální adresu odesláním paketů obsahujících rámce jiné než probing z této adresy.

Každý endpoint validuje adresu svého peer během navazování spojení. Proto může migrující endpoint odesílat svému peer s vědomím, že peer je ochoten přijímat na své aktuální adrese. Endpoint tak může migrovat na novou lokální adresu, aniž by nejprve musel validovat adresu peer.

Pro navázání dosažitelnosti na nové cestě iniciuje koncový bod validaci cesty (Sekce 8.2) na nové cestě. Koncový bod MŮŽE odložit validaci cesty až do doby, kdy protějšek odešle další neprůzkumný rámec na svou novou adresu.

Při migraci nemusí nová cesta podporovat aktuální rychlost odesílání koncového bodu. Koncový bod proto resetuje svůj řadič zahlcení a odhad RTT, jak je popsáno v sekci 9.4.

Nová cesta nemusí mít stejnou ECN schopnost. Proto koncový bod validuje ECN schopnost jak je popsáno v Sekci 13.4.

Integrita Address Validation Token

Přijetí paketu z nové adresy peer obsahujícího non-probing rámec indikuje, že peer migroval na tuto adresu.

Pokud příjemce povolí migraci, MUSÍ poslat následující pakety na novou adresu peer a MUSÍ zahájit validaci cesty (Sekce 8.2) k ověření vlastnictví adresy peer, pokud validace již neprobíhá. Pokud příjemce nemá žádné nepoužité connection ID od peer, nebude moci na nové cestě nic poslat, dokud peer jedno neposkytne; viz Sekce 9.5.

Endpoint změní adresu, na kterou odesílає pakety, pouze v reakci na paket s nejvyšším číslem, který není sondovací. To zajišťuje, že endpoint neodesílá pakety na starou adresu protějšku v případě, že obdrží pakety v nesprávném pořadí.

Koncový bod MŮŽE odeslat data na nevalidovanou adresu protějšku, ale MUSÍ se chránit proti potenciálním útokům, jak je popsáno v sekcích 9.3.1 a 9.3.2. Koncový bod MŮŽE přeskočit validaci adresy protějšku, pokud byla tato adresa nedávno viděna. Zejména pokud se koncový bod vrátí na dříve validovanou cestu po zjištění nějaké formy falešné migrace, přeskočení validace adresy a obnovení detekce ztrát a stavu zahlcení může snížit dopad útoku na výkon.

Po změně adresy, na kterou odesílає neprobingové pakety, může endpoint opustit jakékoli ověřování cesty pro ostatní adresy.

Přijetí paketu z nové adresy peer může být výsledkem NAT rebindingu u peer.

Po ověření nové klientské adresy SHOULD server odeslat nové tokeny pro ověření adresy (sekce 8) klientovi.

Validace cesty

Je možné, že peer falšuje svou zdrojovou adresu, aby způsobil, že endpoint odešle nadměrné množství dat neochotnému hostiteli. Pokud endpoint odesílá výrazně více dat než falšující peer, migrace připojení může být použita k zesílení objemu dat, která může útočník generovat směrem k oběti.

Jak je popsáno v oddílu 9.3, endpoint je povinen validovat novou adresu partnera za účelem potvrzení, že partner vlastní novou adresu. Dokud není adresa partnera považována za platnou, endpoint omezuje množství dat, která na tuto adresu odesílá; viz oddíl 8. Při absenci tohoto omezení riskuje endpoint své využití pro útok typu denial-of-service proti netušící oběti.

Pokud koncový bod přeskočí validaci adresy protějšku jak je popsáno výše, nemusí omezovat svou rychlost odesílání.

Zahájení validace cesty

Útočník na cestě mohl způsobit falešnou migraci spojení zkopírováním a přepošláním paketu s falešnou adresou tak, aby dorazil před původním paketem. Paket s falešnou adresou bude viděn jako přicházející z migrujícího spojení a původní paket bude považován za duplikát a zahozen. Po falešné migraci se validace zdrojové adresy nezdaří, protože entita na zdrojové adrese nemá potřebné kryptografické klíče k přečtení nebo odpovědi na PATH_CHALLENGE rámec, který jí je zaslán, i kdyby chtěla.

Aby byla chráněna před selháním kvůli takové falešné migraci, koncový bod MUSÍ se vrátit k použití poslední ověřené adresy protějšku, když se ověření nové adresy protějšku nezdaří. Kromě toho příjem paketů s vyššími čísly paketů z legitimní adresy protějšku spustí další migraci připojení. To způsobí, že ověření adresy falešné migrace bude opuštěno, čímž se omezí migrace iniciované útočníkem vkládajícím jediný paket.

Pokud endpoint nemá žádný stav o poslední validované adrese peer, MUSÍ tiše uzavřit spojení zahozením veškerého stavu spojení. To má za následek, že nové pakety na spojení jsou zpracovávány obecně. Například endpoint MŮŽE poslat Stateless Reset jako odpověď na jakékoli další příchozí pakety.

Odpovědi na validaci cesty

Útočník mimo cestu, který může pozorovat pakety, může přeposílat kopie skutečných paketů na koncové body. Pokud kopírovaný paket dorazí před skutečným paketem, bude to vypadat jako NAT rebinding. Jakýkoli skutečný paket bude zahozen jako duplikát. Pokud je útočník schopen pokračovat v přeposílání paketů, může být schopen způsobit migraci na cestu přes útočníka. To umístí útočníka na cestu, což mu dává možnost pozorovat nebo zahazovat všechny následující pakety.

Tento typ útoku spoléhá na to, že útočník používá cestu, která má přibližně stejné charakteristiky jako přímá cesta mezi koncovými body. Útok je spolehlivější, pokud je odesláno relativně málo paketů nebo pokud ztráta paketů spadá do doby pokusu o útok.

Neprobingový paket přijatý na původní cestě, který zvýší maximální číslo přijatého paketu, způsobí, že se endpoint přesune zpět na tuto cestu. Vyvolávání paketů na této cestě zvyšuje pravděpodobnost, že útok bude neúspěšný. Zmírnění tohoto útoku proto závisí na spuštění výměny paketů.

V reakci na zdánlivou migraci MUSÍ koncové body validovat dříve aktivní cestu pomocí rámce PATH_CHALLENGE. To vyvolá odesílání nových paketů na této cestě. Pokud cesta již není životaschopná, pokus o validaci vyprší a selže; pokud je cesta životaschopná, ale již není požadována, validace uspěje, ale výsledkem bude pouze odesílání sondovacích paketů na této cestě.

Koncový bod, který obdrží PATH_CHALLENGE na aktivní cestě, BY MĚL odeslat neprůzkumný paket jako odpověď. Pokud neprůzkumný paket dorazí před jakoukoli kopií vytvořenou útočníkem, výsledkem je migrace spojení zpět na původní cestu. Jakákoli následná migrace na jinou cestu restartuje celý tento proces.

Tato obrana není dokonalá, ale to se nepovažuje za vážný problém. Pokud je cesta prostřednictvím útoku spolehlivě rychlejší než původní cesta navzdory několika pokusům o použití původní cesty, není možné rozlišit mezi útokem a zlepšením směrování.

Koncový bod by také mohl použít heuristiky ke zlepšení detekce tohoto stylu útoku. Například NAT rebinding je nepravděpodobný, pokud byly nedávno přijaty pakety na staré cestě; podobně je rebinding vzácný na IPv6 cestách. Koncové body mohou také hledat duplikované pakety. Naopak změna connection ID spíše naznačuje záměrnou migraci než útok.

Úspěšná validace cesty

Kapacita dostupná na nové cestě nemusí být stejná jako na staré cestě. Pakety odeslané po staré cestě NESMÍ přispívat k řízení zahlcení nebo odhadu RTT pro novou cestu.

Po potvrzení vlastnictví nové adresy peera MUSÍ endpoint okamžitě resetovat řadič přetížení a estimátor round-trip time pro novou cestu na počáteční hodnoty (viz Přílohy A.3 a B.3 QUIC-RECOVERY), pokud jedinou změnou v adrese peera není jeho číslo portu. Protože změny pouze portu jsou běžně výsledkem NAT rebinding nebo jiné aktivity middlebox, endpoint MŮŽE místo toho v těchto případech zachovat svůj stav řízení přetížení a odhad round-trip místo návratu k počátečním hodnotám. V případech, kdy se stav řízení přetížení zachovaný ze staré cesty používá na nové cestě s podstatně odlišnými charakteristikami, může odesílatel přenášet příliš agresivně, dokud se řadič přetížení a RTT estimátor nepřizpůsobí. Obecně se implementacím doporučuje být opatrný při používání předchozích hodnot na nové cestě.

Na přijímací straně může dojít k zdánlivému přeuspořádání, když koncový bod odesílá data a sondy z/do více adres během období migrace, protože dvě výsledné cesty mohou mít různé doby round-trip. Přijímač paketů na více cestách bude stále odesílat ACK rámce pokrývající všechny přijaté pakety.

Ačkoli může být během migrace spojení použito více cest, jeden kontext kontroly zahlcení a jeden kontext obnovy ztráty (jak je popsáno v QUIC-RECOVERY) by mohly být dostačující. Například koncový bod může odložit přepnutí na nový kontext kontroly zahlcení, dokud se nepotvrdí, že stará cesta již není potřeba (jako v případě popsaném v sekci 9.3.3).

Odesílatel může udělat výjimky pro testovací pakety tak, aby jejich detekce ztráty byla nezávislá a nenutila zbytečně kontroler zahlcení snižovat svou rychlost odesílání. Koncový bod může nastavit samostatný časovač při odeslání PATH_CHALLENGE, který je zrušen, pokud je přijata odpovídající PATH_RESPONSE. Pokud časovač vypršel před přijetím PATH_RESPONSE, koncový bod může odeslat nový PATH_CHALLENGE a restartovat časovač na delší časové období. Tento časovač BY MĚL být nastaven jak je popsáno v sekci 6.2.1 QUIC-RECOVERY a NESMÍ být agresivnější.

Neúspěšné ověření cesty

Použití stabilního connection ID na více síťových cestách by umožnilo pasivnímu pozorovateli korelovat aktivitu mezi těmito cestami. Endpoint, který se pohybuje mezi sítěmi, si nemusí přát, aby byla jeho aktivita korelována jakoukoliv entitou jinou než jeho protějškem, proto se používají různá connection ID při odesílání z různých lokálních adres, jak je popsáno v sekci 5.1. Aby to bylo efektivní, endpointy musí zajistit, že connection ID, která poskytují, nemohou být spojena žádnou jinou entitou.

V jakémkoli okamžiku MOHOU koncové body změnit Destination Connection ID, které přenášejí, na hodnotu, která nebyla použita na jiné cestě.

Koncový bod NESMÍ znovu použít ID připojení při odesílání z více než jedné místní adresy – například při zahajování migrace připojení podle popisu v sekci 9.2 nebo při testování nové síťové cesty podle popisu v sekci 9.1.

Podobně endpoint NESMÍ znovu použít connection ID při odesílání na více než jednu cílovou adresu. Kvůli změnám sítě mimo kontrolu svého protějšku může endpoint přijmout pakety z nové zdrojové adresy se stejnou hodnotou pole Destination Connection ID, v takovém případě MŮŽE pokračovat v používání aktuálního connection ID s novou vzdálenou adresou, zatímco stále odesílá ze stejné lokální adresy.

Tyto požadavky týkající se opětovného použití connection ID se vztahují pouze na odesílání paketů, protože neúmyslné změny v cestě bez změny connection ID jsou možné. Například po období síťové nečinnosti může rebinding NAT způsobit, že se pakety odesílají po nové cestě, když klient obnoví odesílání. Endpoint odpovídá na takovou událost způsobem popsaným v sekci 9.3.

Použití různých connection ID pro pakety odesílané v obou směrech na každé nové síťové cestě eliminuje možnost použití connection ID pro propojování paketů ze stejného spojení napříč různými síťovými cestami. Ochrana hlavičky zajišťuje, že čísla paketů nemohou být použita ke korelaci aktivity. To nezabraňuje tomu, aby jiné vlastnosti paketů, jako je časování a velikost, byly použity ke korelaci aktivity.

Endpoint by NEMĚL inicializovat migraci s protějškem, který požádal o connection ID nulové délky, protože provoz přes novou cestu by mohl být triviálně provázán s provozem přes starou cestu. Pokud je server schopen asociovat pakety s connection ID nulové délky se správným spojením, znamená to, že server používá jiné informace k demultiplexování paketů. Například server může poskytnout jedinečnou adresu každému klientovi – například pomocí HTTP alternative services ALTSVC. Informace, které by mohly umožnit správné směrování paketů přes více síťových cest, také umožní aktivitu na těchto cestách propojit entitami jinými než protějškem.

Klient si může přát snížit sledovatelnost přepnutím na nové connection ID, zdrojový UDP port nebo IP adresu (viz RFC8981) při odesílání provozu po období nečinnosti. Změna adresy, ze které odesílá pakety současně, může způsobit, že server detekuje migraci spojení. To zajišťuje, že mechanismy podporující migraci jsou využívány i pro klienty, kteří nezažívají NAT rebinding nebo skutečné migrace. Změna adresy může způsobit, že peer resetuje svůj stav řízení zahltění (viz sekce 9.4), takže adresy by se měly měnit jen zřídka.

Koncový bod, který vyčerpá dostupné ID připojení, nemůže prohledávat nové cesty nebo iniciovat migraci, ani nemůže odpovídat na sondy nebo pokusy svého protějšku o migraci. Aby byla zajištěna možnost migrace a pakety odeslané různými cestami nebylo možné korelovat, koncové body BY MĚLY poskytnout nová ID připojení před migrací protějšků; viz Sekce 5.1.1. Pokud by protějšek mohl vyčerpat dostupná ID připojení, migrující koncový bod by mohl zahrnout rámec NEW_CONNECTION_ID do všech paketů odeslaných po nové síťové cestě.

Server’s Preferred Address

QUIC umožňuje serverům přijímat připojení na jedné IP adrese a pokoušet se přenést tato připojení na preferovanější adresu krátce po handshaku. To je obzvláště užitečné, když se klienti zpočátku připojují k adrese sdílené více servery, ale raději by používali unicast adresu pro zajištění stability připojení. Tato sekce popisuje protokol pro migraci připojení na preferovanou serverovou adresu.

Migrace připojení na novou adresu serveru uprostřed připojení není podporována verzí QUIC specifikovanou v tomto dokumentu. Pokud klient obdrží pakety z nové adresy serveru, aniž by klient inicioval migraci na tuto adresu, klient BY MĚL tyto pakety zahodit.

Zkoumání nové cesty

Server sděluje preferovanou adresu zahrnutím transportního parametru preferred_address do TLS handshake.

Servery MOHOU komunikovat preferovanou adresu každé rodiny adres (IPv4 a IPv6), aby umožnily klientům vybrat tu, která je nejvhodnější pro jejich síťové připojení.

Po potvrzení handshake by klient MĚL vybrat jednu ze dvou adres poskytnutých serverem a zahájit validaci cesty (viz sekce 8.2). Klient sestaví pakety pomocí jakéhokoli dříve nepoužitého aktivního connection ID, získaného buď z transport parametru preferred_address nebo z NEW_CONNECTION_ID rámce.

Jakmile ověření cesty uspěje, klient BY MĚL začít odesílat všechny budoucí pakety na novou adresu serveru pomocí nového connection ID a ukončit používání staré adresy serveru. Pokud ověření cesty selže, klient MUSÍ pokračovat v odesílání všech budoucích paketů na původní IP adresu serveru.

Zahájení migrace připojení

Klient, který migruje na preferovanou adresu, MUSÍ validovat adresu, kterou si vybere, před migrací; viz sekce 21.5.3.

Server může obdržet paket adresovaný na svou preferovanou IP adresu kdykoli poté, co přijme připojení. Pokud tento paket obsahuje PATH_CHALLENGE frame, server odešle paket obsahující PATH_RESPONSE frame podle Sekce 8.2. Server MUSÍ odesílat non-probing pakety ze své původní adresy, dokud neobdrží non-probing paket od klienta na své preferované adrese a dokud server nevaliduje novou cestu.

Server MUSÍ provést sondování na cestě směrem ke klientovi ze své preferované adresy. To pomáhá chránit proti falešné migraci iniciované útočníkem.

Jakmile server dokončí validaci cesty a obdrží nezkouškový paket s novým největším číslem paketu na své preferované adrese, server začne odesílat nezkouškové pakety klientovi výhradně ze své preferované IP adresy. Server BY MĚL zahazovat novější pakety pro toto spojení, které jsou přijaty na staré IP adrese. Server MŮŽE nadále zpracovávat opožděné pakety, které jsou přijaty na staré IP adrese.

Adresy, které server poskytuje v transportním parametru preferred_address, jsou platné pouze pro spojení, ve kterém jsou poskytnuty. Klient NESMÍ tyto adresy používat pro jiná spojení, včetně spojení, která jsou obnovena z aktuálního spojení.

Reakce na migraci připojení

Klient může potřebovat provést migraci připojení před tím, než se přesune na preferovanou adresu serveru. V tomto případě by klient MĚL provést validaci cesty jak k původní, tak k preferované adrese serveru z nové adresy klienta současně.

Pokud validace cesty preferované adresy serveru uspěje, klient MUSÍ opustit validaci původní adresy a migrovat na používání preferované adresy serveru. Pokud validace cesty preferované adresy serveru selže, ale validace původní adresy serveru uspěje, klient MŮŽE migrovat na svou novou adresu a pokračovat v odesílání na původní adresu serveru.

Pokud pakety přijaté na serverem preferované adrese mají jinou zdrojovou adresu než byla pozorována od klienta během handshake, server MUSÍ chránit proti potenciálním útokům jak je popsáno v sekcích 9.3.1 a 9.3.2. Kromě záměrné simultánní migrace se to může také stát, protože klientova přístupová síť použila jiné NAT vazby pro serverem preferovanou adresu.

Servery BY MĚLY iniciovat validaci cesty na novou adresu klienta po obdržení probe paketu z jiné adresy; viz Sekce 8.

Klient, který migruje na novou adresu, BY MĚL použít preferovanou adresu ze stejné rodiny adres pro server.

ID připojení poskytnuté v transportním parametru preferred_address není specifické pro adresy, které jsou poskytnuty. Toto ID připojení je poskytováno k zajištění, že klient má k dispozici ID připojení pro migraci, ale klient MŮŽE toto ID připojení použít na jakékoli cestě.

Falšování adres peerů

QUIC doporučuje, aby koncové body, které odesílají data pomocí IPv6, MĚLY aplikovat IPv6 flow label v souladu s RFC 6437, pokud místní API neumožňuje nastavování IPv6 flow labels.

Bohužel Java API neumožňuje nastavování IPv6 flow labels.

Necíle

Následující text je zkopírován z QUIC RFC 9000. Pro každou sekci proveďte kontrolu a úpravy.

Cílem QUIC je poskytovat bezpečné transportní spojení. Sekce 21.1 poskytuje přehled těchto vlastností; následující sekce diskutují omezení a upozornění týkající se těchto vlastností, včetně popisů známých útoků a protiopatření.

Podvržení adresy na cestě

Úplná bezpečnostní analýza QUIC je mimo rozsah tohoto dokumentu. Tato sekce poskytuje neformální popis požadovaných bezpečnostních vlastností jako pomoc pro implementátory a jako návod pro analýzu protokolu.

QUIC předpokládá model hrozeb popsaný v SEC-CONS a poskytuje ochranu proti mnoha útokům, které z tohoto modelu vyplývají.

Pro tento účel jsou útoky rozděleny na pasivní a aktivní útoky. Pasivní útočníci mají schopnost číst pakety ze sítě, zatímco aktivní útočníci mají také schopnost zapisovat pakety do sítě. Pasivní útok však může zahrnovat útočníka se schopností způsobit změnu routingu nebo jinou modifikaci v cestě, kterou pakety tvořící spojení procházejí.

Útočníci jsou dále kategorizováni jako útočníci na cestě (on-path attackers) nebo útočníci mimo cestu (off-path attackers). Útočník na cestě může číst, modifikovat nebo odstranit jakýkoliv paket, který pozoruje, takže paket již nedosáhne svého cíle, zatímco útočník mimo cestu pakety pozoruje, ale nemůže zabránit původnímu paketu v dosažení zamýšleného cíle. Oba typy útočníků mohou také odesílat libovolné pakety. Tato definice se liší od definice v sekci 3.5 dokumentu SEC-CONS v tom, že útočník mimo cestu je schopen pakety pozorovat.

Vlastnosti handshake, chráněných paketů a migrace připojení jsou posuzovány samostatně.

Přeposílání paketů mimo cestu

QUIC handshake zahrnuje TLS 1.3 handshake a dědí kryptografické vlastnosti popsané v Příloze E.1 dokumentu TLS13. Mnoho bezpečnostních vlastností QUIC závisí na tom, že TLS handshake poskytuje tyto vlastnosti. Jakýkoli útok na TLS handshake by mohl ovlivnit QUIC.

Jakýkoliv útok na TLS handshake, který kompromituje tajnost nebo jedinečnost session klíčů, nebo autentizaci účastnících se peerů, ovlivňuje další bezpečnostní záruky poskytované protokolem QUIC, které závisí na těchto klíčích. Například migrace (Sekce 9) závisí na účinnosti ochrany důvěrnosti, jak pro vyjednávání klíčů pomocí TLS handshake, tak pro ochranu QUIC paketů, aby se předešlo možnosti propojování napříč síťovými cestami.

Útok na integritu TLS handshake by mohl umožnit útočníkovi ovlivnit výběr aplikačního protokolu nebo verze QUIC.

Kromě vlastností poskytovaných TLS protokolem poskytuje QUIC handshake určitou ochranu proti DoS útokům na handshake.

Detekce ztrát a řízení zahlcení

Validace adresy (Sekce 8) se používá k ověření, že entita, která si nárokuje danou adresu, je schopna přijímat pakety na této adrese. Validace adresy omezuje cíle amplifikačních útoků na adresy, u kterých může útočník pozorovat pakety.

Před validací adresy jsou endpoints omezené v tom, co mohou odesílat. Endpoints nemohou odesílat data směrem k nevalidované adrese v objemu překračujícím trojnásobek dat přijatých z této adresy.

Poznámka: Limit proti zesílení se vztahuje pouze tehdy, když koncový bod odpovídá na pakety přijaté z nevalidované adresy. Limit proti zesílení se nevztahuje na klienty při navazování nového spojení nebo při zahájení migrace spojení.

Důsledky migrace připojení pro soukromí

Výpočet prvního letu serveru pro úplný handshake je potenciálně nákladný a vyžaduje jak podpis, tak výpočet výměny klíčů. Aby se zabránilo výpočetním DoS útokům, Retry paket poskytuje levný mechanismus výměny tokenů, který serverům umožňuje ověřit IP adresu klienta před provedením jakýchkoliv nákladných výpočtů za cenu jediné zpáteční cesty. Po úspěšném handshake mohou servery vydávat klientům nové tokeny, které umožní navázání nového spojení bez vzniku těchto nákladů.

Preferovaná adresa serveru

Útočník na cestě nebo mimo cestu může vynutit selhání handshaku nahrazením nebo předběhnutím Initial paketů. Jakmile jsou vyměněny platné Initial pakety, následující Handshake pakety jsou chráněny pomocí Handshake klíčů a útočník na cestě nemůže vynutit selhání handshaku jinak než zahazováním paketů, což způsobí, že koncové body pokus opustí.

Útočník na cestě může také nahradit adresy paketů na obou stranách a způsobit tak, že klient nebo server bude mít nesprávný pohled na vzdálené adresy. Takový útok je k nerozeznání od funkcí prováděných NAT.

Sdělování preferované adresy

Celý handshake je kryptograficky chráněn, přičemž počáteční pakety jsou šifrovány pomocí klíčů specifických pro verzi a pakety Handshake a následující pakety jsou šifrovány pomocí klíčů odvozených z výměny klíčů TLS. Dále je vyjednávání parametrů začleněno do přepisu TLS a poskytuje tak stejné záruky integrity jako běžné vyjednávání TLS. Útočník může pozorovat transportní parametry klienta (pokud zná salt specifický pro verzi), ale nemůže pozorovat transportní parametry serveru a nemůže ovlivnit vyjednávání parametrů.

ID připojení jsou nešifrovaná, ale chráněná integritou ve všech paketech.

Tato verze QUIC neobsahuje mechanismus vyjednávání verzí; implementace nekompatibilních verzí jednoduše nebudou schopny navázat spojení.

Migrace na preferovanou adresu

Ochrana paketů (Sekce 12.1) aplikuje autentizované šifrování na všechny pakety kromě paketů Version Negotiation, ačkoli pakety Initial a Retry mají omezenou ochranu kvůli použití klíčového materiálu specifického pro verzi; více podrobností viz QUIC-TLS. Tato sekce se zabývá pasivními a aktivními útoky proti chráněným paketům.

Jak útočníci na cestě, tak útočníci mimo cestu mohou provést pasivní útok, při kterém si uloží pozorované pakety pro offline útok proti ochraně paketů v budoucnu; toto platí pro jakéhokoliv pozorovatele jakéhokoliv paketu v jakékoliv síti.

Útočník, který vkládá pakety bez možnosti pozorovat platné pakety pro spojení, pravděpodobně nebude úspěšný, protože ochrana paketů zajišťuje, že platné pakety jsou generovány pouze koncovými body, které vlastní klíčový materiál vytvořený během handshake; viz sekce 7 a 21.1.1. Podobně jakýkoli aktivní útočník, který pozoruje pakety a pokouší se vložit nová data nebo upravit existující data v těchto paketech, by neměl být schopen generovat pakety považované přijímajícím koncovým bodem za platné, kromě Initial paketů.

Útok spoofingu, při kterém aktivní útočník přepíše nechráněné části paketu, který předává nebo vkládá, jako je zdrojová nebo cílová adresa, je účinný pouze tehdy, pokud útočník dokáže předávat pakety na původní koncový bod. Ochrana paketů zajišťuje, že payload paketů mohou zpracovávat pouze koncové body, které dokončily handshake, a neplatné pakety jsou těmito koncovými body ignorovány.

Útočník může také upravit hranice mezi pakety a UDP datagramy, což způsobí sloučení více paketů do jediného datagramu nebo rozdělení sloučených paketů do více datagramů. Kromě datagramů obsahujících Initial pakety, které vyžadují padding, nemá úprava způsobu, jak jsou pakety uspořádány v datagramech, žádný funkční vliv na spojení, ačkoli může změnit některé výkonnostní charakteristiky.

Interakce migrace klienta a preferované adresy

Migrace připojení (kapitola 9) poskytuje koncovým bodům schopnost přecházet mezi IP adresami a porty na více cestách, přičemž používají jednu cestu najednou pro přenos a příjem rámců, které nejsou testovací. Validace cesty (kapitola 8.2) stanovuje, že protějšek je ochoten i schopen přijímat pakety odeslané po konkrétní cestě. To pomáhá snižovat dopady spoofingu adres omezením počtu paketů odeslaných na falešnou adresu.

Tato sekce popisuje zamýšlené bezpečnostní vlastnosti migrace připojení při různých typech DoS útoků.

Použití IPv6 Flow Label a migrace

Útočník, který může způsobit, že pozorovaný paket již nedosáhne svého zamýšleného cíle, je považován za útočníka na cestě (on-path attacker). Když se útočník nachází mezi klientem a serverem, koncové body jsou nuceny posílat pakety přes útočníka, aby navázaly spojení na dané cestě.

Útočník na cestě může:

• Kontrola paketů

• Upravit hlavičky IP a UDP paketů

• Vložit nové pakety

• Zpozdit pakety

• Přeuspořádat pakety

• Zahazovat pakety

• Rozdělení a sloučení datagramů podél hranic paketů

Útočník na cestě nemůže:

• Upravit autentifikovanou část paketu a způsobit, že příjemce tento paket přijme

Útočník na cestě má příležitost modifikovat pakety, které pozoruje; nicméně jakékoli úpravy autentizované části paketu způsobí, že bude přijímajícím koncovým bodem zahozen jako neplatný, protože datové části paketů jsou jak autentizované, tak šifrované.

QUIC si klade za cíl omezit schopnosti útočníka na cestě následujícím způsobem:

1. Útočník na cestě může zabránit použití cesty pro připojení, což způsobí selhání připojení, pokud nemůže použít jinou cestu, která útočníka neobsahuje. Toho lze dosáhnout zahazováním všech paketů, jejich modifikací tak, aby se nepodařilo je dešifrovat, nebo jinými metodami.

2. Útočník na cestě může zabránit migraci na novou cestu, na které se útočník také nachází, tím, že způsobí selhání validace cesty na nové cestě.

3. Útočník na cestě nemůže zabránit klientovi v migraci na cestu, na které útočník není přítomen.

4. Útočník na cestě může snížit propustnost spojení zpožděním paketů nebo jejich zahazováním.

5. Útočník na cestě nemůže způsobit, aby koncový bod přijal paket, u kterého útočník upravil autentifikovanou část tohoto paketu.

Off-Path Active Attacks

Útočník mimo cestu (off-path attacker) není přímo na cestě mezi klientem a serverem, ale mohl by být schopen získat kopie některých nebo všech paketů posílaných mezi klientem a serverem. Je také schopen poslat kopie těchto paketů kterémukoli koncovému bodu.

Útočník mimo cestu může:

• Kontrola paketů

• Vložit nové pakety

• Přeuspořádat vložené pakety

Útočník mimo cestu nemůže:

• Upravit pakety odeslané koncovými body

• Zpozdit pakety

• Zahodit pakety

• Změnit pořadí původních paketů

Útočník mimo cestu může vytvořit upravené kopie paketů, které pozoroval, a vložit tyto kopie do sítě, potenciálně s falešnými zdrojovými a cílovými adresami.

Pro účely této diskuse se předpokládá, že útočník mimo cestu má schopnost vložit do sítě upravenou kopii paketu, která dosáhne cílového koncového bodu dříve než dorazí původní paket pozorovaný útočníkem. Jinými slovy, útočník má schopnost důsledně “vyhrát” závod s legitimními pakety mezi koncovými body, což může způsobit, že příjemce bude původní paket ignorovat.

Předpokládá se také, že útočník má k dispozici zdroje nezbytné k ovlivnění stavu NAT. Konkrétně může útočník způsobit, že koncový bod ztratí své NAT vazby a poté získá stejný port pro použití se svým vlastním provozem.

QUIC si klade za cíl omezit schopnosti útočníka mimo cestu následovně:

1. Útočník mimo cestu může soupeřit s pakety a pokusit se stát “omezeným” útočníkem na cestě.

2. Útočník mimo cestu může způsobit úspěšné ověření cesty pro přeposílané pakety se zdrojovou adresou uvedenou jako útočník mimo cestu, pokud dokáže poskytnout lepší konektivitu mezi klientem a serverem.

3. Útočník mimo cestu nemůže způsobit uzavření spojení poté, co byl handshake dokončen.

4. Útočník mimo cestu nemůže způsobit selhání migrace na novou cestu, pokud nemůže pozorovat novou cestu.

5. Útočník mimo cestu se může stát omezeným útočníkem na cestě během migrace na novou cestu, pro kterou je také útočníkem mimo cestu.

6. Útočník mimo cestu se může stát omezeným útočníkem na cestě tím, že ovlivní sdílený NAT stav tak, že odesílá pakety na server ze stejné IP adresy a portu, které klient původně použil.

Přehled bezpečnostních vlastností

Omezený útočník na cestě je útočník mimo cestu, který nabídl zlepšené směrování paketů duplikováním a předáváním původních paketů mezi serverem a klientem, což způsobuje, že tyto pakety dorazí před původními kopiemi, takže původní pakety jsou zahozeny cílovým koncovým bodem.

Omezený útočník na cestě se liší od útočníka na cestě v tom, že se nenachází na původní cestě mezi koncovými body, a proto původní pakety odeslané koncovým bodem stále dosahují svého cíle. To znamená, že budoucí selhání při směrování kopírovaných paketů do cíle rychleji než jejich původní cesta nezabrání původním paketům v dosažení cíle.

Omezený útočník na cestě může:

• Kontrola paketů

• Vložit nové pakety

• Upravit nezašifrované hlavičky paketů

• Přeuspořádat pakety

Omezený útočník na cestě nemůže:

• Zpozdit pakety tak, aby dorazily později než pakety odeslané po původní cestě

• Zahazovat pakety

• Modifikovat autentizovanou a šifrovanou část paketu a způsobit, že příjemce tento paket přijme

Omezený útočník na cestě může pouze zdržet pakety do bodu, kdy původní pakety dorazí před duplikovanými pakety, což znamená, že nemůže nabídnout směrování s horší latencí než původní cesta. Pokud omezený útočník na cestě zahazuje pakety, původní kopie stále dorazí do cílového koncového bodu.

QUIC si klade za cíl omezit schopnosti omezeného off-path útočníka následovně:

1. Omezený útočník na cestě nemůže způsobit uzavření spojení po dokončení handshake.

2. Omezený útočník na cestě nemůže způsobit uzavření nečinného spojení, pokud klient jako první obnoví aktivitu.

3. Omezený útočník na cestě může způsobit, že nečinné spojení bude považováno za ztracené, pokud server jako první obnoví aktivitu.

Všimněte si, že tyto záruky jsou stejné záruky poskytované pro jakýkoliv NAT, ze stejných důvodů.

Handshake

Jako šifrovaný a ověřený transport poskytuje QUIC řadu ochran proti útokům typu denial of service. Jakmile je kryptografický handshake dokončen, QUIC endpointy zahazují většinu paketů, které nejsou ověřené, čímž výrazně omezují schopnost útočníka zasahovat do existujících připojení.

Jakmile je spojení navázáno, QUIC endpointy mohou přijímat některé neautentizované ICMP pakety (viz sekce 14.2.1), ale použití těchto paketů je velmi omezené. Jediný další typ paketu, který endpoint může přijmout, je stateless reset (sekce 10.3), který spoléhá na to, že token zůstane tajný, dokud není použit.

Během vytváření spojení poskytuje QUIC pouze ochranu proti útokům z míst mimo síťovou cestu. Všechny QUIC pakety obsahují důkaz, že příjemce viděl předchozí paket od svého partnera.

Adresy se nemohou změnit během handshake, takže koncové body mohou zahodit pakety, které jsou přijaty na jiné síťové cestě.

Pole Source a Destination Connection ID jsou primárním prostředkem ochrany proti útoku mimo cestu během handshaku; viz sekce 8.1. Tyto hodnoty musí odpovídat těm, které nastavil protějšek. Kromě Initial a Stateless Resets endpoint přijímá pouze pakety, které obsahují pole Destination Connection ID odpovídající hodnotě, kterou endpoint dříve zvolil. Toto je jediná ochrana poskytovaná pro Version Negotiation pakety.

Pole Destination Connection ID v Initial paketu je vybráno klientem tak, aby bylo nepředvídatelné, což slouží dalšímu účelu. Pakety, které nesou kryptografický handshake, jsou chráněny klíčem, který je odvozen z tohoto connection ID a soli specifické pro verzi QUIC. To umožňuje koncovým bodům používat stejný proces pro autentizaci paketů, které přijímají, jako používají po dokončení kryptografického handshake. Pakety, které nelze autentizovat, jsou zahozeny. Ochrana paketů tímto způsobem poskytuje silnou záruku, že odesílatel paketu viděl Initial paket a porozuměl mu.

Tyto ochrany nejsou určeny k tomu, aby byly účinné proti útočníkovi, který je schopen přijímat QUIC pakety před navázáním spojení. Takový útočník může potenciálně odesílat pakety, které budou QUIC koncovými body přijaty. Tato verze QUIC se pokouší tento druh útoku detekovat, ale očekává, že koncové body nebudou schopny navázat spojení místo toho, aby se zotavily. Z velké části je kryptografický handshake protokol QUIC-TLS odpovědný za detekci manipulace během handshake.

Koncové body mohou používat jiné metody k detekci a pokusům o obnovení z interference s handshake. Neplatné pakety mohou být identifikovány a zahozeny pomocí jiných metod, ale v tomto dokumentu není stanovena žádná konkrétní metoda.

Anti-Amplifikace

Útočník může být schopen získat token pro validaci adresy (Sekce 8) ze serveru a poté uvolnit IP adresu, kterou použil k získání tohoto tokenu. Později může útočník zahájit 0-RTT připojení k serveru pomocí falšování této stejné adresy, která nyní může adresovat jiný (obětní) koncový bod. Útočník tak může potenciálně způsobit, že server odešle množství dat odpovídající počátečnímu congestive window směrem k oběti.

Servery BY MĚLY poskytovat zmírnění tohoto útoku omezením použití a životnosti tokenů pro validaci adres; viz sekce 8.1.3.

Útoky DoS na straně serveru

Koncový bod, který potvrzuje pakety, které neobdržel, může způsobit, že řadič přetížení povolí odesílání rychlostmi přesahujícími to, co síť podporuje. Koncový bod MŮŽE při odesílání paketů přeskakovat čísla paketů, aby detekoval toto chování. Koncový bod pak může okamžitě uzavřit spojení s chybou připojení typu PROTOCOL_VIOLATION; viz sekce 10.2.

Ukončení handshake na cestě

Útok paděláním požadavku nastává, když koncový bod způsobí, že jeho protějšek vydá požadavek směrem k oběti, přičemž požadavek je kontrolován koncovým bodem. Útoky paděláním požadavků mají za cíl poskytnout útočníkovi přístup k možnostem jeho protějšku, které by jinak nemusely být útočníkovi dostupné. U síťového protokolu se útok paděláním požadavku často používá k zneužití jakékoliv implicitní autorizace udělené protějšku obětí kvůli umístění protějšku v síti.

Aby bylo padělání požadavků účinné, útočník musí být schopen ovlivnit, jaké pakety peer odesílá a kam jsou tyto pakety odesílány. Pokud může útočník zacílit na zranitelnou službu s kontrolovanou datovou částí, tato služba může provádět akce, které jsou přičítány útočníkovu peeru, ale jsou rozhodovány útočníkem.

Například útoky typu cross-site request forgery CSRF na webu způsobují, že klient vydává požadavky, které obsahují autorizační cookies COOKIE, což umožňuje jedné stránce přístup k informacím a akcím, které jsou určeny k omezení na jinou stránku.

Vzhledem k tomu, že QUIC běží nad UDP, primární způsob útoku, který je předmětem obav, je takový, kdy útočník může vybrat adresu, na kterou jeho protějšek odesílá UDP datagramy, a může kontrolovat část nechráněného obsahu těchto paketů. Jelikož je většina dat odesílaných QUIC koncovými body chráněna, zahrnuje to kontrolu nad šifrovaným textem. Útok je úspěšný, pokud může útočník způsobit, že protějšek odešle UDP datagram hostiteli, který na základě obsahu datagramu provede nějakou akci.

Tato sekce pojednává o způsobech, jak by mohl být QUIC použit pro útoky typu request forgery.

Tato sekce také popisuje omezená protiopatření, která mohou být implementována QUIC endpointy. Tato zmírňující opatření mohou být použita jednostranně QUIC implementací nebo nasazením, aniž by musely potenciální cíle útoků falšování požadavků podniknout akci. Nicméně tato protiopatření mohou být nedostatečná, pokud UDP-based služby řádně neautorizují požadavky.

Protože útok migrace popsaný v sekci 21.5.4 je poměrně silný a nemá adekvátní protiopatření, implementace QUIC serverů by měly předpokládat, že útočníci jim mohou způsobit generování libovolných UDP payloadů na libovolné cíle. QUIC servery by NEMĚLY být nasazovány v sítích, které nepoužívají ingress filtering BCP38 a také mají nedostatečně zabezpečené UDP endpointy.

Ačkoli není obecně možné zajistit, aby klienti nebyli umístěni společně se zranitelnými koncovými body, tato verze QUIC neumožňuje serverům migraci, čímž zabraňuje útokům falešné migrace na klienty. Jakékoli budoucí rozšíření, které umožní migraci serveru, MUSÍ také definovat protiopatření proti útokům falsifikace.

Vyjednávání parametrů

QUIC nabízí útočníkovi některé příležitosti ovlivnit nebo kontrolovat, kam jeho protějšek odesílá UDP datagramy:

• navázání počátečního spojení (Section 7), kde server je schopen vybrat, kam klient posílá datagramy – například naplněním DNS záznamů;

• preferované adresy (sekce 9.6), kde je server schopen vybrat, kam klient odesílá datagramy;

• spoofované migrace připojení (Sekce 9.3.1), kde je klient schopen použít falšování zdrojové adresy k výběru, kam server pošle následující datagramy; a

• falešné pakety, které způsobí, že server odešle paket Version Negotiation (Section 21.5.5).

Ve všech případech může útočník způsobit, že jeho partner odešle datagramy oběti, která nemusí rozumět QUIC. To znamená, že tyto pakety jsou odeslány partnerem před validací adresy; viz Sekce 8.

Mimo šifrované části paketů nabízí QUIC koncovému bodu několik možností pro řízení obsahu UDP datagramů, které zasílá jeho protějšek. Pole Destination Connection ID poskytuje přímou kontrolu nad bajty, které se objevují na začátku paketů odesílaných protějškem; viz Sekce 5.1. Pole Token v Initial paketech nabízí serveru kontrolu nad ostatními bajty Initial paketů; viz Sekce 17.2.2.

V této verzi QUIC neexistují žádná opatření zabraňující nepřímé kontrole nad šifrovanými částmi paketů. Je nutné předpokládat, že koncové body jsou schopny kontrolovat obsah rámců, které partner odesílá, zejména těch rámců, které přenášejí aplikační data, jako jsou STREAM rámce. Ačkoli to do určité míry závisí na detailech aplikačního protokolu, určitá kontrola je možná v mnoha kontextech použití protokolu. Jelikož má útočník přístup k klíčům pro ochranu paketů, je pravděpodobné, že bude schopen předpovědět, jak bude partner šifrovat budoucí pakety. Úspěšná kontrola nad obsahem datagramu pak vyžaduje pouze to, aby útočník dokázal s určitou mírou spolehlivosti předpovědět číslo paketu a umístění rámců v paketech.

Tato sekce předpokládá, že omezení kontroly nad obsahem datagramů není proveditelné. Zaměření zmírňujících opatření v následujících sekcích je na omezení způsobů, jakými mohou být datagramy odeslané před validací adresy použity pro falšování požadavků.

Chráněné pakety

Útočník jednající jako server si může vybrat IP adresu a port, na kterých inzeruje svou dostupnost, takže se předpokládá, že Initial pakety od klientů jsou k dispozici pro použití v tomto druhu útoku. Validace adresy zahrnutá v handshaku zajišťuje, že – pro nové spojení – klient nebude posílat jiné typy paketů na cíl, který nerozumí QUIC nebo není ochoten přijmout QUIC spojení.

Počáteční ochrana paketů (Sekce 5.2 QUIC-TLS) ztěžuje serverům kontrolu obsahu počátečních paketů odesílaných klienty. Klient volící nepředvídatelné Destination Connection ID zajišťuje, že servery nejsou schopny kontrolovat jakoukoli část šifrované části počátečních paketů od klientů.

Nicméně pole Token je otevřené kontrole serveru a umožňuje serveru použít klienty k provedení útoků padělání požadavků. Použití tokenů poskytnutých s rámcem NEW_TOKEN (Sekce 8.1.3) nabízí jedinou možnost pro padělání požadavků během navazování spojení.

Klienti však nejsou povinni používat rámec NEW_TOKEN. Útokům na padělání požadavků, které spoléhají na pole Token, se lze vyhnout, pokud klienti odešlou prázdné pole Token, když se adresa serveru změnila od okamžiku, kdy byl rámec NEW_TOKEN přijat.

Klienti by se mohli vyhnout používání NEW_TOKEN, pokud se změní adresa serveru. Nezahrnutí pole Token by však mohlo negativně ovlivnit výkon. Servery by se mohly spoléhat na NEW_TOKEN k umožnění odesílání dat přesahujících trojnásobný limit na odesílání dat; viz sekce 8.1. To se zejména týká případů, kdy klienti používají 0-RTT k vyžádání dat ze serverů.

Odeslání paketu Retry (Sekce 17.2.5) nabízí serveru možnost změnit pole Token. Po odeslání Retry může server také řídit pole Destination Connection ID následných Initial paketů od klienta. To také může umožnit nepřímé řízení šifrovaného obsahu Initial paketů. Výměna paketu Retry však ověří adresu serveru, čímž zabrání použití následných Initial paketů pro padělání požadavků.

Migrace spojení

Servery mohou specifikovat preferovanou adresu, na kterou se klienti následně migrují po potvrzení handshake; viz sekce 9.6. Pole Destination Connection ID paketů, které klient odesílá na preferovanou adresu, může být použito pro padělání požadavků.

Klient NESMÍ odesílat rámce, které nejsou probing, na preferovanou adresu před ověřením této adresy; viz sekce 8. To výrazně omezuje možnosti, které má server pro kontrolu šifrované části datagramů.

Tento dokument nenabízí žádná další protiopatření, která jsou specifická pro použití preferovaných adres a mohou být implementována koncovými body. Obecná opatření popsaná v sekci 21.5.6 by mohla být použita jako další zmírnění.

Aktivní útoky na cestě

Klienti jsou schopni prezentovat falešnou zdrojovou adresu jako součást zdánlivé migrace připojení, aby přinutili server odeslat datagramy na tuto adresu.

Pole Destination Connection ID v jakýchkoli paketech, které server následně odešle na tuto falešnou adresu, může být použito pro padělání požadavků. Klient také může být schopen ovlivnit šifrovaný text.

Server, který odesílá pouze sondovací pakety (Sekce 9.1) na adresu před validací adresy, poskytuje útočníkovi pouze omezené řízení nad šifrovanou částí datagramů. Nicméně, zejména pro NAT rebinding, to může nepříznivě ovlivnit výkon. Pokud server odesílá rámce nesoucí aplikační data, útočník může být schopen řídit většinu obsahu datagramů.

Tento dokument nenabízí specifická protiopatření, která mohou být implementována koncovými body, kromě obecných opatření popsaných v sekci 21.5.6. Nicméně protiopatření proti falšování adres na úrovni sítě – zejména ingress filtering BCP38 – jsou zvláště účinná proti útokům, které používají falšování a pocházejí z externí sítě.

Aktivní útoky mimo cestu

Klienti, kteří jsou schopni předložit falešnou zdrojovou adresu v paketu, mohou způsobit, že server odešle paket Version Negotiation (sekce 17.2.1) na tuto adresu.

Absence omezení velikosti polí connection ID pro pakety neznámé verze zvyšuje množství dat, která klient kontroluje z výsledného datagramu. První byte tohoto paketu není pod kontrolou klienta a následující čtyři byty jsou nulové, ale klient je schopen kontrolovat až 512 bytů počínaje pátým bytem.

Pro tento útok nejsou poskytnuty žádné specifické protiopatření, ačkoli by se mohly uplatnit obecné ochrany (Sekce 21.5.6). V tomto případě je také účinné ingress filtering BCP38.

Omezené aktivní útoky na cestě

Nejúčinnější obranou proti útokům typu request forgery je úprava zranitelných služeb tak, aby používaly silnou autentizaci. To však není vždy něco, co je v kontrole QUIC nasazení. Tato sekce nastiňuje některé další kroky, které by QUIC koncové body mohly podniknout jednostranně. Všechny tyto dodatečné kroky jsou volitelné, protože v závislosti na okolnostech by mohly zasahovat do legitimního použití nebo mu zabránit.

Služby nabízené přes loopback rozhraní často postrádají správnou autentifikaci. Koncové body MOHOU zabránit pokusům o připojení nebo migraci na loopback adresu. Koncové body by NEMĚLY povolit připojení nebo migraci na loopback adresu, pokud byla stejná služba dříve dostupná na jiném rozhraní nebo pokud byla adresa poskytnutá službou na ne-loopback adrese. Koncové body, které závisí na těchto schopnostech, by mohly nabídnout možnost vypnout tyto ochrany.

Podobně by mohly koncové body považovat změnu adresy na link-local adresu RFC4291 nebo adresu v rozsahu pro soukromé použití RFC1918 z globální, unique-local RFC4193 nebo nesoukromé adresy za potenciální pokus o padělání požadavku. Koncové body by mohly zcela odmítnout používání těchto adres, ale to nese významné riziko narušení legitimního použití. Koncové body by NEMĚLY odmítnout použití adresy, pokud nemají specifické znalosti o síti naznačující, že odesílání datagramů na neověřené adresy v daném rozsahu není bezpečné.

Koncové body MOHOU zvolit snížení rizika padělání požadavků tím, že nezahrnou hodnoty z NEW_TOKEN rámců do Initial paketů nebo odesláním pouze sondovacích rámců v paketech před dokončením validace adresy. Vezměte na vědomí, že to nezabrání útočníkovi v použití pole Destination Connection ID pro útok.

Od koncových bodů se neočekává, že budou mít specifické informace o umístění serverů, které by mohly být zranitelné cíle útoku typu request forgery. Nicméně časem by mohlo být možné identifikovat konkrétní UDP porty, které jsou běžné cíle útoků, nebo určité vzory v datagramech používané pro útoky. Koncové body MOHOU zvolit, že nebudou odesílat datagramy na tyto porty nebo nebudou odesílat datagramy odpovídající těmto vzorům před validací cílové adresy. Koncové body MOHOU vyřadit connection ID obsahující vzory známé jako problematické, aniž by je použily.

Poznámka: Úprava koncových bodů pro aplikaci těchto ochran je efektivnější než nasazování síťových ochran, protože koncové body nemusí provádět žádné další zpracování při odesílání na adresu, která byla validována.

Handshake Denial of Service

Útoky běžně známé jako Slowloris SLOWLORIS se snaží udržet mnoho připojení k cílovému koncovému bodu otevřených a držet je otevřené co nejdéle. Tyto útoky mohou být prováděny proti QUIC koncovému bodu generováním minimálního množství aktivity nezbytné k tomu, aby nedošlo k uzavření kvůli nečinnosti. To může zahrnovat odesílání malých množství dat, postupné otevírání oken řízení toku za účelem kontroly rychlosti odesílatele, nebo vytváření ACK rámců, které simulují vysokou míru ztrát.

Implementace QUIC BY MĚLY poskytovat ochranu proti útokům Slowloris, jako je zvýšení maximálního počtu klientů, které server povolí, omezení počtu připojení, které může vytvořit jedna IP adresa, zavedení omezení minimální rychlosti přenosu pro připojení a omezení doby, po kterou může být endpoint připojen.

Amplifikační útok

Nepřátelský odesílatel by mohl úmyslně neodeslat části dat streamu, což by způsobilo, že příjemce vyčlení prostředky pro neodeslaná data. To by mohlo způsobit neúměrné využití paměti pro přijímací buffer a/nebo vytvoření velké a neefektivní datové struktury u příjemce.

Nepřátelský příjemce může záměrně nepotvrzovat pakety obsahující streamová data ve snaze donutit odesílatele k ukládání nepotvrzených streamových dat pro opětovné odeslání.

Útok na příjemce je zmírněn, pokud okna flow control odpovídají dostupné paměti. Někteří příjemce však paměť nadměrně alokují a inzerují flow control offsety v souhrnu, které překračují skutečně dostupnou paměť. Strategie nadměrné alokace může vést k lepšímu výkonu, když jsou koncové body dobře vychované, ale činí koncové body zranitelnými vůči útoku fragmentace proudu.

QUIC implementace BY MĚLY poskytovat ochranu proti útokům fragmentace streamů. Ochranná opatření by mohla zahrnovat vyhýbání se nadměrnému přidělování paměti, omezování velikosti struktur pro sledování dat, odkládání sestavování STREAM rámců, implementaci heuristik založených na stáří a době trvání děr při sestavování, nebo nějakou kombinaci těchto přístupů.

Optimistic ACK útok

Nepřátelský endpoint může otevřít velké množství streamů, čímž vyčerpá stav na endpointu. Nepřátelský endpoint by mohl tento proces opakovat na velkém počtu připojení, způsobem podobným SYN flooding útokům v TCP.

Obvykle klienti otevírají proudy sekvenčně, jak je vysvětleno v sekci 2.1. Nicméně, když je několik proudů iniciováno v krátkých intervalech, ztráta nebo změna pořadí může způsobit, že STREAM rámce, které otevírají proudy, budou přijaty mimo pořadí. Při příjmu vyššího čísla stream ID je příjemce povinen otevřít všechny mezilehlé proudy stejného typu; viz sekce 3.2. Tedy při novém připojení otevření proudu 4000000 otevře 1 milion a 1 klientem iniciovaných obousměrných proudů.

Počet aktivních streamů je omezen parametry initial_max_streams_bidi a initial_max_streams_uni transportu, které jsou aktualizovány případnými přijatými rámci MAX_STREAMS, jak je vysvětleno v sekci 4.6. Pokud jsou tyto limity zvoleny uvážlivě, zmírňují účinek útoku stream commitment. Nicméně nastavení příliš nízkého limitu by mohlo ovlivnit výkon, když aplikace očekávají otevření velkého počtu streamů.

Útoky typu Request Forgery

QUIC i TLS obsahují rámce nebo zprávy, které mají legitimní použití v některých kontextech, ale tyto rámce nebo zprávy mohou být zneužity k tomu, aby nutily protější stranu vynaložit výpočetní prostředky, aniž by to mělo jakýkoliv pozorovatelný dopad na stav spojení.

Zprávy mohou být také použity ke změně a vrácení stavu malými nebo bezvýznamnými způsoby, například odesíláním malých přírůstků k limitům řízení toku.

Pokud jsou náklady na zpracování nepřiměřeně velké ve srovnání se spotřebou šířky pásma nebo vlivem na stav, pak by to mohlo umožnit škodlivému uzlu vyčerpat kapacitu zpracování.

Ačkoli existují legitimní použití pro všechny zprávy, implementace BY MĚLY sledovat náklady na zpracování vzhledem k pokroku a považovat nadměrné množství jakýchkoli neproduktivních paketů za známku útoku. Koncové body MOHOU na tuto situaci reagovat chybou připojení nebo zahozením paketů.

Možnosti ovládání pro koncové body

Útočník na cestě by mohl manipulovat hodnotu ECN polí v IP hlavičce, aby ovlivnil rychlost odesílatele. RFC3168 diskutuje manipulace a jejich účinky podrobněji.

Omezený útočník na cestě může duplikovat a odesílat pakety s upravenými ECN poli, aby ovlivnil rychlost odesílatele. Pokud duplikátní pakety jsou přijímačem zahozeny, útočník bude muset v tomto útoku uspět tím, že předstihne duplikátní paket před původním. Proto QUIC koncové body ignorují ECN pole v IP paketu, pokud není alespoň jeden QUIC paket v tomto IP paketu úspěšně zpracován; viz sekce 13.4.

Padělání požadavků s klientskými počátečními pakety

Stateless resety vytvářejí možný útok typu denial-of-service analogický k TCP reset injection. Tento útok je možný, pokud je útočník schopen způsobit vygenerování stateless reset tokenu pro spojení s vybraným connection ID. Útočník, který dokáže způsobit vygenerování tohoto tokenu, může resetovat aktivní spojení se stejným connection ID.

Pokud může být paket směrován do různých instancí, které sdílí statický klíč – například změnou IP adresy nebo portu – pak může útočník způsobit, že server odešle stateless reset. Pro ochranu proti tomuto stylu útoku odepření služby MUSÍ být koncové body, které sdílí statický klíč pro stateless resety (viz sekce 10.3.2), uspořádány tak, aby pakety s daným connection ID vždy dorazily do instance, která má stav spojení, pokud toto spojení již není aktivní.

Obecněji platí, že servery NESMÍ generovat bezstavové resetování, pokud by spojení s odpovídajícím connection ID mohlo být aktivní na jakémkoli koncovém bodu používajícím stejný statický klíč.

V případě clusteru, který používá dynamické vyvažování zátěže, je možné, že dojde ke změně konfigurace load-balanceru, zatímco aktivní instance si zachová stav připojení. I když si instance zachová stav připojení, změna směrování a výsledný stateless reset způsobí ukončení připojení. Pokud neexistuje žádná šance, že by byl paket směrován na správnou instanci, je lepší odeslat stateless reset než čekat na vypršení časového limitu připojení. To je však přijatelné pouze v případě, že směrování nemůže být ovlivněno útočníkem.

Falšování požadavků s preferovanými adresami

Tento dokument definuje pakety QUIC Version Negotiation (Sekce 6), které lze použít k vyjednání verze QUIC používané mezi dvěma koncovými body. Tento dokument však nespecifikuje, jak bude toto vyjednávání probíhat mezi touto verzí a následujícími budoucími verzemi. Konkrétně pakety Version Negotiation neobsahují žádný mechanismus pro prevenci útoků snižujících verzi. Budoucí verze QUIC, které používají pakety Version Negotiation, MUSÍ definovat mechanismus, který je odolný proti útokům snižujícím verzi.

Padělání požadavku s falešnou migrací

Nasazení by měla omezit schopnost útočníka zaměřit nové připojení na konkrétní instanci serveru. V ideálním případě se rozhodnutí o směrování provádějí nezávisle na hodnotách vybraných klientem, včetně adres. Jakmile je instance vybrána, lze vybrat ID připojení tak, aby pozdější pakety byly směrovány do stejné instance.

Padělání požadavku s vyjednáváním verze

Délka QUIC paketů může odhalit informace o délce obsahu těchto paketů. PADDING frame je poskytnut tak, aby koncové body měly určitou schopnost zastřít délku obsahu paketu; viz sekce 19.1.

Překonání analýzy provozu je náročné a je předmětem aktivního výzkumu. Délka není jediný způsob, jak by mohly informace uniknout. Koncové body mohou také odhalit citlivé informace prostřednictvím jiných postranních kanálů, jako je časování paketů.

Relay Security

Následuje analýza Relay Request, Relay Response, Relay Intro a Hole Punch v SSU1.

Omezení: Je důležité, aby Relay byly rychlé. Počet round tripů by měl být minimalizován. Šířka pásma a CPU nejsou tak důležité.

SSU 1: Alice se nejprve připojí k introduceru Bobovi, který přepošle požadavek Charliemu (který je za firewallem). Po hole punchi je relace navázána mezi Alicí a Charliem stejně jako při přímém navázání.

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

Autentifikace: Relay Request a Relay Response nejsou bezpečně neautentifikované, protože Alice a Bob obvykle nemají existující relaci; tyto zprávy používají publikované intro klíče. Relay Request/Response v rámci relace je povoleno a preferováno, pokud relace existuje.

Relay Intro od Boba k Charliemu musí být v existující relaci, takže se předpokládá, že je bezpečné.

Bob může podvrhnout Relay Intros nebo změnit IP/port z Relay Request. Neexistují žádné mechanismy pro kryptografické svázání požadavků s intros nebo jinak zabránit či detekovat škodlivé Boby.

Hash Bobova routeru v současné době není publikován v Charlie’s Router Info, takže to musí být přidáno, pokud chceme, aby zprávy Alice-Bob byly autentifikované. Navíc by další SSU2 parametry musely být publikovány v Charlie’s Router Info, nebo by Alice musela vyhledat Bobovu Router Info v síťové databázi, což by přidalo další zpoždění. Autentifikace by přidala round-trip mezi Alice a Bobem.

Předáním hash routeru Alice Charliemu by Charlie mohl snadněji určit, zda si přeje přijmout spojení od Alice, kontrolou místního seznamu zakázaných. Neexistuje žádný mechanismus pro Charlieho k odmítnutí relay odesláním zamítnutí přes Boba Alici. Neexistuje žádný mechanismus pro Charlieho k přijetí relay odesláním souhlasu přes Boba Alici. Alice musí čekat na HolePunch, nebo jednoduše poslat SessionRequest naslepo. HolePunch může přijít z jiného portu, než Alice očekávala, kvůli NAT, což může ztížit rozpoznání, od kterého routeru HolePunch přišel.

Alice by mohla poslat své úplné Router Info v Relay Request Bobovi a předat ho Charliemu v Relay Intro.

Relay Request neobsahuje časové razítko, takže nemá ochranu proti opakovanému přehrání. Zdrojová IP adresa může být podvrhnuta, aby způsobila, že Charlie pošle Hole Punch na libovolnou IP/port. Relay Request není podepsán, a i kdyby byl podepsán a opatřen časovým razítkem, Charlie nemá úplnou Router Identity, aby mohl podpis ověřit.

Protokol definuje pole výzvy o proměnné délce 0-255 bajtů. Výzva v Relay Request je předána Charliemu v Relay Intro. Protokol však nespecifikuje, jak výzvu vytvořit, použít nebo ověřit, a není implementována. Pokud by HolePunch obsahoval výzvu, Alice by mohla snadno korelovat HolePunch s Charliem.

Čtyřbajtový nonce možná bude potřeba nahradit nebo doplnit 8-bajtovým connection ID.

Prázdná zpráva Hole Punch je jedinečná a může být použita pozorovateli na cestě k identifikaci protokolu, toto by mělo být změněno.

Další diskuse o DPI

Následuje analýza Peer Test v SSU1.

Omezení: Není zvláště důležité, aby Peer Tests byly rychlé, nebo s nízkou šířkou pásma, nebo s nízkou zátěží CPU, možná s výjimkou spuštění routeru, kde preferujeme, aby router zjistil svou dosažitelnost poměrně rychle.

SSU 1:

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

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

Protože specifikaci SSU1 je těžké následovat, dokumentujeme níže obsah zpráv.

Bob vybere Charlie, se kterým má existující session. Zprávy 2 a 3 jsou odeslány in-session. Proto jsou zprávy 2 a 3 zabezpečené a autentizované.

Zpráva 4 by měla být odeslána v rámci relace; avšak specifikace SSU 1 dříve uváděla, že je odeslána s Aliciným publikovaným intro klíčem, což znamená mimo relaci. Před verzí 0.9.52 Java I2P skutečně odesílala s intro klíčem. Od verze 0.9.52 specifikace uvádí, že by měl být použit klíč relace, a Java I2P odesílá zprávu v rámci relace od verze 0.9.52.

Alice nesmí mít existující relaci s Charlie, aby test mohl pokračovat; Alice test přeruší, pokud Bob vybere Charlie, který má relaci s Alice. Proto zprávy 5-7 nejsou zabezpečené a autentizované.

Všechny zprávy Peer Test obsahují 4-bajtový nonce, který si vybírá Alice. Tento nonce se nepoužívá kryptograficky.

Možné útoky na zprávy 5-7: k prozkoumání.

Hash routeru Alice není znám Charlie. Hash routeru Charlie není znám Alice. Ty musí být přidány do protokolu, pokud chceme, aby zprávy mezi Alice a Charlie byly autentizovány. Navíc by musely být poskytnuty další SSU2 parametry ve zprávách Peer Test, nebo by Charlie musel vyhledat Router Info Alice v síťové databázi, což by přidalo další zpoždění. Autentizace by přidala round-trip mezi Charlie a Alice.

Přeposláním hash hodnoty Alice routeru na Charlieho by Charlie mohl snadněji určit, zda se chce účastnit Peer Test s Alice, kontrolou místního seznamu zakázaných.

Čtyřbajtový nonce může být potřeba nahradit nebo doplnit 8-bajtovým connection ID.

Relay and Peer Test Design Goals

Relay a Peer Test mají podobnou konstrukci. V obou případech Alice požádá Boba, aby předal servisní požadavek Charliemu, a Charlie pak na tento požadavek zareaguje.

Aktuální problémy SSU1 Peer Test:

• Peer Test nemá žádnou ochranu proti škodlivému Bobovi
• Peer Test nemá způsob, jak může Bob nebo Charlie odmítnout požadavek
• Peer Test nemá způsob, jak může Alice znát identitu Charlieho nebo jak může Alice odmítnout Charlieho
• Peer Test nemá způsob, jak může Charlie znát identitu Alice nebo jak může Charlie odmítnout Alice
• Peer Test má vlastní ad-hoc schéma pro opětovné přenosy
• Peer Test vyžaduje komplexní stavový automat, aby bylo známo, která zpráva patří ke kterému stavu
• Aniž by věděla, že ji Charlie odmítl, Alice bude považovat test za neúspěšný.

Aktuální problémy s SSU1 Relay:

Většina problémů s Peer Test uvedených výše se také vztahuje na Peer Test.

Máme následující cíle při zlepšování bezpečnosti Relay a Peer Test:

• Charlie by měl publikovat dostatečné informace o svých představovatelích (Bobech) v netdb, aby Alice mohla tyto informace v případě potřeby ověřit. Například publikování router hash pro každého představovatele by umožnilo Alice, pokud bude mít čas, načíst router info z netdb.

• Chránit proti podvrhování adres nebo hrozbám na cestě, které mohou podvrhnout, změnit, falšovat nebo znovu přehrát požadavky od Alice k Bobovi. Bob musí zajistit, že Alice je skutečný I2P router a že předložený požadavek a testovací adresa jsou platné.

• Ochrana proti škodlivým Bobům, kteří mohou falšovat, měnit, padělat nebo opakovat požadavky předávané Charliemu. Charlie musí zajistit, že jak Alice, tak Bob jsou skutečné I2P routery a že předložený požadavek a testovací adresa jsou platné.

• Bob musí od Alice obdržet dostatek informací, aby mohl požadavek ověřit a poté jej přijmout nebo odmítnout. Bob musí mít mechanismus pro odeslání přijetí nebo odmítnutí zpět Alice. Bob nikdy nesmí být nucen provést požadovanou akci.

• Charlie musí obdržet dostatek informací od Boba, aby byl schopen ověřit požadavek a následně jej přijmout nebo odmítnout. Charlie musí mít mechanismus pro odeslání přijetí nebo odmítnutí zpět Bobovi, aby to bylo předáno Alici. Charlie nesmí být nikdy požádán o provedení požadované akce.

• Alice musí být schopna ověřit, že odpověď přeposlaná prostřednictvím Boba skutečně pochází od Charlieho.

• Alice a Charlie musí být schopni ověřit, že jejich následné přímé zprávy (nepředávané přes Boba) pocházejí z očekávaného zdroje a jsou od skutečných I2P routerů.

Následující mechanismy mohou pomoci při dosahování těchto cílů:

• Časové značky

• Podpisy používající klíč pro podepisování routeru

• Použití challenge dat obsažených v požadavku

• Šifrování pomocí šifrovacího klíče routeru

• Odesílání hash routerů, Router Identities nebo Router Infos, nejen IP adres a portů.

• Validace informací o routeru dotazováním síťové databáze

• Kontrola informací routeru, IP adres a portů proti seznamům zakázaných

• Omezování rychlosti

• Vyžaduje navázání relace

Tyto možné mechanismy mohou zvýšit dobu zpracování a latenci funkcí Relay nebo Peer Test. Všechny účinky musí být vyhodnoceny.

Cross-version relaying a peer testing by měly být také podporovány, pokud je to možné. To usnadní postupný přechod z SSU 1 na SSU 2. Možné kombinace verzí jsou:

Bezpečnostní cíle

Summary

Spoléháme na několik existujících protokolů, jak v rámci I2P, tak na vnější standardy, pro inspiraci, vedení a opětovné použití kódu:

• Modely hrozeb: Z NTCP2 NTCP2, s významnými dodatečnými hrozbami relevantními pro UDP transport, jak analyzuje QUIC RFC 9000 RFC 9001.

• Kryptografické volby: Z NTCP2.

• Handshake: Noise XK z NTCP2 a NOISE. Značná zjednodušení NTCP2 jsou možná díky enkapsulaci (inherentní hranice zpráv) poskytované protokolem UDP.

• Handshake ephemeral key obfuscation: Upraveno z NTCP2 ale s použitím ChaCha20 z ECIES místo AES.

• Hlavičky paketů: Adaptováno z WireGuard WireGuard a QUIC RFC 9000 RFC 9001.

• Obfuskace záhlaví paketů: Adaptováno z NTCP2 ale používá ChaCha20 z ECIES místo AES.

• Ochrana záhlaví paketů: Adaptováno z QUIC RFC 9001 a Nonces

• Hlavičky používané jako AEAD associated data jako v ECIES.

• Číslování paketů: Adaptováno z WireGuard WireGuard a QUIC RFC 9000 RFC 9001.

• Zprávy: Adaptováno z SSU

• I2NP fragmentace: Adaptováno z SSU

• Relay a Peer Testing: Adaptováno z SSU

• Podpisy dat Relay a Peer Test: Ze specifikace společných struktur Common

• Formát bloku: Z NTCP2 a ECIES.

• Padding a možnosti: Z NTCP2 a ECIES.

• Acks, nacks: Převzato z QUIC RFC 9000.

• Řízení toku: TBD

Neexistují žádné nové kryptografické primitiva, která by nebyla v I2P dříve použita.

Validace adres

Stejně jako u ostatních I2P transportů NTCP, NTCP2 a SSU 1, tento transport není obecně použitelným prostředkem pro doručování uspořádaného proudu bajtů. Je navržen pro transport I2NP zpráv. Není poskytována žádná abstrakce “proudu”.

Navíc, stejně jako u SSU, obsahuje další nástroje pro NAT traversal podporovaný peer uzly a testování dosažitelnosti (příchozí spojení).

Pokud jde o SSU 1, NEPOSKYTUJE doručování I2NP zpráv v pořadí. Ani nezaručuje doručení I2NP zpráv. Z důvodu efektivity, nebo kvůli doručování UDP datagramů mimo pořadí nebo ztrátě těchto datagramů, mohou být I2NP zprávy doručeny na vzdálenou stranu mimo pořadí, nebo nemusí být doručeny vůbec. I2NP zpráva může být v případě potřeby retransmitována několikrát, ale doručení může nakonec selhat, aniž by to způsobilo odpojení celého spojení. Navíc mohou být nadále odesílány nové I2NP zprávy i během retransmise (obnovování ztracených zpráv) jiných I2NP zpráv.

Tento protokol úplně nezabrání duplicitnímu doručení I2NP zpráv. Router by měl vynucovat vypršení I2NP zpráv a používat Bloom filtr nebo jiný mechanismus založený na ID I2NP zprávy. Viz sekce Duplikace I2NP zpráv níže.

Noise Protocol Framework

Tento návrh poskytuje požadavky založené na Noise Protocol Framework NOISE (Revize 33, 2017-10-04). Noise má podobné vlastnosti jako protokol Station-To-Station (STS), který je základem pro protokol SSU. V terminologii Noise je Alice iniciátor a Bob respondér.

SSU2 je založen na protokolu Noise Noise_XK_25519_ChaChaPoly_SHA256. (Skutečný identifikátor pro počáteční funkci odvození klíče je “Noise_XKchaobfse+hs1+hs2+hs3_25519_ChaChaPoly_SHA256” pro označení I2P rozšíření - viz sekce KDF 1 níže)

POZNÁMKA: Tento identifikátor se liší od toho, který se používá pro NTCP2, protože všechny tři zprávy handshaku používají hlavičku jako přidružená data.

Tento Noise protokol používá následující primitiva:

• Handshake Pattern: XK Alice přenáší svůj klíč Bobovi (X) Alice již zná Bobův statický klíč (K)

• DH Function: X25519 X25519 DH s délkou klíče 32 bajtů podle specifikace v RFC 7748.

• Cipher Function: ChaChaPoly AEAD_CHACHA20_POLY1305 jak je specifikováno v RFC 7539 sekce 2.8. 12 bajtový nonce, s prvními 4 bajty nastavenými na nulu.

• Hash Function: SHA256 Standardní 32-bajtový hash, již hojně používaný v I2P.

Additions to the Framework

Tento návrh definuje následující vylepšení protokolu Noise_XK_25519_ChaChaPoly_SHA256. Tyto obecně následují pokyny v sekci 13 dokumentu NOISE.

1. Handshake zprávy (Session Request, Created, Confirmed) obsahují 16 nebo 32 bajtovou hlavičku.

2. Hlavičky pro zprávy handshake (Session Request, Created, Confirmed) jsou použity jako vstup do mixHash() před šifrováním/dešifrováním k navázání hlaviček ke zprávě.

3. Hlavičky jsou šifrovány a chráněny.

4. Cleartext dočasné klíče jsou skryty pomocí ChaCha20 šifrování s použitím známého klíče a IV. Toto je rychlejší než elligator2.

5. Formát payload je definován pro zprávy 1, 2 a datovou fázi. To samozřejmě není definováno v Noise.

Datová fáze používá šifrování podobné datové fázi protokolu Noise, ale není s ní kompatibilní.

Processing overhead estimate

Bude doplněno

Definitions

Definujeme následující funkce odpovídající používaným kryptografickým stavebním blokům.

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

Každý UDP datagram obsahuje přesně jednu zprávu. Délka datagramu (po IP a UDP hlavičkách) je délka zprávy. Výplň, pokud existuje, je obsažena v bloku výplně uvnitř zprávy. V tomto dokumentu používáme termíny “datagram” a “packet” většinou zaměnitelně. Každý datagram (nebo packet) obsahuje jednu zprávu (na rozdíl od QUIC, kde datagram může obsahovat více QUIC packetů). “Packet header” je část po IP/UDP hlavičce.

Výjimka: Zpráva Session Confirmed je jedinečná v tom, že může být fragmentována napříč více pakety. Viz sekce Session Confirmed Fragmentation níže pro více informací.

Všechny SSU2 zprávy mají délku nejméně 40 bajtů. Jakákoliv zpráva s délkou 1-39 bajtů je neplatná. Všechny SSU2 zprávy mají délku menší nebo rovnu 1472 (IPv4) nebo 1452 (IPv6) bajtů. Formát zpráv je založen na Noise zprávách s modifikacemi pro rámování a nerozlišitelnost. Implementace používající standardní Noise knihovny musí předzpracovat přijaté zprávy do standardního formátu Noise zpráv. Všechna šifrovaná pole jsou AEAD šifrotexty.

Jsou definovány následující zprávy:

Session Establishment

Standardní sekvence navázání spojení, kdy Alice má platný token dříve obdržený od Boba, je následující:

Alice                           Bob

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

Když Alice nemá platný token, sekvence navázání spojení probíhá následovně:

Alice                           Bob

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

Když si Alice myslí, že má platný token, ale Bob ho odmítne (možná proto, že se Bob restartoval), sekvence navázání spojení probíhá následovně:

Alice                           Bob

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

Bob může odmítnout Session nebo Token Request tím, že odpoví zprávou Retry obsahující blok Termination s kódem důvodu. Na základě kódu důvodu by se Alice neměla pokoušet o další požadavek po určitou dobu:

Alice                           Bob

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

or

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

Při použití terminologie Noise je sekvence navázání spojení a dat následující: (Vlastnosti zabezpečení datové části)

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

Jakmile je relace navázána, Alice a Bob si mohou vyměňovat zprávy Data.

Packet Header

Všechny pakety začínají zastřeným (šifrovaným) záhlavím. Existují dva typy záhlaví, dlouhé a krátké. Všimněte si, že prvních 13 bajtů (Destination Connection ID, číslo paketu a typ) je stejných pro všechna záhlaví.

Obecná opatření proti padělání požadavků

Dlouhá hlavička má 32 bajtů. Používá se před vytvořením relace, pro Token Request, SessionRequest, SessionCreated a Retry. Používá se také pro zprávy Peer Test a Hole Punch mimo relaci.

Před šifrováním hlavičky:

+----+----+----+----+----+----+----+----+
  |      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 útoky

Krátká hlavička má 16 bajtů. Používá se pro zprávy Session Created a Data. Neautentizované zprávy jako Session Request, Retry a Peer Test budou vždy používat dlouhou hlavička.

16 bajtů je vyžadováno, protože příjemce musí dešifrovat prvních 16 bajtů pro získání typu zprávy a poté musí dešifrovat dalších 16 bajtů, pokud se jedná o dlouhou hlavičku, jak je indikováno typem zprávy.

Pro Session Confirmed, před šifrováním hlavičky:

+----+----+----+----+----+----+----+----+
  |      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

Více informací o poli frag najdete v sekci Session Confirmed Fragmentation níže.

Pro Data zprávy, před šifrováním hlavičky:

+----+----+----+----+----+----+----+----+
  |      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

Útoky fragmentace a znovusložení streamu

ID připojení musí být generována náhodně. Zdrojová a cílová ID se NESMÍ shodovat, aby útočník na cestě nemohl zachytit a odeslat paket zpět původci, který by vypadal platně. NEPOUŽÍVEJTE čítač pro generování ID připojení, aby útočník na cestě nemohl vygenerovat paket, který by vypadal platně.

Na rozdíl od QUIC neměníme ID připojení během nebo po handshake, ani po zprávě Retry. ID zůstávají konstantní od první zprávy (Token Request nebo Session Request) až po poslední zprávu (Data s Termination). Kromě toho se ID připojení nemění během nebo po path challenge nebo migraci připojení.

Také na rozdíl od QUIC je, že connection ID v hlavičkách jsou vždy header-encrypted. Viz níže.

Stream Commitment Attack

Pokud není v handshaku odeslán žádný blok First Packet Number, pakety jsou číslovány v rámci jedné relace, pro každý směr, počínaje od 0, až do maxima (2**32 -1). Relace musí být ukončena a vytvořena nová relace výrazně před dosažením maximálního počtu odeslaných paketů.

Pokud je v handshake odeslán blok First Packet Number, pakety jsou číslovány v rámci jedné relace pro daný směr, počínaje tímto číslem paketu. Číslo paketu se může během relace přetočit. Když bylo odesláno maximálně 2**32 paketů, čímž se číslo paketu přetočí zpět na první číslo paketu, tato relace již není platná. Relace musí být ukončena a vytvořena nová relace, výrazně před dosažením maximálního počtu odeslaných paketů.

TODO rotace klíčů, snížit maximální číslo paketu?

Handshake pakety, které jsou určeny jako ztracené, jsou retransmitovány celé, se stejným headerem včetně čísla paketu. Handshake zprávy Session Request, Session Created a Session Confirmed MUSÍ být retransmitovány se stejným číslem paketu a identickým šifrovaným obsahem, aby byl použit stejný zřetězený hash pro šifrování odpovědi. Zpráva Retry není nikdy transmitována.

Pakety datové fáze, které jsou určeny jako ztracené, nejsou nikdy retransmitovány celé (kromě ukončení, viz níže). Totéž platí pro bloky, které jsou obsaženy ve ztracených paketech. Místo toho jsou informace, které mohou být přenášeny v blocích, posílány znovu v nových paketech podle potřeby. Datové pakety nejsou nikdy retransmitovány se stejným číslem paketu. Jakákoli retransmise obsahu paketu (bez ohledu na to, zda obsah zůstává stejný) musí použít další nepoužité číslo paketu.

Opětovné odeslání nezměněného celého paketu tak, jak je, se stejným číslem paketu, není povoleno z několika důvodů. Pro kontext viz QUIC RFC 9000 sekce 12.3.

• Je neefektivní ukládat pakety pro opakované odeslání
• Nový paket vypadá z pohledu pozorovatele na cestě jinak, nelze poznat, že je znovu odeslán
• Nový paket obsahuje aktualizovaný ack blok, ne starý ack blok
• Znovu odesíláte pouze to, co je nutné. některé fragmenty mohly být již jednou znovu odeslány a potvrzeny
• Můžete do každého znovu odeslaného paketu vložit tolik, kolik potřebujete, pokud čeká více dat
• Koncové body, které sledují všechny jednotlivé pakety za účelem detekce duplikátů, riskují hromadění nadměrného stavu. Data potřebná pro detekci duplikátů lze omezit udržováním minimálního čísla paketu, pod kterým jsou všechny pakety okamžitě zahozeny.
• Toto schéma je mnohem flexibilnější

Nové pakety se používají k přenosu informací, které byly určeny jako ztracené. Obecně se informace odesílají znovu, když je paket obsahující tyto informace určen jako ztracený, a odesílání se zastaví, když je paket obsahující tyto informace zůstávají stejné) potvrzen.

Výjimka: Paket datové fáze obsahující blok Termination může, ale není vyžadováno, aby byl retransmitován jako celek, tak jak je. Viz sekce Session Termination níže.

Následující pakety obsahují náhodné číslo paketu, které je ignorováno:

• Žádost o relaci
• Relace vytvořena
• Žádost o token
• Opakování
• Test protějšku
• Hole Punch

Pro Alice začíná číslování odchozích paketů na 0 s Session Confirmed. Pro Bob začíná číslování odchozích paketů na 0 s prvním Data paketem, který by měl být ACK Session Confirmed. Čísla paketů v příkladu standardního handshake budou:

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.

Jakékoli opětovné odeslání zpráv handshake (SessionRequest, SessionCreated nebo SessionConfirmed) musí být znovu odesláno nezměněno, se stejným číslem paketu. Nepoužívejte jiné dočasné klíče ani neměňte payload při opětovném odesílání těchto zpráv.

Odmítnutí služby peer

Hlavička (před obfuskací a ochranou) je vždy zahrnuta v přidružených datech pro funkci AEAD, aby se kryptograficky vázala hlavička k datům.

Útoky pomocí explicitního oznámení zahlcení

Šifrování hlaviček má několik cílů. Podívejte se na sekci “Další diskuse o DPI” výše pro pozadí a předpoklady.

• Zabránit online DPI v identifikaci protokolu
• Zabránit vzorcům v sérii zpráv ve stejném spojení, kromě opakovaných přenosů handshake
• Zabránit vzorcům ve zprávách stejného typu v různých spojeních
• Zabránit dešifrování hlaviček handshake bez znalosti introduction key nalezeného v netDb
• Zabránit identifikaci X25519 efemérních klíčů bez znalosti introduction key nalezeného v netDb
• Zabránit dešifrování čísla a typu paketu datové fáze jakýmkoli online nebo offline útočníkem
• Zabránit vkládání platných handshake paketů pozorovatelem na cestě nebo mimo cestu bez znalosti introduction key nalezeného v netDb
• Zabránit vkládání platných datových paketů pozorovatelem na cestě nebo mimo cestu
• Umožnit rychlou a efektivní klasifikaci příchozích paketů
• Poskytovat odolnost proti “sondování” tak, že neexistuje odpověď na špatný Session Request, nebo pokud existuje Retry odpověď, odpověď není identifikovatelná jako I2P bez znalosti introduction key nalezeného v netDb
• Destination Connection ID není kritická data, a je v pořádku, pokud mohou být dešifrována pozorovatelem se znalostí introduction key nalezeného v netDb
• Číslo paketu datové fáze je AEAD nonce a jsou to kritická data. Nesmí být dešifrovatelné pozorovatelem ani se znalostí introduction key nalezeného v netDb. Viz Nonces.

Hlavičky jsou šifrovány pomocí známých klíčů publikovaných v síťové databázi nebo vypočítaných později. Ve fázi handshake to slouží pouze k odolnosti proti DPI, protože klíč je veřejný a klíč i nonce se opakovaně používají, takže jde fakticky jen o obfuskaci. Všimněte si, že šifrování hlaviček se také používá k obfuskaci dočasných klíčů X (v Session Request) a Y (v Session Created).

Viz sekci Zpracování příchozích paketů níže pro další pokyny.

Bajty 0-15 všech hlaviček jsou šifrovány pomocí schématu ochrany hlaviček XOR operací s daty vypočítanými ze známých klíčů, používajíc ChaCha20, podobně jako QUIC RFC 9001 a Nonces. To zajišťuje, že šifrovaná krátká hlavička a první část dlouhé hlavičky se budou jevit jako náhodné.

Pro Session Request a Session Created jsou bajty 16-31 dlouhé hlavičky a 32-bajtový Noise ephemeral klíč šifrovány pomocí ChaCha20. Nešifrovaná data jsou náhodná, takže šifrovaná data budou vypadat náhodně.

Pro Retry jsou bajty 16-31 dlouhé hlavičky zašifrovány pomocí ChaCha20. Nezašifrovaná data jsou náhodná, takže zašifrovaná data budou vypadat náhodně.

Na rozdíl od schématu ochrany hlaviček QUIC RFC 9001 jsou šifrovány VŠECHNY části všech hlaviček, včetně identifikátorů cílového a zdrojového spojení. QUIC RFC 9001 a Nonces se primárně zaměřují na šifrování “kritické” části hlavičky, tj. čísla paketu (ChaCha20 nonce). Zatímco šifrování ID relace činí klasifikaci příchozích paketů o něco složitější, některé útoky jsou tak obtížnější. QUIC definuje různé ID spojení pro různé fáze a pro path challenge a migraci spojení. Zde používáme stejné ID spojení v průběhu celého procesu, protože jsou šifrované.

Existuje sedm fází klíčů pro ochranu hlaviček:

• Požadavek na relaci a požadavek na token
• Relace vytvořena
• Opakovat
• Relace potvrzena
• Fáze dat
• Test peer
• Hole Punch

Všimněte si, že Session Created a Retry jsou JEDINÉ zprávy, které vyžadují záložní zpracování pro k_header_1 k dešifrování Connection ID, protože používají intro klíč odesílatele (Boba). VŠECHNY ostatní zprávy používají intro klíč příjemce pro k_header_1. Záložní zpracování potřebuje pouze vyhledat čekající odchozí připojení podle zdrojové IP/portu.

Pokud záložní zpracování podle zdrojové IP/portu nenajde čekající odchozí spojení, může být několik příčin:

• Není SSU2 zpráva
• Poškozená SSU2 zpráva
• Odpověď je falešná nebo upravená útočníkem
• Bob má symetrický NAT
• Bob změnil IP nebo port během zpracování zprávy
• Bob poslal odpověď přes jiné rozhraní

Zatímco dodatečné záložní zpracování je možné pro pokus o nalezení čekajícího odchozího spojení a dešifrování connection ID pomocí k_header_1 pro toto spojení, pravděpodobně to není nutné. Pokud má Bob problémy se svým NAT nebo směrováním paketů, je pravděpodobně lepší nechat spojení selhat. Tento návrh spoléhá na to, že koncové body si zachovají stabilní adresu po dobu trvání handshake.

Viz sekci Zpracování příchozích paketů níže pro další pokyny.

Viz jednotlivé sekce KDF níže pro odvození šifrovacích klíčů hlavičky pro danou fázi.

Stateless Reset 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])

Tato KDF používá posledních 24 bajtů paketu jako IV pro dvě operace ChaCha20. Vzhledem k tomu, že všechny pakety končí 16bajtovým MAC, je nutné, aby všechny payloady paketů měly minimálně 8 bajtů. Tento požadavek je dodatečně zdokumentován v sekcích zpráv níže.

Downgrade verze

Po dešifrování prvních 8 bajtů hlavičky bude příjemce znát Destination Connection ID. Odtud příjemce ví, který klíč pro šifrování hlavičky má použít pro zbytek hlavičky, na základě key phase dané relace.

Dešifrování dalších 8 bajtů hlavičky pak odhalí typ zprávy a umožní určit, zda se jedná o krátkou nebo dlouhou hlavičku. Pokud se jedná o dlouhou hlavičku, příjemce musí ověřit pole version a netid. Pokud je version != 2, nebo netid != očekávaná hodnota (obecně 2, kromě testovacích sítí), příjemce by měl zprávu zahodit.

Packet Integrity

Všechny zprávy obsahují buď tři nebo čtyři části:

• Záhlaví zprávy
• Pouze pro Session Request a Session Created, efemérní klíč
• ChaCha20-šifrovaný payload
• Poly1305 MAC

Ve všech případech je header (a pokud je přítomen, dočasný klíč) svázán s autentizačním MAC, aby bylo zajištěno, že celá zpráva je neporušená.

• U handshake zpráv Session Request, Session Created a Session Confirmed je hlavička zprávy mixHash()ovaná před fází zpracování Noise
• Dočasný klíč, pokud je přítomen, je pokryt standardním Noise mixHash()
• U zpráv mimo Noise handshake je hlavička použita jako Associated Data pro ChaCha20/Poly1305 šifrování.

Obslužné rutiny příchozích paketů musí vždy dešifrovat ChaCha20 payload a ověřit MAC před zpracováním zprávy, s jednou výjimkou: Pro zmírnění DoS útoků z paketů s falešnou adresou obsahujících zdánlivé Session Request zprávy s neplatným tokenem, obslužná rutina NEMUSÍ pokoušet se dešifrovat a ověřit celou zprávu (vyžadující nákladnou DH operaci kromě ChaCha20/Poly1305 dešifrování). Obslužná rutina může odpovědět Retry zprávou pomocí hodnot nalezených v hlavičce Session Request zprávy.

Authenticated Encryption

Existují tři samostatné instance autentifikovaného šifrování (CipherStates). Jedna během fáze handshake a dvě (přenos a příjem) pro datovou fázi. Každá má svůj vlastní klíč z KDF.

Šifrovaná/autentizovaná data budou reprezentována jako

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

Cílené útoky směrováním

Šifrovaný a autentizovaný datový formát.

Vstupy do funkcí šifrování/dešifrování:

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

Výstup šifrovací funkce, vstup dešifrovací funkce:

+----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |       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

Pro ChaCha20 odpovídá to, co je zde popsáno, RFC 7539, které se také podobně používá v TLS RFC 7905.

Analýza provozu

• Jelikož ChaCha20 je proudová šifra, plaintexty nemusí být doplňovány. Dodatečné bajty keystreamu jsou zahozeny.

• Klíč pro šifru (256 bitů) je dohodnut pomocí SHA256 KDF. Podrobnosti KDF pro každou zprávu jsou uvedeny v samostatných sekcích níže.

AEAD Error Handling

• Ve všech zprávách je velikost AEAD zprávy známa předem. Při selhání AEAD autentifikace musí příjemce zastavit další zpracování zprávy a zprávu zahodit.

• Bob by měl udržovat černou listinu IP adres s opakovanými selháními.

KDF for Session Request

Key Derivation Function (KDF) generuje klíč k pro šifrování ve fázi handshake z výsledku DH, pomocí HMAC-SHA256(key, data) jak je definováno v RFC 2104. Jedná se o funkce InitializeSymmetric(), MixHash() a MixKey(), přesně jak jsou definovány ve specifikaci Noise.

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 odesílá Bobovi, buď jako první zprávu v handshake, nebo v odpovědi na Retry zprávu. Bob odpovídá zprávou Session Created. Velikost: 80 + velikost payload. Minimální velikost: 88

Pokud Alice nemá platný token, měla by místo Session Request odeslat zprávu Token Request, aby se vyhnula režii asymetrického šifrování při generování Session Request.

Dlouhá hlavička. Noise obsah: Alice’s ephemeral key X Noise payload: DateTime a další bloky Maximální velikost payload: MTU - 108 (IPv4) nebo MTU - 128 (IPv6). Pro 1280 MTU: Maximální payload je 1172 (IPv4) nebo 1152 (IPv6). Pro 1500 MTU: Maximální payload je 1392 (IPv4) nebo 1372 (IPv6).

Vlastnosti zabezpečení payload:

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.

Hodnota X je šifrována pro zajištění nerozlišitelnosti a jedinečnosti payload, což jsou nezbytná opatření proti DPI. K dosažení tohoto cíle používáme šifrování ChaCha20 namísto složitějších a pomalejších alternativ, jako je elligator2. Asymetrické šifrování veřejným klíčem Bobova routeru by bylo příliš pomalé. Šifrování ChaCha20 používá Bobův intro klíč, jak je publikován v network database.

ChaCha20 šifrování slouží pouze k odolnosti proti DPI. Jakákoli strana znající Bobův introduction klíč, který je publikovaný v síťové databázi, může dešifrovat hlavičku a hodnotu X v této zprávě.

Surový obsah:

+----+----+----+----+----+----+----+----+
  |  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)

Nešifrovaná data (Poly1305 autentizační tag není zobrazen):

+----+----+----+----+----+----+----+----+
  |      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

• Blok DateTime
• Blok Options (volitelný)
• Blok Relay Tag Request (volitelný)
• Blok Padding (volitelný)

Minimální velikost payload je 8 bajtů. Jelikož blok DateTime má pouze 7 bajtů, musí být přítomen alespoň jeden další blok.

Notes

• Unikátní hodnota X v počátečním bloku ChaCha20 zajišťuje, že šifrovaný text je odlišný pro každou relaci.

• Pro zajištění odolnosti proti zkoumání by Bob neměl posílat zprávu Retry jako odpověď na zprávu Session Request, pokud nejsou pole typu zprávy, verze protokolu a síťového ID ve zprávě Session Request platná.

• Bob musí odmítnout spojení, kde je hodnota časového razítka příliš vzdálená od aktuálního času. Maximální časovou odchylku nazýváme “D”. Bob musí udržovat místní cache dříve použitých handshake hodnot a odmítat duplikáty, aby zabránil replay útokům. Hodnoty v cache musí mít životnost nejméně 2*D. Cache hodnoty jsou závislé na implementaci, avšak lze použít 32-bajtovou hodnotu X (nebo její šifrovaný ekvivalent). Odmítnutí provedete odesláním Retry zprávy obsahující nulový token a ukončovací blok.

• Diffie-Hellman ephemeral klíče nesmí být nikdy znovu použity, aby se zabránilo kryptografickým útokům, a jejich opětovné použití bude odmítnuto jako replay útok.

• Možnosti “KE” a “auth” musí být kompatibilní, tj. sdílené tajemství K musí mít odpovídající velikost. Pokud se přidají další možnosti “auth”, mohlo by to implicitně změnit význam příznaku “KE” tak, aby používal jiný KDF nebo jinou velikost zkrácení.

• Bob musí ověřit, že Alicin efemérní klíč je platný bod na křivce zde.

• Padding by měl být omezen na rozumné množství. Bob může odmítnout spojení s nadměrným paddingem. Bob specifikuje své možnosti paddingu v Session Created. Min/max směrnice TBD. Náhodná velikost od 0 do 31 bajtů minimálně? (Distribuce má být určena, viz Příloha A.) TODO POKUD není vynucena minimální velikost paketu pro PMTU.

• Při většině chyb, včetně AEAD, DH, zjevného replay nebo selhání validace klíče, by Bob měl zastavit další zpracování zprávy a zahodit zprávu bez odpovědi.

• Bob MŮŽE poslat zprávu Retry obsahující nulový token a blok Termination s kódem důvodu clock skew, pokud je časové razítko v bloku DateTime příliš nakloněné.

• Zmírnění DoS útoků: DH je relativně nákladná operace. Stejně jako u předchozího protokolu NTCP by si routery měly přijmout všechna potřebná opatření k zabránění vyčerpání CPU nebo připojení. Stanovte limity na maximální aktivní připojení a maximální počet probíhajících navazování připojení. Vynuťte časové limity pro čtení (jak pro jednotlivé čtení, tak celkové pro “slowloris”). Omezte opakovaná nebo současná připojení ze stejného zdroje. Udržujte černé listiny zdrojů, které opakovaně selhávají. Neodpovídejte na selhání AEAD. Alternativně odpovězte zprávou Retry před operací DH a validací AEAD.

• “ver” pole: Celkový Noise protokol, rozšíření a SSU2 protokol včetně specifikací payload, indikující SSU2. Toto pole může být použito k indikaci podpory pro budoucí změny.

• Pole network ID se používá k rychlé identifikaci připojení mezi sítěmi. Pokud se toto pole neshoduje s Bobovým network ID, Bob by se měl odpojit a blokovat budoucí připojení.

• Bob musí zprávu zahodit, pokud se Source Connection ID rovná Destination Connection ID.

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)

Migrace připojení

Bob odesílá Alici v odpovědi na zprávu Session Request. Alice odpovídá zprávou Session Confirmed. Velikost: 80 + velikost payload. Minimální velikost: 88

Noise obsah: Bobův dočasný klíč Y Noise payload: DateTime, Address a další bloky Maximální velikost payload: MTU - 108 (IPv4) nebo MTU - 128 (IPv6). Pro 1280 MTU: Maximální payload je 1172 (IPv4) nebo 1152 (IPv6). Pro 1500 MTU: Maximální payload je 1392 (IPv4) nebo 1372 (IPv6).

Vlastnosti zabezpečení datové části:

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.

Hodnota Y je šifrována pro zajištění nerozlišitelnosti a jedinečnosti payload, což jsou nezbytná protiopatření proti DPI. K dosažení tohoto cíle používáme šifrování ChaCha20 spíše než složitější a pomalejší alternativy jako elligator2. Asymetrické šifrování k veřejnému klíči Alicina routeru by bylo příliš pomalé. Šifrování ChaCha20 používá Bobův intro klíč, jak je publikován v network database.

ChaCha20 šifrování slouží pouze pro odolnost proti DPI. Jakákoliv strana znající Bobův intro klíč, který je publikován v síťové databázi, a zachytí prvních 32 bajtů Session Request, může dešifrovat hodnotu Y v této zprávě.

Nezpracovaný obsah:

+----+----+----+----+----+----+----+----+
  |  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)

Nešifrovaná data (Poly1305 auth tag nezobrazena):

+----+----+----+----+----+----+----+----+
  |      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 blok
• Address blok
• Relay Tag blok (volitelný)
• New Token blok (volitelný)
• First Packet Number blok (volitelný)
• Options blok (volitelný)
• Termination blok (nedoporučuje se, místo toho odešlete ve zprávě retry)
• Padding blok (volitelný)

Minimální velikost payload je 8 bajtů. Jelikož bloky DateTime a Address dohromady překračují tuto hodnotu, požadavek je splněn pouze těmito dvěma bloky.

Notes

• Alice musí zde ověřit, že Bobův dočasný klíč je platný bod na křivce.

• Padding by měl být omezen na rozumné množství. Alice může odmítnout spojení s nadměrným padding. Alice specifikuje své možnosti padding v Session Confirmed. Min/max směrnice TBD. Náhodná velikost od 0 do 31 bajtů minimum? (Distribuce bude určena, viz Příloha A.) TODO POKUD NENÍ vynucena minimální velikost paketu pro PMTU.

• Při jakékoli chybě, včetně AEAD, DH, timestamp, zjevného replay nebo selhání validace klíče, musí Alice zastavit další zpracování zpráv a zavřít spojení bez odpovědi.

• Alice musí odmítnout připojení, kde je hodnota časového razítka příliš vzdálená od současného času. Nazvěme maximální časový rozdíl “D”. Alice musí udržovat lokální cache dříve použitých handshake hodnot a odmítat duplikáty, aby zabránila replay útokům. Hodnoty v cache musí mít životnost nejméně 2*D. Hodnoty cache jsou závislé na implementaci, nicméně lze použít 32-bajtovou hodnotu Y (nebo její šifrovaný ekvivalent).

• Alice musí zprávu zahodit, pokud se zdrojová IP adresa a port neshodují s cílovou IP adresou a portem Session Request.

• Alice musí zprávu zahodit, pokud se Destination a Source Connection ID neshodují se Source a Destination Connection ID z Session Request.

• Bob odešle blok relay tag, pokud o to Alice požádá v Session Request.

Issues

• Zahrnout možnosti min/max paddingu zde?

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 odesílá Bobovi jako odpověď na zprávu Session Created. Bob okamžitě odpovídá zprávou Data obsahující ACK blok. Velikost: 80 + velikost payload. Minimální velikost: Přibližně 500 (minimální velikost bloku router info je přibližně 420 bajtů)

Noise obsah: Statický klíč Alice Noise payload část 1: Žádná Noise payload část 2: RouterInfo Alice a další bloky Maximální velikost payload: MTU - 108 (IPv4) nebo MTU - 128 (IPv6). Pro MTU 1280: Maximální payload je 1172 (IPv4) nebo 1152 (IPv6). Pro MTU 1500: Maximální payload je 1392 (IPv4) nebo 1372 (IPv6).

Vlastnosti zabezpečení payload:

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.

Toto obsahuje dva ChaChaPoly rámce. První je Alicein zašifrovaný statický veřejný klíč. Druhý je Noise payload: Aliceiny zašifrované RouterInfo, volitelné možnosti a volitelné padding. Používají různé klíče, protože mezi nimi se volá funkce MixKey().

Surový obsah:

+----+----+----+----+----+----+----+----+
  |  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

Nezašifrovaná data (Poly1305 autentizační značky nejsou zobrazeny):

+----+----+----+----+----+----+----+----+
  |      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 blok (musí být první blok)
• Options blok (volitelný)
• New Token blok (volitelný)
• Relay Request blok (volitelný)
• Peer Test blok (volitelný)
• First Packet Number blok (volitelný)
• I2NP, First Fragment, nebo Follow-on Fragment bloky (volitelné, ale pravděpodobně není místo)
• Padding blok (volitelný)

Minimální velikost užitečného nákladu je 8 bajtů. Jelikož blok RouterInfo bude výrazně větší než tato hodnota, požadavek je splněn pouze tímto blokem.

Notes

• Bob musí provést obvyklou validaci Router Info. Ujistit se, že typ podpisu je podporován, ověřit podpis, ověřit, že časové razítko je v rámci mezí, a jakékoli další nezbytné kontroly. Viz níže poznámky k zacházení s fragmentovanými Router Info.

• Bob musí ověřit, že Alicin statický klíč přijatý v prvním rámci odpovídá statickému klíči v Router Info. Bob musí nejprve vyhledat v Router Info NTCP nebo SSU2 Router Address s odpovídající opcí verze (v). Viz sekce Publikované Router Info a Nepublikované Router Info níže. Viz níže poznámky k práci s fragmentovanými Router Info.

• Pokud má Bob starší verzi RouterInfo Alice ve své netdb, ověř, že statický klíč v router info je stejný v obou, pokud je přítomen, a pokud je starší verze méně než XXX stará (viz doba rotace klíče níže)

• Bob musí zde ověřit, že Alicein statický klíč je platný bod na křivce.

• Měly by být zahrnuty možnosti pro specifikaci parametrů paddingu.

• Při jakékoli chybě, včetně selhání AEAD, RI, DH, časového razítka nebo validace klíče, musí Bob zastavit další zpracování zpráv a uzavřít spojení bez odpovědi.

• Obsah rámce Message 3 část 2: Formát tohoto rámce je stejný jako formát rámců datové fáze, kromě toho, že délka rámce je odeslána Alice v Session Request. Viz níže pro formát rámce datové fáze. Rámec musí obsahovat 1 až 4 bloky v následujícím pořadí:

  1. Blok Alice’s Router Info (povinný)
  2. Blok Options (volitelný)
  3. I2NP bloky (volitelné)
  4. Blok Padding (volitelný) Tento rámec nesmí nikdy obsahovat žádný jiný typ bloku. TODO: co s relay a peer test?

• Blok výplně 2. části zprávy 3 je doporučen.

• Nemusí být k dispozici žádné místo, nebo jen malé množství místa, pro I2NP bloky, v závislosti na MTU a velikosti Router Info. NEZAHRNUJTE I2NP bloky, pokud je Router Info fragmentované. Nejjednodušší implementace může spočívat v tom, že nikdy nezahrnete I2NP bloky do zprávy Session Confirmed a všechny I2NP bloky odešlete v následných zprávách Data. Viz sekce Router Info bloku níže pro maximální velikost bloku.

Session Confirmed Fragmentation

Zpráva Session Confirmed musí obsahovat kompletní podepsané Router Info od Alice, aby Bob mohl provést několik požadovaných kontrol:

• Statický klíč “s” v RI se shoduje se statickým klíčem v handshake
• Introdukční klíč “i” v RI musí být extrahován a platný, aby mohl být použit ve fázi dat
• Podpis RI je platný

Bohužel Router Info, i když je gzip komprimované v RI bloku, může překročit MTU. Proto může být Session Confirmed fragmentované napříč dvěma nebo více pakety. Toto je JEDINÝ případ v SSU2 protokolu, kde je AEAD-chráněný payload fragmentovaný napříč dvěma nebo více pakety.

Hlavičky pro každý paket jsou konstruovány následovně:

• VŠECHNY hlavičky jsou krátké hlavičky se stejným číslem packetu 0
• VŠECHNY hlavičky obsahují pole “frag” s číslem fragmentu a celkovým počtem fragmentů
• Nešifrovaná hlavička fragmentu 0 je asociovaná data (AD) pro “jumbo” zprávu
• Každá hlavička je šifrována pomocí posledních 24 bajtů dat v TOMTO packetu

Sestavte sérii paketů následovně:

• Vytvořte jeden RI blok (fragment 0 z 1 v poli frag RI bloku). Nepoužíváme fragmentaci RI bloku, to bylo pro alternativní metodu řešení stejného problému.
• Vytvořte “jumbo” payload s RI blokem a jakýmikoli dalšími bloky, které mají být zahrnuty
• Vypočítejte celkovou velikost dat (nezahrnuje hlavičku), což je velikost payload + 64 bajtů pro statický klíč a dva MACs
• Vypočítejte dostupný prostor v každém paketu, což je MTU mínus IP hlavička (20 nebo 40), mínus UDP hlavička (8), mínus SSU2 krátká hlavička (16). Celková režie na paket je 44 (IPv4) nebo 64 (IPv6).
• Vypočítejte počet paketů.
• Vypočítejte velikost dat v posledním paketu. Musí být větší než nebo rovna 24 bajtům, aby šifrování hlavičky fungovalo. Pokud je příliš malá, buď přidejte padding blok, NEBO zvětšete velikost padding bloku pokud už existuje, NEBO zmenšete velikost jednoho z ostatních paketů tak, aby byl poslední paket dostatečně velký.
• Vytvořte nešifrovanou hlavičku pro první paket, s celkovým počtem fragmentů v poli frag, a zašifrujte “jumbo” payload pomocí Noise, použitím hlavičky jako AD, jak obvykle.
• Rozdělte zašifrovaný jumbo paket na fragmenty
• Přidejte nešifrovanou hlavičku pro každý fragment 1-n
• Zašifrujte hlavičku pro každý fragment 0-n. Každá hlavička používá STEJNÉ k_header_1 a k_header_2 jak je definováno výše v Session Confirmed KDF.
• Odešlete všechny fragmenty

Proces opětovného sestavení:

Když Bob obdrží jakoukoli zprávu Session Confirmed, dešifruje hlavičku, zkontroluje pole frag a zjistí, že zpráva Session Confirmed je fragmentovaná. Nedešifruje (a nemůže dešifrovat) zprávu, dokud nejsou všechny fragmenty přijaty a znovu sestaveny.

• Zachovat hlavičku pro fragment 0, protože se používá jako Noise AD
• Zahodit hlavičky ostatních fragmentů před opětovným sestavením
• Opětovně sestavit “jumbo” payload s hlavičkou fragmentu 0 jako AD a dešifrovat pomocí Noise
• Ověřit RI blok obvyklým způsobem
• Pokračovat do datové fáze a odeslat ACK 0 obvyklým způsobem

Neexistuje žádný mechanismus pro Boba k potvrzení jednotlivých fragmentů. Když Bob obdrží všechny fragmenty, znovu je sestaví, dešifruje a ověří obsah, Bob provede split() jako obvykle, vstoupí do datové fáze a pošle ACK čísla paketu 0.

Pokud Alice neobdrží ACK pro paket číslo 0, musí retransmitovat všechny session confirmed pakety tak, jak jsou.

Příklady:

Pro 1500 MTU přes IPv6 je maximální payload 1372, režie RI bloku je 5, maximální velikost (gzip komprimovaných) RI dat je 1367 (za předpokladu žádných dalších bloků). Se dvěma pakety je režie 2. paketu 64, takže může obsahovat dalších 1436 bajtů payload. Takže dva pakety stačí pro komprimované RI až do velikosti 2803 bajtů.

Největší komprimované RI pozorované v současné síti má přibližně 1400 bajtů; proto by v praxi měly stačit dva fragmenty, i při minimálním MTU 1280. Protokol umožňuje maximálně 15 fragmentů.

Bezpečnostní analýza:

Integrita a bezpečnost fragmentovaného Session Confirmed je stejná jako u nefragmentovaného. Jakákoliv změna kteréhokoliv fragmentu způsobí selhání Noise AEAD po opětovném sestavení. Hlavičky fragmentů po fragmentu 0 se používají pouze k identifikaci fragmentu. I kdyby útočník na cestě měl klíč k_header_2 použitý k šifrování hlavičky (nepravděpodobné, odvozený z handshake), neumožnilo by mu to nahradit platný fragment.

KDF for data phase

Datová fáze používá hlavičku pro asociovaná data.

KDF generuje dva šifrovací klíče k_ab a k_ba z řetězového klíče ck, pomocí HMAC-SHA256(key, data) jak je definováno v RFC 2104. Toto je funkce split(), přesně jak je definována ve specifikaci Noise.

// 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: Všechny typy bloků jsou povoleny. Maximální velikost payload: MTU - 60 (IPv4) nebo MTU - 80 (IPv6). Pro MTU 1500: Maximální payload je 1440 (IPv4) nebo 1420 (IPv6).

Počínaje 2. částí Session Confirmed jsou všechny zprávy uvnitř autentifikovaného a šifrovaného ChaChaPoly payload. Veškeré odsazení je uvnitř zprávy. Uvnitř payload je standardní formát s nula nebo více “bloky”. Každý blok má jednobytový typ a dvoubytovou délku. Typy zahrnují datum/čas, I2NP zprávu, možnosti, ukončení a odsazení.

Poznámka: Bob může, ale není povinen, poslat své RouterInfo k Alici jako svou první zprávu k Alici ve fázi dat.

Bezpečnostní vlastnosti payloadu:

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 musí zahodit zprávu s chybou AEAD.

+----+----+----+----+----+----+----+----+
  |  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)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Nešifrovaná data (Poly1305 autentizační značka není zobrazena):

+----+----+----+----+----+----+----+----+
  |      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

• Minimální velikost datové části je 8 bajtů. Tento požadavek bude splněn jakýmkoliv blokem ACK, I2NP, First Fragment nebo Follow-on Fragment. Pokud požadavek není splněn, musí být zahrnut blok Padding.

• Každé číslo paketu lze použít pouze jednou. Při opětovném přenosu I2NP zpráv nebo fragmentů musí být použito nové číslo paketu.

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 posílá Alice a Alice posílá Charlie pouze pro fáze 5-7 Peer Test. Fáze 1-4 Peer Test musí být odeslány v rámci relace pomocí bloku Peer Test ve zprávě Data. Další informace najdete v níže uvedených sekcích Peer Test Block a Peer Test Process.

Velikost: 48 + velikost datové části.

Noise payload: Viz níže.

Nezpracovaný obsah:

+----+----+----+----+----+----+----+----+
  |  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)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Nešifrovaná data (Poly1305 autentizační tag není zobrazen):

+----+----+----+----+----+----+----+----+
  |      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

Dlouhá hlavička

• DateTime blok
• Address blok (vyžadován pro zprávy 6 a 7, viz poznámka níže)
• Peer Test blok
• Padding blok (volitelný)

Minimální velikost datové části je 8 bajtů. Protože blok Peer Test celkem překračuje tuto hodnotu, požadavek je splněn pouze tímto blokem.

Ve zprávách 5 a 7 může být blok Peer Test identický s blokem ze zpráv 3 a 4 v rámci relace, obsahující dohodu podepsanou Charliem, nebo může být znovu vygenerován. Podpis je volitelný.

Ve zprávě 6 může být blok Peer Test identický s blokem ze zpráv 1 a 2 v rámci relace, obsahující požadavek podepsaný Alicí, nebo může být znovu vygenerován. Podpis je volitelný.

Connection ID: Obě Connection ID jsou odvozena z testovacího nonce. Pro zprávy 5 a 7 odeslané z Charlie do Alice je Destination Connection ID tvořeno dvěma kopiemi 4-bytového big-endian testovacího nonce, tj. ((nonce « 32) | nonce). Source Connection ID je inverzí Destination Connection ID, tj. ~((nonce « 32) | nonce). Pro zprávu 6 odeslanou z Alice do Charlie se obě Connection ID prohodí.

Obsah bloku adres:

• Ve zprávě 5: Není vyžadováno.
• Ve zprávě 6: Charlie’s IP a port vybrané z Charlie’s RI.
• Ve zprávě 7: Alice’s skutečná IP a port, ze kterých byla zpráva 6 přijata.

KDF for Retry

Požadavkem pro zprávu Retry je, že Bob není povinen dešifrovat zprávu Session Request, aby vygeneroval zprávu Retry jako odpověď. Také tato zpráva musí být rychlá na generování, používajíc pouze symetrické šifrování.

// 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 posílá Alice, jako odpověď na zprávu Session Request nebo Token Request. Alice odpovídá novým Session Request. Velikost: 48 + velikost payload.

Slouží také jako zpráva o ukončení (tj. „Neopakovat pokus"), pokud je zahrnut blok ukončení.

Noise payload: Viz níže.

Nezpracovaný obsah:

+----+----+----+----+----+----+----+----+
  |  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)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Nešifrovaná data (Poly1305 autentizační tag není zobrazen):

+----+----+----+----+----+----+----+----+
  |      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

Krátká hlavička

• Blok DateTime
• Blok Address
• Blok Options (volitelný)
• Blok Termination (volitelný, pokud je relace zamítnuta)
• Blok Padding (volitelný)

Minimální velikost payload je 8 bajtů. Jelikož bloky DateTime a Address mají celkem více než 8 bajtů, tento požadavek je splněn pouze těmito dvěma bloky.

Číslování ID připojení

• Pro zajištění odolnosti proti sondování by router neměl odeslat zprávu Retry jako odpověď na zprávu Session Request nebo Token Request, pokud nejsou platná pole typu zprávy, verze protokolu a ID sítě ve zprávě Request.

• Pro omezení rozsahu jakéhokoliv zesilovacího útoku, který může být proveden pomocí falešných zdrojových adres, nesmí zpráva Retry obsahovat velké množství výplně. Doporučuje se, aby zpráva Retry nebyla větší než třikrát větší než zpráva, na kterou reaguje. Alternativně použijte jednoduchou metodu, jako je přidání náhodného množství výplně v rozsahu 1-64 bajtů.

KDF for Token Request

Tato zpráva musí být rychlá na vygenerování, používá pouze symetrické šifrování.

// 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 odesílá Bobovi. Bob odpovídá zprávou Retry. Velikost: 48 + velikost payload.

Pokud Alice nemá platný token, Alice by měla odeslat tuto zprávu namísto Session Request, aby se vyhnula režii asymetrického šifrování při generování Session Request.

Noise payload: Viz níže.

Nezpracovaný obsah:

+----+----+----+----+----+----+----+----+
  |  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)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Nešifrovaná data (Poly1305 autentizační tag není zobrazen):

+----+----+----+----+----+----+----+----+
  |      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

Číslování paketů

• DateTime blok
• Padding blok

Minimální velikost payload je 8 bajtů.

Vazba hlaviček

• Pro poskytnutí odolnosti proti sondování by router neměl odesílat Retry zprávu v odpovědi na Token Request zprávu, pokud nejsou typ zprávy, verze protokolu a pole network ID v Token Request zprávě platné.

• Toto NENÍ standardní Noise zpráva a není součástí handshake. Není vázána na zprávu Session Request jinak než pomocí ID připojení.

• Při většině chyb, včetně AEAD nebo zjevného opakování, by měl Bob zastavit další zpracování zprávy a zahodit zprávu bez odpovědi.

• Bob musí odmítnout připojení, kde je hodnota časového razítka příliš vzdálená od aktuálního času. Nazývejme maximální časový rozdíl “D”. Bob musí udržovat místní cache dříve použitých handshake hodnot a odmítnout duplicity, aby zabránil replay útokům. Hodnoty v cache musí mít životnost alespoň 2*D. Cache hodnoty jsou závislé na implementaci, avšak může být použita 32-bytová X hodnota (nebo její šifrovaný ekvivalent).

• Bob MŮŽE poslat zprávu Retry obsahující nulový token a blok Termination s kódem důvodu clock skew, pokud je časové razítko v bloku DateTime příliš vzdálené.

• Minimální velikost: TBD, stejná pravidla jako pro Session Created?

KDF for Hole Punch

Tato zpráva musí být rychlá na generování a používat pouze symetrické šifrování.

// 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 posílá Alice v odpovědi na Relay Intro obdrženou od Boba. Alice odpovídá novým Session Request. Velikost: 48 + velikost payload.

Noise payload: Viz níže.

Surový obsah:

+----+----+----+----+----+----+----+----+
  |  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)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Nešifrovaná data (Poly1305 autentifikační tag není zobrazen):

+----+----+----+----+----+----+----+----+
  |      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.

Šifrování hlavičky

• DateTime blok
• Address blok
• Relay Response blok
• Padding blok (volitelný)

Minimální velikost payload je 8 bytů. Protože bloky DateTime a Address dohromady přesahují tuto hodnotu, požadavek je splněn pouze těmito dvěma bloky.

Connection ID: Dvě connection ID jsou odvozena z relay nonce. Destination Connection ID jsou dvě kopie 4-bajtového big-endian relay nonce, tj. ((nonce « 32) | nonce). Source Connection ID je inverzí Destination Connection ID, tj. ~((nonce « 32) | nonce).

Alice by měla ignorovat token v hlavičce. Token, který má být použit v Session Request, je v bloku Relay Response.

Noise Payload

Každý Noise payload obsahuje nula nebo více “bloků”.

Toto používá stejný formát bloku, jak je definován ve specifikacích NTCP2 a ECIES. Jednotlivé typy bloků jsou definovány odlišně. Ekvivalentní termín v QUIC RFC 9000 je “frames”.

Existují obavy, že povzbuzování implementátorů ke sdílení kódu může vést k problémům s parsováním. Implementátoři by měli pečlivě zvážit výhody a rizika sdílení kódu a zajistit, aby se pravidla pro řazení a platné bloky lišila pro oba kontexty.

Bezpečnostní aspekty

V šifrovaném payloadu je jeden nebo více bloků. Blok je jednoduchý formát Tag-Length-Value (TLV). Každý blok obsahuje jednobajtový identifikátor, dvoubytovou délku a nula nebo více bajtů dat. Tento formát je identický s formátem v NTCP2 a ECIES, nicméně definice bloků se liší.

Pro rozšiřitelnost musí příjemci ignorovat bloky s neznámými identifikátory a zacházet s nimi jako s paddingem.

(Poly1305 autentizační tag není zobrazen):

+----+----+----+----+----+----+----+----+
  |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

Šifrování hlavičky používá posledních 24 bajtů paketu jako IV pro dvě operace ChaCha20. Protože všechny pakety končí 16bajtovým MAC, vyžaduje to, aby všechny datové části paketů měly minimálně 8 bajtů. Pokud datová část jinak nesplňuje tento požadavek, musí být zahrnut blok Padding.

Maximální velikost ChaChaPoly payload se liší podle typu zprávy, MTU a typu IPv4 nebo IPv6 adresy. Maximální payload je MTU - 60 pro IPv4 a MTU - 80 pro IPv6. Maximální payload data jsou MTU - 63 pro IPv4 a MTU - 83 pro IPv6. Horní limit je přibližně 1440 bajtů pro IPv4, 1500 MTU, Data zprávu. Maximální celková velikost bloku je maximální velikost payload. Maximální velikost jednoho bloku je maximální celková velikost bloku. Typ bloku má 1 bajt. Délka bloku má 2 bajty. Maximální velikost dat jednoho bloku je maximální velikost jednoho bloku minus 3.

Poznámky:

• Implementátoři musí zajistit, že při čtení bloku nebudou poškozená nebo škodlivá data způsobovat čtení přesahující do následujícího bloku nebo za hranice datové části.

• Implementace by měly ignorovat neznámé typy bloků kvůli dopředné kompatibilitě.

Typy bloků:

Block Ordering Rules

V Session Confirmed musí být Router Info prvním blokem.

Ve všech ostatních zprávách není pořadí specifikováno, kromě následujících požadavků: Padding, pokud je přítomen, musí být posledním blokem. Termination, pokud je přítomen, musí být posledním blokem kromě Padding. Více Padding bloků není v jednom payload povoleno.

Block Specifications

Šifrování hlavičky KDF

Pro synchronizaci času:

+----+----+----+----+----+----+----+
  | 0  |    4    |     timestamp     |
  +----+----+----+----+----+----+----+

  blk :: 0
  size :: 2 bytes, big endian, value = 4
  timestamp :: Unix timestamp, unsigned seconds.
               Wraps around in 2106

Poznámky:

• Na rozdíl od SSU 1 neobsahuje hlavička paketu v datové fázi SSU 2 žádný časový údaj.
• Implementace by měly periodicky odesílat DateTime bloky v datové fázi.
• Implementace musí zaokrouhlovat na nejbližší sekundu, aby zabránily časovému zkreslení v síti.

Validace hlaviček

Předat aktualizované možnosti. Možnosti zahrnují: Minimální a maximální padding.

Blok možností bude mít proměnnou délku.

+----+----+----+----+----+----+----+----+
  | 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

Problémy s možnostmi:

• Vyjednávání možností je TBD.

RouterInfo

Předej RouterInfo Alice Bobovi. Používá se pouze v části 2 payloadu Session Confirmed. Nepoužívat ve fázi dat; místo toho použij I2NP DatabaseStore zprávu.

Minimální velikost: Přibližně 420 bytů, pokud není identita routeru a podpis v router info kompresibilní, což je nepravděpodobné.

POZNÁMKA: Blok Router Info není nikdy fragmentován. Pole frag je vždy 0/1. Viz sekce Session Confirmed Fragmentation výše pro více informací.

+----+----+----+----+----+----+----+----+
  | 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

Poznámky:

• Router Info je volitelně komprimováno pomocí gzip, jak je indikováno příznakovým bitem 1. To se liší od NTCP2, kde není nikdy komprimováno, a od DatabaseStore zprávy, kde je vždy komprimováno. Komprese je volitelná, protože obvykle přináší malý užitek pro malé Router Info, kde je málo komprimovatelného obsahu, ale je velmi přínosná pro velké Router Info s několika komprimovatelnými Router Addresses. Komprese je doporučena, pokud umožňuje Router Info vejít se do jediného Session Confirmed paketu bez fragmentace.

• Maximální velikost prvního nebo jediného fragmentu ve zprávě Session Confirmed: MTU - 113 pro IPv4 nebo MTU - 133 pro IPv6. Za předpokladu výchozího MTU 1500 bajtů a žádných jiných bloků ve zprávě, 1387 pro IPv4 nebo 1367 pro IPv6. 97% aktuálních router infos je menších než 1367 bez gzipování. 99,9% aktuálních router infos je menších než 1367 při gzipování. Za předpokladu minimálního MTU 1280 bajtů a žádných jiných bloků ve zprávě, 1167 pro IPv4 nebo 1147 pro IPv6. 94% aktuálních router infos je menších než 1147 bez gzipování. 97% aktuálních router infos je menších než 1147 při gzipování.

• Frag byte je nyní nepoužívaný, blok Router Info není nikdy fragmentován. Frag byte musí být nastaven na fragment 0, celkem fragmentů 1. Více informací naleznete v sekci Session Confirmed Fragmentation výše.

• Flooding nesmí být vyžádán, pokud v RouterInfo nejsou publikované RouterAddresses. Přijímající router nesmí RouterInfo rozesílat (flood), pokud v něm nejsou publikované RouterAddresses.

• Tento protokol neposkytuje potvrzení, že RouterInfo byla uložena nebo rozšířena. Pokud je potvrzení žádoucí a příjemce je floodfill, odesílatel by měl místo toho poslat standardní I2NP DatabaseStoreMessage s reply tokenem.

I2NP Message

Kompletní I2NP zpráva s upravenou hlavičkou.

Používá stejných 9 bytů pro I2NP hlavičku jako v NTCP2 (typ, message id, krátké vypršení).

+----+----+----+----+----+----+----+----+
  | 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

Poznámky:

• Toto je stejný 9-bajtový formát hlavičky I2NP používaný v NTCP2.

• Toto je naprosto stejný formát jako blok První fragment, ale typ bloku označuje, že se jedná o úplnou zprávu.

• Maximální velikost včetně 9-bajtové I2NP hlavičky je MTU - 63 pro IPv4 a MTU - 83 pro IPv6.

ChaCha20/Poly1305

První fragment (fragment #0) I2NP zprávy s upraveným hlavičkovým polem.

Toto používá stejných 9 bytů pro I2NP hlavičku jako v NTCP2 (typ, id zprávy, krátká expirace).

Celkový počet fragmentů není specifikován.

+----+----+----+----+----+----+----+----+
  | 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)

Poznámky:

• Toto je stejný 9-bytový formát hlavičky I2NP používaný v NTCP2.

• Toto je přesně stejný formát jako blok I2NP Message, ale typ bloku označuje, že se jedná o první fragment zprávy.

• Délka částečné zprávy musí být větší než nula.

• Stejně jako v SSU 1 se doporučuje poslat poslední fragment jako první, aby příjemce znal celkový počet fragmentů a mohl efektivně alokovat přijímací buffery.

• Maximální velikost včetně 9-bajtové I2NP hlavičky je MTU - 63 pro IPv4 a MTU - 83 pro IPv6.

Poznámky

Dodatečný fragment (číslo fragmentu větší než nula) I2NP zprávy.

+----+----+----+----+----+----+----+----+
  | 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

Poznámky:

• Délka částečné zprávy musí být větší než nula.

• Stejně jako v SSU 1, je doporučeno poslat poslední fragment jako první, aby příjemce znal celkový počet fragmentů a mohl efektivně alokovat přijímací buffery.

• Stejně jako u SSU 1 je maximální číslo fragmentu 127, ale praktický limit je 63 nebo méně. Implementace mohou omezit maximum na to, co je praktické pro maximální velikost I2NP zprávy přibližně 64 KB, což je asi 55 fragmentů s minimální MTU 1280. Viz sekci Max I2NP Message Size níže.

• Maximální velikost částečné zprávy (nezahrnuje frag a message id) je MTU - 68 pro IPv4 a MTU - 88 pro IPv6.

Zpracování chyb AEAD

Ukončit připojení. Toto musí být poslední blok bez paddingu v datové části.

+----+----+----+----+----+----+----+----+
  | 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.

Poznámky:

• Nemusí být skutečně použity všechny důvody, závisí na implementaci. Většina selhání obecně povede k zahození zprávy, nikoli k ukončení. Viz poznámky v sekcích zpráv handshake výše. Dodatečné uvedené důvody slouží pro konzistenci, logování, ladění nebo v případě změn v politice.
• Doporučuje se, aby byl s blokem Termination zahrnut blok ACK.
• Ve fázi dat, z jakéhokoli jiného důvodu než “termination received”, by měl protějšek odpovědět blokem termination s důvodem “termination received”.

RelayRequest

Odesláno v Data zprávě v rámci relace, od Alice k Bobovi. Viz sekce Relay Process níže.

+----+----+----+----+----+----+----+----+
  |  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.

Poznámky:

• IP adresa je vždy zahrnuta (na rozdíl od SSU 1) a může se lišit od IP adresy používané pro relaci.

Podpis:

Alice podepíše požadavek a zahrne ho do tohoto bloku; Bob ho přepošle v bloku Relay Intro Charliemu. Algoritmus podpisu: Podepsat následující data podpisovým klíčem Alice’s routeru:

• prologue: 16 bajtů “RelayRequestData”, není ukončeno nulou (není zahrnuto ve zprávě)
• bhash: Bobův 32-bajtový hash routeru (není zahrnuto ve zprávě)
• chash: Charlieho 32-bajtový hash routeru (není zahrnuto ve zprávě)
• nonce: 4 bajtový nonce
• relay tag: 4 bajtový relay tag
• timestamp: 4 bajtový časový údaj (sekundy)
• ver: 1 bajt verze SSU
• asz: 1 bajt velikost koncového bodu (port + IP) (6 nebo 18)
• AlicePort: 2 bajty číslo portu Alice
• Alice IP: (asz - 2) bajt IP adresa Alice

KDF pro počáteční ChainKey

Odesláno v Data zprávě v rámci relace, od Charlie k Bobovi nebo od Boba k Alici, A TAKÉ ve zprávě Hole Punch od Charlie k Alici. Viz sekce Relay Process níže.

+----+----+----+----+----+----+----+----+
  |  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)

Poznámky:

Token musí být Alice okamžitě použit v Session Request.

Podpis:

Pokud Charlie souhlasí (kód odpovědi 0) nebo odmítá (kód odpovědi 64 nebo vyšší), Charlie podepíše odpověď a zahrne ji do tohoto bloku; Bob ji předá v bloku Relay Response Alici. Algoritmus podpisu: Podepsat následující data pomocí Charlie router signing key:

• prologue: 16 bajtů “RelayAgreementOK”, nezakončené nulovým bajtem (není zahrnuto ve zprávě)
• bhash: Bobův 32-bajtový router hash (není zahrnuto ve zprávě)
• nonce: 4-bajtový nonce
• timestamp: 4-bajtový časový údaj (sekundy)
• ver: 1-bajtová SSU verze
• csz: 1-bajtová velikost koncového bodu (port + IP) (0 nebo 6 nebo 18)
• CharliePort: 2-bajtové číslo Charlieho portu (není přítomno, pokud je csz 0)
• Charlie IP: (csz - 2) bajtová IP adresa Charlieho (není přítomna, pokud je csz 0)

Pokud Bob odmítne (kód odpovědi 1-63), Bob podepíše odpověď a zahrne ji do tohoto bloku. Algoritmus podpisu: Podepsat následující data pomocí Bobova router podpisového klíče:

• prologue: 16 bajtů “RelayAgreementOK”, neukončeno null (není zahrnuto ve zprávě)
• bhash: 32-bajtový router hash od Boba (není zahrnuto ve zprávě)
• nonce: 4-bajtové nonce
• timestamp: 4-bajtové časové razítko (sekundy)
• ver: 1 bajt SSU verze
• csz: 1 bajt = 0

KDF pro Session Request

Odesláno v Data zprávě v rámci relace, od Boba k Charliemu. Viz sekce Proces předávání níže.

Musí předcházet blok RouterInfo nebo blok I2NP DatabaseStore zprávy (nebo fragment) obsahující Router Info Alice, buď ve stejném payloadu (pokud je místo), nebo v předchozí zprávě.

+----+----+----+----+----+----+----+----+
  |  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.

Poznámky:

• Pro IPv4 je IP adresa Alice vždy 4 bajty, protože se Alice snaží připojit k Charlie přes IPv4. IPv6 je podporováno a IP adresa Alice může být 16 bajtů.

• Pro IPv4 musí být tato zpráva odeslána prostřednictvím navázaného IPv4 spojení, protože to je jediný způsob, jak Bob zná Charlie’s IPv4 adresu pro vrácení Alice v RelayResponse_. IPv6 je podporováno a tato zpráva může být odeslána prostřednictvím navázaného IPv6 spojení.

• Jakákoli SSU adresa publikovaná s introducery musí obsahovat “4” nebo “6” v možnosti “caps”.

Podpis:

Alice podepíše požadavek a Bob jej předá v tomto bloku Charliemu. Algoritmus ověření: Ověř následující data pomocí podpisového klíče Alice router:

• prologue: 16 bajtů “RelayRequestData”, nezakončené null (není zahrnuto ve zprávě)
• bhash: Bobův 32-bajtový hash routeru (není zahrnuto ve zprávě)
• chash: Charlieho 32-bajtový hash routeru (není zahrnuto ve zprávě)
• nonce: 4-bajtové nonce
• relay tag: 4-bajtový relay tag
• timestamp: 4-bajtové časové razítko (sekundy)
• ver: 1-bajtová verze SSU
• asz: 1-bajtová velikost koncového bodu (port + IP) (6 nebo 18)
• AlicePort: 2-bajtové číslo portu Alice
• Alice IP: (asz - 2) bajtová IP adresa Alice

PeerTest

Odesláno buď ve zprávě Data v rámci relace, nebo ve zprávě Peer Test mimo relaci. Viz sekce Proces Peer Test níže.

Pro zprávu 2 musí předcházet blok RouterInfo nebo blok I2NP DatabaseStore zprávy (nebo fragment) obsahující Router Info Alice, buď ve stejném payload (pokud je místo), nebo v předchozí zprávě.

Pro zprávu 4, pokud je relay přijato (kód důvodu 0), musí předcházet blok RouterInfo, nebo blok I2NP DatabaseStore zprávy (nebo fragment), obsahující Router Info uzlu Charlie, buď ve stejném payload (pokud je místo), nebo v předchozí zprávě.

+----+----+----+----+----+----+----+----+
  | 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.

Poznámky:

• Na rozdíl od SSU 1 musí zpráva 1 obsahovat IP adresu a port Alice.

• Testování IPv6 adres je podporováno, a komunikace Alice-Bob a Alice-Charlie může probíhat přes IPv6, pokud Bob a Charlie indikují podporu pomocí schopnosti ‘B’ ve své publikované IPv6 adrese. Podrobnosti viz Proposal 126.

Alice pošle požadavek Bobovi pomocí existující relace přes transport (IPv4 nebo IPv6), který chce testovat. Když Bob obdrží požadavek od Alice přes IPv4, Bob musí vybrat Charlieho, který inzeruje IPv4 adresu. Když Bob obdrží požadavek od Alice přes IPv6, Bob musí vybrat Charlieho, který inzeruje IPv6 adresu. Skutečná komunikace Bob-Charlie může být přes IPv4 nebo IPv6 (tj. nezávisle na typu adresy Alice).

• Zprávy 1-4 musí být obsaženy ve zprávě Data v existující relaci.

• Bob musí odeslat Alice RI Charliemu před odesláním zprávy 2.

• Bob musí poslat Charlie’s RI Alici před odesláním zprávy 4, pokud je přijata (kód důvodu 0).

• Zprávy 5-7 musí být obsaženy ve zprávě Peer Test mimo relaci.

• Zprávy 5 a 7 mohou obsahovat stejná podepsaná data jako byla odeslána ve zprávách 3 a 4, nebo mohou být regenerována s novým časovým razítkem. Podpis je volitelný.

• Zpráva 6 může obsahovat stejná podepsaná data jako byla odeslána ve zprávách 1 a 2, nebo mohou být regenerována s novým časovým razítkem. Podpis je volitelný.

Podpisy:

Alice podepíše požadavek a zahrne ho do zprávy 1; Bob ho přepošle ve zprávě 2 Charliemu. Charlie podepíše odpověď a zahrne ji do zprávy 3; Bob ji přepošle ve zprávě 4 Alice. Algoritmus podpisu: Podepsat nebo ověřit následující data pomocí podpisového klíče Alice nebo Charlieho:

• prologue: 16 bajtů “PeerTestValidate”, není ukončeno nulou (není zahrnuto ve zprávě)
• bhash: Bobův 32-bajtový hash routeru (není zahrnuto ve zprávě)
• ahash: Alicein 32-bajtový hash routeru (Použito pouze v podpisu pro zprávy 3 a 4; není zahrnuto ve zprávě 3 nebo 4)
• ver: 1 bajt verze SSU
• nonce: 4-bajtové testovací nonce
• timestamp: 4-bajtové časové razítko (sekundy)
• asz: 1 bajt velikosti koncového bodu (port + IP) (6 nebo 18)
• AlicePort: 2 bajty čísla portu Alice
• Alice IP: (asz - 2) bajtů IP adresy Alice

Payload

TODO pouze pokud rotujeme klíče

+----+----+----+----+----+----+----+----+
  | 11 |  size   |      TBD               |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 11
  size :: 2 bytes, big endian, size of data to follow

Poznámky

4 bajtové potvrzení průchodu, následované počtem potvrzení a nula nebo více rozsahů nack/ack.

Tento návrh je adaptován a zjednodušen z QUIC. Cíle návrhu jsou následující:

• Chceme efektivně zakódovat “bitové pole”, což je sekvence bitů reprezentující potvrzené pakety.
• Bitové pole je většinou tvořeno jedničkami. Jak jedničky, tak nuly obecně přicházejí v sekvenčních “shlucích”.
• Množství místa v paketu dostupné pro potvrzení se liší.
• Nejdůležitější bit je ten s nejvyšším číslem. Ty s nižšími čísly jsou méně důležité. Pod určitou vzdáleností od nejvyššího bitu budou nejstarší bity “zapomenuty” a nikdy znovu odeslány.

Kódování specifikované níže dosahuje těchto návrhových cílů tím, že posílá číslo nejvyššího bitu, který je nastaven na 1, společně s dalšími po sobě následujícími bity níže, které jsou také nastaveny na 1. Poté, pokud je místo, jeden nebo více “rozsahů” specifikujících počet po sobě následujících 0 bitů a po sobě následujících 1 bitů níže. Viz QUIC RFC 9000 sekce 13.2.3 pro více informací.

+----+----+----+----+----+----+----+----+
  | 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

Příklady:

Chceme potvrdit ACK pouze paket 10:

• Ack Through: 10
• acnt: 0
• žádné rozsahy nejsou zahrnuty

Chceme potvrdit pouze pakety 8-10:

• Ack Through: 10
• acnt: 2
• nejsou zahrnuty žádné rozsahy

Chceme ACK 10 9 8 6 5 2 1 0 a NACK 7 4 3. Kódování ACK bloku je:

• 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)

Poznámky:

• Rozsahy nemusí být přítomny. Maximální počet rozsahů není specifikován, může jich být tolik, kolik se vejde do paketu.
• Range nack může být nula při potvrzování více než 255 po sobě jdoucích paketů.
• Range ack může být nula při zamítání více než 255 po sobě jdoucích paketů.
• Range nack a ack nemohou být oba nulové.
• Po posledním rozsahu nejsou pakety ani potvrzeny ani zamítnuty. Délka bloku ack a způsob nakládání se starými ack/nack závisí na odesílateli bloku ack. Viz diskuse v sekcích ack níže.
• Hodnota ack through by měla být nejvyšší číslo přijatého paketu a jakékoli pakety s vyšším číslem nebyly přijaty. V omezených situacích však může být nižší, například při potvrzení jediného paketu, který “vyplní díru”, nebo zjednodušené implementace, která neudržuje stav všech přijatých paketů. Nad nejvyšším přijatým nejsou pakety ani potvrzeny ani zamítnuty, ale po několika blocích ack může být vhodné přejít do režimu rychlého opětovného odeslání.
• Tento formát je zjednodušená verze toho z QUIC. Je navržen k efektivnímu kódování velkého počtu ACK společně s shlukováním NACK.
• Bloky ACK se používají k potvrzení paketů datové fáze. Mají být zahrnuty pouze pro pakety datové fáze v rámci relace.

Address

2 bajtový port a 4 nebo 16 bajtová IP adresa. Alicina adresa, poslaná Alici od Boba, nebo Bobova adresa, poslaná Bobovi od Alice.

+----+----+----+----+----+----+----+----+
  | 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

Toto může být zasláno Alice v Session Request, Session Confirmed nebo Data zprávě. Není podporováno ve zprávě Session Created, protože Bob ještě nemá Alice RI a neví, zda Alice podporuje relay. Také pokud Bob dostává příchozí spojení, pravděpodobně nepotřebuje introducery (kromě možná pro druhý typ ipv4/ipv6).

Když je odeslán v Session Request, Bob může odpovědět s Relay Tag ve zprávě Session Created, nebo se může rozhodnout počkat na přijetí Alice RouterInfo v Session Confirmed k ověření Alice identity před odpovědí ve zprávě Data. Pokud Bob nechce pro Alice relay fungovat, neodešle blok Relay Tag.

+----+----+----+
  | 15 |    0    |
  +----+----+----+

  blk :: 15
  size :: 2 bytes, big endian, value = 0

Užitečné zatížení

Toto může být odesláno Bobem ve zprávě Session Confirmed nebo Data, jako odpověď na Relay Tag Request od Alice.

Když je Relay Tag Request odeslán v Session Request, Bob může odpovědět s Relay Tag ve zprávě Session Created, nebo se může rozhodnout počkat na přijetí Alice RouterInfo v Session Confirmed pro ověření Alice identity před odpovědí v Data zprávě. Pokud Bob nechce pro Alice relay provozovat, neposílá Relay Tag blok.

+----+----+----+----+----+----+----+
  | 16 |    4    |    relay tag      |
  +----+----+----+----+----+----+----+

  blk :: 16
  size :: 2 bytes, big endian, value = 4
  relay tag :: 4 bytes, big endian, nonzero

Poznámky

Pro následné připojení. Obecně je obsažen ve zprávách Session Created a Session Confirmed. Může být také odeslán znovu ve zprávě Data u dlouhodobé relace, pokud platnost předchozího tokenu vyprší.

+----+----+----+----+----+----+----+----+
  | 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

Problémy

Ping s libovolnými daty, která mají být vrácena v Path Response, používaný jako keep-alive nebo k ověření změny IP/portu.

+----+----+----+----+----+----+----+----+
  | 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

Poznámky:

Doporučuje se, ale není vyžadována, minimální velikost dat 8 bajtů obsahující náhodná data.

Path Response

Pong s daty obdrženými v Path Challenge, jako odpověď na Path Challenge, používaný jako keep-alive nebo k ověření změny IP/portu.

+----+----+----+----+----+----+----+----+
  | 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

Volitelně zahrnuto v handshaku v každém směru, pro specifikaci čísla prvního paketu, který bude odeslán. To poskytuje větší bezpečnost pro šifrování hlavičky, podobně jako TCP.

Není plně specifikováno, momentálně není podporováno.

+----+----+----+----+----+----+----+
  | 20 |  size   |  First pkt number |
  +----+----+----+----+----+----+----+

  blk :: 20
  size :: 4
  pkt num :: The first packet number to be sent in the data phase

Congestion

Tento blok je navržen jako rozšiřitelná metoda pro výměnu informací o řízení zahlcení. Řízení zahlcení může být složité a může se vyvíjet, jak získáváme více zkušeností s protokolem v živém testování nebo po úplném nasazení.

To udržuje jakékoliv informace o přetížení mimo vysoce využívané I2NP, First Fragment, Followon Fragment a ACK bloky, kde není alokován žádný prostor pro příznaky. Zatímco v hlavičce Data paketu jsou tři bajty nevyužitých příznaků, to také poskytuje omezený prostor pro rozšiřitelnost a slabší ochranu šifrováním.

Ačkoli je poněkud plýtvavé používat 4-bajtový blok pro dva bity informace, umístěním do samostatného bloku jej můžeme snadno rozšířit o další data, jako jsou aktuální velikosti oken, naměřené RTT nebo další příznaky. Zkušenosti ukázaly, že samotné bity příznaků jsou často nedostatečné a neohrabané pro implementaci pokročilých schémat řízení přetížení. Pokus o přidání podpory pro jakoukoliv možnou funkci řízení přetížení například do ACK bloku by plýtval místem a přidal složitost k parsování tohoto bloku.

Implementace by neměly předpokládat, že druhý router podporuje jakýkoli konkrétní flag bit nebo funkci zde uvedenou, pokud implementace není vyžadována budoucí verzí této specifikace.

Tento blok by pravděpodobně měl být posledním blokem (kromě padding bloků) v payload.

+----+----+----+----+
  | 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

Datová část

Toto je pro padding uvnitř AEAD payloadů. Padding pro všechny zprávy jsou uvnitř AEAD payloadů.

Padding by měl zhruba dodržovat vyjednané parametry. Bob poslal své požadované tx/rx min/max parametry v Session Created. Alice poslala své požadované tx/rx min/max parametry v Session Confirmed. Aktualizované možnosti mohou být odeslány během datové fáze. Viz informace o bloku možností výše.

Pokud je přítomen, musí být tento blok posledním v payload.

+----+----+----+----+----+----+----+----+
  |254 |  size   |      padding           |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 254
  size :: 2 bytes, big endian, size of padding to follow
  padding :: random data

Poznámky:

• Velikost = 0 je povolena.

• Strategie paddingu TBD.

• Minimální padding TBD.

• Payloady obsahující pouze padding jsou povoleny.

• Výchozí hodnoty paddingu TBD.

• Viz options blok pro vyjednávání parametrů paddingu

• Viz options blok pro min/max parametry paddingu

• Nepřekračujte MTU. Pokud je potřeba více paddingu, pošlete několik zpráv.

• Odpověď routeru na porušení vyjednaného paddingu závisí na implementaci.

• Délka paddingu má být buď rozhodována na základě jednotlivých zpráv a odhadů distribuce délky, nebo mají být přidána náhodná zpoždění. Tato protiopatření mají být zahrnuta pro odolání proti DPI, jelikož velikosti zpráv by jinak prozradily, že I2P provoz je přenášen transportním protokolem. Přesné schéma paddingu je oblastí budoucí práce, Příloha A dokumentu NTCP2 poskytuje více informací k tomuto tématu.

Replay Prevention

SSU2 je navrženo tak, aby minimalizovalo dopad zpráv znovu přehrávaných útočníkem.

Zprávy Token Request, Retry, Session Request, Session Created, Hole Punch a out-of-session Peer Test musí obsahovat bloky DateTime.

Jak Alice, tak Bob ověří, že čas těchto zpráv je v rámci platné odchylky (doporučeno +/- 2 minuty). Pro “odolnost proti sondování” by Bob neměl odpovídat na zprávy Token Request nebo Session Request, pokud je odchylka neplatná, protože tyto zprávy mohou být útokem typu replay nebo sondovacím útokem.

Bob může zvolit odmítnutí duplicitních zpráv Token Request a Retry, i když je skew platný, pomocí Bloom filtru nebo jiného mechanismu. Avšak velikost a CPU náklady na odpovědi na tyto zprávy jsou nízké. V nejhorším případě může přehraná zpráva Token Request zneplatnit dříve odeslaný token.

Systém tokenů výrazně minimalizuje dopad opakovaných zpráv Session Request. Protože tokeny mohou být použity pouze jednou, opakovaná zpráva Session Request nikdy nebude mít platný token. Bob se může rozhodnout odmítnout duplicitní zprávy Session Request, i když je skew platný, prostřednictvím Bloom filteru nebo jiného mechanismu. Nicméně velikost a náklady na CPU při odpovědi zprávou Retry jsou nízké. V nejhorším případě může odeslání zprávy Retry zneplatnit dříve odeslaný token.

Duplikátní zprávy Session Created a Session Confirmed nebudou validovány, protože stav Noise handshake nebude ve správném stavu pro jejich dešifrování. V nejhorším případě může peer znovu odeslat Session Confirmed jako odpověď na zdánlivě duplikátní Session Created.

Opakované zprávy Hole Punch a Peer Test by měly mít malý nebo žádný dopad.

Routery musí použít číslo paketu datové zprávy k detekci a zahození duplicitních zpráv datové fáze. Každé číslo paketu by mělo být použito pouze jednou. Opakované zprávy musí být ignorovány.

Handshake Retransmission

Session Request

Pokud Alice neobdrží žádnou Session Created nebo Retry:

Udržujte stejné zdrojové a připojovací ID, dočasný klíč a číslo paketu 0. Nebo jednoduše podržte a znovu přeneste stejný šifrovaný paket. Číslo paketu nesmí být zvýšeno, protože by to změnilo hodnotu zřetězeného hash použitého k šifrování zprávy Session Created.

Doporučené intervaly pro opětovné odeslání: 1,25, 2,5 a 5 sekund (1,25, 3,75 a 8,75 sekund po prvním odeslání). Doporučený timeout: celkem 15 sekund

Session Created

Pokud Bob neobdrží žádné Session Confirmed:

Udržujte stejné zdrojové a připojovací ID, dočasný klíč a číslo paketu 0. Nebo jednoduše ponechte zašifrovaný paket. Číslo paketu nesmí být zvýšeno, protože by to změnilo hodnotu zřetězeného hashe používaného k šifrování zprávy Session Confirmed.

Doporučené intervaly pro opětovné odeslání: 1, 2 a 4 sekundy (1, 3 a 7 sekund po prvním odeslání). Doporučený timeout: celkem 12 sekund

Session Confirmed

V SSU 1 Alice nepřechází do fáze dat, dokud neobdrží první datový paket od Boba. To činí z SSU 1 nastavení se dvěma zpáteční cestami.

Pro SSU 2, Doporučené intervaly pro opětovné odeslání Session Confirmed: 1,25, 2,5 a 5 sekund (1,25, 3,75 a 8,75 sekund po prvním odeslání).

Existuje několik alternativ. Všechny jsou 1 RTT:

1. Alice předpokládá, že Session Confirmed bylo přijato, posílá datové zprávy okamžitě, nikdy znovu nepřenáší Session Confirmed. Datové pakety přijaté mimo pořadí (před Session Confirmed) budou nešifrovatelné, ale budou znovu přeneseny. Pokud se Session Confirmed ztratí, všechny odeslané datové zprávy budou zahozeny.

2. Stejně jako v 1), odesílej datové zprávy okamžitě, ale také znovu přenášej Session Confirmed, dokud není přijata datová zpráva.

3. Mohli bychom použít IK místo XK, protože má pouze dvě zprávy v handshake, ale používá dodatečný DH (4 místo 3).

Doporučená implementace je možnost 2). Alice si musí uchovat informace potřebné k opětovnému odeslání zprávy Session Confirmed. Alice by také měla opětovně odeslat všechny Data zprávy poté, co je zpráva Session Confirmed opětovně odeslána.

Při retransmisi Session Confirmed udržujte stejná zdrojová a connection ID, ephemeral key a číslo packetu 1. Nebo jednoduše zachovejte šifrovaný packet. Číslo packetu nesmí být zvýšeno, protože by to změnilo hodnotu chained hash, která je vstupem pro funkci split().

Bob může zadržet (zařadit do fronty) datové zprávy přijaté před zprávou Session Confirmed. Ani klíče pro ochranu hlaviček ani dešifrovací klíče nejsou dostupné před přijetím zprávy Session Confirmed, takže Bob neví, že se jedná o datové zprávy, ale může to předpokládat. Po přijetí zprávy Session Confirmed je Bob schopen dešifrovat a zpracovat zařazené datové zprávy. Pokud je to příliš složité, Bob může jednoduše zahodit nedešifrovatelné datové zprávy, protože je Alice znovu odešle.

Poznámka: Pokud se pakety session confirmed ztratí, Bob znovu odešle session created. Hlavička session created nebude dešifrovatelná s intro klíčem Alice, protože je nastavena s intro klíčem Boba (pokud není provedeno záložní dešifrování s intro klíčem Boba). Bob může okamžitě znovu odeslat pakety session confirmed, pokud nebyly dříve potvrzeny, a je přijat nedešifrovatelný paket.

Token Request

Pokud Alice neobdrží žádný Retry:

Udržujte stejné ID zdroje a spojení. Implementace může vygenerovat nové náhodné číslo paketu a zašifrovat nový paket; Nebo může znovu použít stejné číslo paketu nebo pouze zachovat a znovu přenést stejný zašifrovaný paket. Číslo paketu nesmí být zvýšeno, protože by to změnilo hodnotu zřetězeného hashe používanou k šifrování zprávy Session Created.

Doporučené intervaly pro opětovné odeslání: 3 a 6 sekund (3 a 9 sekund po prvním odeslání). Doporučený timeout: celkem 15 sekund

Retry

Pokud Bob neobdrží žádný Session Request:

Zpráva Retry není při vypršení timeoutu přeposílána, aby se snížily dopady falšovaných zdrojových adres.

Nicméně zpráva Retry může být znovu odeslána v reakci na opakovanou zprávu Session Request přijatou s původním (neplatným) tokenem, nebo v reakci na opakovanou zprávu Token Request. V obou případech to naznačuje, že zpráva Retry byla ztracena.

Pokud je přijata druhá zpráva Session Request s odlišným, ale stále neplatným tokenem, zrušte čekající relaci a neodpovídejte.

Při opětovném odesílání zprávy Retry: Zachovejte stejné zdrojové ID a ID připojení a token. Implementace může vygenerovat nové náhodné číslo paketu a zašifrovat nový paket; nebo může znovu použít stejné číslo paketu nebo pouze zachovat a znovu odeslat stejný zašifrovaný paket.

Total Timeout

Doporučený celkový timeout pro handshake je 20 sekund.

Duplicates and Error Handling

Duplikáty tří Noise handshake zpráv Session Request, Session Created a Session Confirmed musí být detekovány před MixHash() hlavičky. Zatímco Noise AEAD zpracování pravděpodobně po tom selže, handshake hash by již byl poškozen.

Pokud je některá ze tří zpráv poškozena a selže AEAD, handshake již nelze následně obnovit ani při opětovném přenosu, protože MixHash() byla již zavolána na poškozenou zprávu.

Tokens

Token v hlavičce Session Request se používá pro zmírnění DoS útoků, k zabránění falšování zdrojové adresy a jako ochrana proti replay útokům.

Pokud Bob nepřijme token ve zprávě Session Request, Bob NErozšifruje zprávu, protože by to vyžadovalo nákladnou DH operaci. Bob jednoduše pošle zprávu Retry s novým tokenem.

Pokud je následně přijata zpráva Session Request s tímto tokenem, Bob pokračuje v dešifrování této zprávy a pokračuje v handshaku.

Token musí být náhodně generovaná 8bajtová hodnota, pokud generátor tokenu ukládá tyto hodnoty a přidružené IP a port (v paměti nebo perzistentně). Generátor nesmí generovat neprůhlednou hodnotu, například pomocí SipHash (s tajným seedem K0, K1) IP, portu a aktuální hodiny nebo dne, pro vytvoření tokenů, které není nutné ukládat v paměti, protože tato metoda ztěžuje odmítání znovu použitých tokenů a replay útoků.

Tokeny mohou být použity pouze jednou. Token odeslaný od Boba k Alici ve zprávě Retry musí být použit okamžitě a vyprší během několika sekund. Token odeslaný v bloku New Token ve vytvořeném session může být použit v následujícím připojení a vyprší v čase určeném v daném bloku. Vypršení je specifikováno odesílatelem; doporučené hodnoty jsou minimálně jedna hodina, maximálně několik hodin.

Pokud se změní IP adresa nebo port routeru, musí smazat všechny uložené tokeny (jak příchozí, tak odchozí) pro starou IP adresu nebo port, protože již nejsou platné. Tokeny mohou být volitelně zachovány při restartování routeru, závisí to na implementaci. Přijetí nevypršelého tokenu není zaručeno; pokud Bob zapomněl nebo smazal své uložené tokeny, pošle Alice zprávu Retry. Router se může rozhodnout omezit ukládání tokenů a odstranit nejstarší uložené tokeny, i když ještě nevypršely.

Nové Token bloky mohou být posílány z Alice k Bobovi nebo z Boba k Alice. Obvykle by byly poslány jednou, během nebo brzy po navázání relace. Token může být znovu odeslán před nebo po vypršení s novým časem vypršení, nebo může být poslán nový token. Routery by měly předpokládat, že pouze poslední přijatý token je platný; neexistuje požadavek ukládat více příchozích nebo odchozích tokenů pro stejnou IP/port.

Token je vázán na kombinaci zdrojové IP/portu a cílové IP/portu. Token přijatý na IPv4 nesmí být použit pro IPv6 nebo naopak.

Pokud se kterýkoli peer během relace migruje na novou IP nebo port (viz sekce Connection Migration), všechny dříve vyměněné tokeny jsou zneplatněny a musí být vyměněny nové tokeny.

Implementace mohou, ale nejsou povinny, ukládat tokeny na disk a znovu je načítat při restartu. Pokud jsou zachovány, implementace musí zajistit, že se IP adresa a port nezměnily od vypnutí před jejich opětovným načtením.

I2NP Message Fragmentation

Rozdíly od SSU 1

Poznámka: Stejně jako u SSU 1, počáteční fragment neobsahuje informace o celkovém počtu fragmentů nebo celkové délce. Následující fragmenty neobsahují informace o svém posunu. To poskytuje odesílateli flexibilitu fragmentovat „za běhu" na základě dostupného místa v paketu. (Java I2P toto nedělá; „předem fragmentuje" před odesláním prvního fragmentu) Nicméně to zatěžuje příjemce nutností ukládat fragmenty přijaté mimo pořadí a odkládat opětovné sestavení, dokud nebudou přijaty všechny fragmenty.

Stejně jako v SSU 1, jakékoli znovu odeslání fragmentů musí zachovat délku (a implicitní offset) předchozího přenosu fragmentu.

SSU 2 odděluje tyto tři případy (celá zpráva, počáteční fragment a následující fragment) do tří různých typů bloků za účelem zlepšení efektivity zpracování.

I2NP Message Duplication

Tento protokol ZCELA nezabraňuje duplicitnímu doručování I2NP zpráv. Duplikáty na IP vrstvě nebo útoky typu replay budou detekovány na SSU2 vrstvě, protože každé číslo paketu může být použito pouze jednou.

Když jsou však I2NP zprávy nebo fragmenty retransmitovány v nových paketech, toto není detekovatelné na úrovni SSU2. Router by měl vynucovat vypršení platnosti I2NP (jak příliš staré, tak příliš daleko v budoucnosti) a používat Bloomův filtr nebo jiný mechanismus založený na ID I2NP zprávy.

Router nebo implementace SSU2 mohou používat další mechanismy pro detekci duplikátů. Například SSU2 může udržovat cache nedávno přijatých ID zpráv. Toto je závislé na implementaci.

Congestion Control

Tento návrh specifikuje protokol pro číslování paketů a ACK bloky. To poskytuje dostatečné informace v reálném čase pro odesílatele k implementaci efektivního a responzivního algoritmu řízení zahlcení, zatímco umožňuje flexibilitu a inovace v této implementaci. Tato sekce diskutuje implementační cíle a poskytuje návrhy. Obecné pokyny lze nalézt v RFC 9002. Viz také RFC 6298 pro pokyny ohledně časovačů opětovného přenosu.

ACK-only datové pakety by se neměly počítat pro bajty nebo pakety v přenosu a nepodléhají řízení zahlcení. Na rozdíl od TCP může SSU2 detekovat ztrátu těchto paketů a tato informace může být použita k úpravě stavu zahlcení. Tento dokument však nespecifikuje mechanismus pro takový postup.

Pakety obsahující některé další nedatové bloky mohou být také vyloučeny z řízení zahlcení podle potřeby, závislé na implementaci. Například:

• Peer Test
• Relay request/intro/response
• Path challenge/response

Doporučuje se, aby řízení přetížení bylo založeno na počtu bytů, nikoliv na počtu paketů, podle pokynů v TCP RFC a QUIC RFC 9002. Další limit počtu paketů může být také užitečný pro předcházení přetečení bufferu v jádře nebo v middleboxech, závisí na implementaci, ačkoli to může přidat významnou složitost. Pokud je výstup paketů pro jednotlivé relace a/nebo celkový omezen šířkou pásma a/nebo řízen tempem, může to zmírnit potřebu omezování počtu paketů.

Packet Numbers

V SSU 1 obsahovaly ACK a NACK čísla I2NP zpráv a bitové masky fragmentů. Vysílače sledovaly stav ACK odchozích zpráv (a jejich fragmentů) a podle potřeby znovu přenášely fragmenty.

V SSU 2 obsahují ACK a NACK čísla paketů. Odesílatelé musí udržovat datovou strukturu s mapováním čísel paketů na jejich obsah. Když je paket potvrzen ACK nebo odmítnut NACK, odesílatel musí určit, které I2NP zprávy a fragmenty byly v daném paketu, aby rozhodl, co znovu odeslat.

Session Confirmed ACK

Bob odešle ACK paketu 0, které potvrzuje zprávu Session Confirmed a umožňuje Alici pokračovat do datové fáze a zahodit velkou zprávu Session Confirmed uloženou pro možnou retransmisi. Toto nahrazuje DeliveryStatusMessage odeslanou Bobem v SSU 1.

Bob by měl odeslat ACK co nejdříve po obdržení zprávy Session Confirmed. Malé zpoždění (ne více než 50 ms) je přijatelné, protože alespoň jedna Data zpráva by měla dorazit téměř okamžitě po zprávě Session Confirmed, takže ACK může potvrdit jak Session Confirmed, tak Data zprávu. Tím se zabrání tomu, aby Bob musel znovu přenést zprávu Session Confirmed.

Generating ACKs

Definice: Pakety vyžadující potvrzení (Ack-eliciting packets): Pakety, které obsahují bloky vyžadující potvrzení, vyžadují od příjemce ACK do maximálního zpoždění potvrzení a nazývají se pakety vyžadující potvrzení (ack-eliciting packets).

Routery potvrzují všechny pakety, které přijmou a zpracují. Nicméně pouze pakety vyžadující potvrzení způsobí odeslání ACK bloku v rámci maximálního zpoždění potvrzení. Pakety, které nevyžadují potvrzení, jsou potvrzovány pouze tehdy, když je ACK blok odeslán z jiných důvodů.

Při odesílání paketu z jakéhokoli důvodu by se endpoint měl pokusit zahrnout ACK blok, pokud nebyl odeslán v nedávné době. Tím se pomáhá včasnému odhalení ztráty u protější strany.

Obecně platí, že častá zpětná vazba od příjemce zlepšuje odezvu na ztráty a zahlcení, ale to je třeba vyvážit proti nadměrné zátěži generované příjemcem, který posílá ACK blok v reakci na každý packet vyžadující potvrzení. Níže uvedené pokyny se snaží najít tuto rovnováhu.

Datové pakety v rámci relace obsahující jakýkoliv blok KROMĚ následujících vyvolávají potvrzení (ack):

• ACK blok
• Address blok
• DateTime blok
• Padding blok
• Termination blok
• Jakékoliv bloky ve stejném paketu jako Termination blok
• Další?

Pakety obsahující blok Termination s důvodem jiným než „termination received" jsou potvrzovány paketem obsahujícím blok Termination s „termination received".

Pakety mimo relaci, včetně handshake zpráv a zpráv peer test 5-7, mají své vlastní mechanismy potvrzování. Viz níže.

Handshake ACKs

Jedná se o zvláštní případy:

• Token Request je implicitně potvrzena pomocí Retry
• Session Request je implicitně potvrzena pomocí Session Created nebo Retry
• Retry je implicitně potvrzena pomocí Session Request
• Session Created je implicitně potvrzena pomocí Session Confirmed
• Session Confirmed by měla být potvrzena okamžitě

Sending ACK Blocks

ACK bloky se používají k potvrzení paketů datové fáze. Mají být zahrnuty pouze pro pakety datové fáze v rámci relace.

Každý paket by měl být potvrzen alespoň jednou a pakety vyžadující potvrzení musí být potvrzeny alespoň jednou v rámci maximálního zpoždění.

Koncový bod musí okamžitě potvrdit všechny pakety handshake vyžadující potvrzení v rámci svého maximálního zpoždění, s následující výjimkou. Před potvrzením handshake nemusí mít koncový bod šifrovací klíče záhlaví paketů pro dešifrování paketů při jejich přijetí. Může je proto ukládat do vyrovnávací paměti a potvrdit je, když budou k dispozici potřebné klíče.

Protože pakety obsahující pouze ACK bloky nejsou řízeny z hlediska přetížení, endpoint nesmí odeslat více než jeden takový paket v reakci na přijetí paketu vyvolávajícího potvrzení.

Koncový bod nesmí poslat paket nevyžadující potvrzení jako odpověď na paket nevyžadující potvrzení, a to ani v případě, že před přijatým paketem existují mezery v paketech. Tím se zabrání nekonečné smyčce zpětné vazby potvrzení, která by mohla zabránit tomu, aby se spojení kdy stalo nečinným. Pakety nevyžadující potvrzení jsou nakonec potvrzeny, když koncový bod pošle ACK blok jako odpověď na jiné události.

Koncový bod, který pouze odesílá ACK bloky, neobdrží potvrzení od svého partnera, pokud tato potvrzení nejsou zahrnuta v paketech s bloky vyžadujícími potvrzení. Koncový bod by měl odeslat ACK blok s ostatními bloky, když jsou k dispozici nové pakety vyžadující potvrzení k potvrzení. Když je třeba potvrdit pouze pakety nevyžadující potvrzení, koncový bod MŮŽE zvolit neodesílání ACK bloku s odchozími bloky, dokud nebyl přijat paket vyžadující potvrzení.

Koncový bod, který pouze odesílá pakety nevyžadující potvrzení, si může příležitostně zvolit přidání bloku vyžadujícího potvrzení do těchto paketů, aby zajistil, že obdrží potvrzení. V takovém případě NESMÍ koncový bod odeslat blok vyžadující potvrzení ve všech paketech, které by jinak nevyžadovaly potvrzení, aby se předešlo nekonečné zpětnovazebnému cyklu potvrzení.

Aby pomohl detekci ztrát u odesílatele, měl by koncový bod generovat a odesílat ACK blok bez zpoždění, když obdrží ack-eliciting paket v kterémkoli z těchto případů:

• Když přijatý paket má číslo paketu menší než jiný paket vyžadující potvrzení, který byl přijat

• Když má paket číslo paketu vyšší než nejvyšší číslovaný packet vyvolávający potvrzení, který byl přijat, a existují chybějící pakety mezi tímto paketem a uvedeným paketem.

• Když je v hlavičce paketu nastaven příznak ack-immediate

Algoritmy jsou navrženy tak, aby byly odolné vůči příjemcům, kteří nedodržují výše uvedené pokyny. Implementace by se však měla od těchto požadavků odchýlit pouze po pečlivém zvážení dopadů změny na výkon, a to jak pro připojení vytvořená koncovým bodem, tak pro ostatní uživatele sítě.

ACK Frequency

Příjemce určuje, jak často odesílat potvrzení v odpovědi na pakety vyžadující potvrzení. Toto rozhodnutí zahrnuje kompromis.

Koncové body spoléhají na včasné potvrzování pro detekci ztráty. Regulátory přetížení založené na okně spoléhají na potvrzování pro správu svého okna přetížení. V obou případech může zpožďování potvrzování negativně ovlivnit výkon.

Na druhou stranu snížení frekvence paketů, které nesou pouze potvrzení, snižuje náklady na přenos a zpracování paketů na obou koncových bodech. Může zlepšit propustnost spojení na silně asymetrických linkách a snížit objem potvrzovacího provozu využívajícího kapacitu zpětné cesty; viz sekce 3 RFC 3449.

Příjemce by měl odeslat ACK blok po přijetí nejméně dvou paketů vyžadujících potvrzení. Toto doporučení je obecné povahy a je v souladu s doporučeními pro chování TCP koncových bodů RFC 5681. Znalost síťových podmínek, znalost řadiče zahlcení partnera nebo další výzkum a experimenty mohou navrhnout alternativní strategie potvrzování s lepšími výkonnostními charakteristikami.

Příjemce může zpracovat více dostupných paketů, než se rozhodne, zda má v reakci odeslat ACK blok. Obecně by příjemce neměl zpozdit ACK o více než RTT / 6, nebo maximálně 150 ms.

Flag ack-immediate v hlavičce datového paketu je požadavek, aby příjemce odeslal potvrzení brzy po přijetí, pravděpodobně během několika ms. Obecně by příjemce neměl zpozdit okamžité ACK o více než RTT / 16, nebo maximálně 5 ms.

Immediate ACK Flag

Příjemce nezná velikost odesílacího okna odesílatele, a proto neví, jak dlouho má čekat před odesláním ACK. Příznak okamžitého ACK v hlavičce datového paketu je důležitým způsobem, jak udržet maximální propustnost minimalizací efektivního RTT. Příznak okamžitého ACK je bajt 13 hlavičky, bit 0, tj. (header[13] & 0x01). Když je nastaven, je požadován okamžitý ACK. Podrobnosti najdete v sekci krátké hlavičky výše.

Existuje několik možných strategií, které může odesílatel použít k určení, kdy nastavit příznak immediate-ack:

• Nastaveno jednou za každých N paketů, pro nějaké malé N
• Nastaveno na posledním v sérii paketů
• Nastaveno kdykoli je okno odesílání téměř plné, například více než 2/3 plné
• Nastaveno na všech paketech s retransmitovanými fragmenty

Příznaky okamžitého ACK by měly být nutné pouze u datových paketů obsahujících I2NP zprávy nebo fragmenty zpráv.

ACK Block Size

Když je odeslán ACK blok, je zahrnuto jedno nebo více rozsahů potvrzených paketů. Zahrnutí potvrzení pro starší pakety snižuje pravděpodobnost falešných retransmisí způsobených ztrátou dříve odeslaných ACK bloků, za cenu větších ACK bloků.

ACK bloky by měly vždy potvrzovat nejnověji přijaté pakety, a čím více jsou pakety mimo pořadí, tím důležitější je rychle odeslat aktualizovaný ACK blok, aby se zabránilo tomu, že protistrana prohlásí paket za ztracený a zbytečně znovu přenese bloky, které obsahuje. ACK blok se musí vejít do jediného paketu. Pokud se nevejde, pak jsou starší rozsahy (ty s nejmenšími čísly paketů) vynechány.

Příjemce omezuje počet ACK rozsahů, které si pamatuje a posílá v ACK blocích, a to jak pro omezení velikosti ACK bloků, tak pro zabránění vyčerpání zdrojů. Po obdržení potvrzení pro ACK blok by příjemce měl přestat sledovat tyto potvrzené ACK rozsahy. Odesílatelé mohou očekávat potvrzení pro většinu paketů, ale tento protokol nezaručuje obdržení potvrzení pro každý paket, který příjemce zpracuje.

Je možné, že uchovávání mnoha ACK rozsahů by mohlo způsobit, že ACK blok se stane příliš velkým. Příjemce může zahodit nepotvrzené ACK rozsahy, aby omezil velikost ACK bloku, za cenu zvýšených retransmisí od odesílatele. To je nezbytné, pokud by ACK blok byl příliš velký na to, aby se vešel do paketu. Příjemci mohou také dále omezovat velikost ACK bloku, aby zachovali místo pro jiné bloky nebo aby omezili šířku pásma, kterou potvrzení spotřebovávají.

Příjemce musí zachovat rozsah ACK, dokud nemůže zajistit, že následně nepřijme pakety s čísly v tomto rozsahu. Udržování minimálního čísla paketu, které se zvyšuje při zahazování rozsahů, je jedním ze způsobů, jak toho dosáhnout s minimálním stavem.

Příjemci mohou zahodit všechny ACK rozsahy, ale musí si ponechat největší číslo paketu, které bylo úspěšně zpracováno, protože se používá k obnovení čísel paketů z následujících paketů.

Následující sekce popisuje příkladný přístup pro určení, které pakety potvrdit v každém ACK bloku. Ačkoliv cílem tohoto algoritmu je vygenerovat potvrzení pro každý paket, který je zpracován, je stále možné, že potvrzení budou ztracena.

Limiting Ranges by Tracking ACK Blocks

Když je odeslán paket obsahující ACK blok, může být pole Ack Through v tomto bloku uloženo. Když je paket obsahující ACK blok potvrzen, příjemce může přestat potvrzovat pakety menší nebo rovné poli Ack Through v odeslaném ACK bloku.

Přijímač, který odesílá pouze pakety nevyžadující potvrzení, jako jsou ACK bloky, nemusí dlouhou dobu obdržet potvrzení. To by mohlo způsobit, že si přijímač bude udržovat stav pro velký počet ACK bloků po dlouhou dobu, a ACK bloky, které odesílá, by mohly být zbytečně velké. V takovém případě by přijímač mohl občas odeslat PING nebo jiný malý blok vyžadující potvrzení, například jednou za round trip, aby vyvolal ACK od protějšku.

V případech bez ztráty ACK bloku tento algoritmus umožňuje minimálně 1 RTT přeuspořádání. V případech se ztrátou ACK bloku a přeuspořádáním tento přístup nezaručuje, že každé potvrzení bude odesílatelem viděno dříve, než již nebude zahrnuto v ACK bloku. Pakety mohou být přijaty v nesprávném pořadí a všechny následující ACK bloky je obsahující mohou být ztraceny. V tomto případě může algoritmus obnovy po ztrátě způsobit falešné retransmise, ale odesílatel bude pokračovat v postupu vpřed.

Congestion

I2P transporty nezaručují doručení I2NP zpráv ve správném pořadí. Proto ztráta Data zprávy obsahující jednu nebo více I2NP zpráv či fragmentů NEBRÁNÍ doručení ostatních I2NP zpráv; nedochází k blokování hlavy fronty. Implementace by měly pokračovat v odesílání nových zpráv během fáze obnovy po ztrátě, pokud to odesílací okno umožňuje.

Retransmission

Odesílatel by neměl uchovávat plný obsah zprávy pro identické opětovné odeslání (s výjimkou handshake zpráv, viz výše). Odesílatel musí sestavit zprávy obsahující aktuální informace (ACK, NACK a nepotvrzená data) pokaždé, když odešle zprávu. Odesílatel by se měl vyhnout opětovnému přenosu informací ze zpráv, jakmile jsou potvrzeny. To zahrnuje zprávy, které jsou potvrzeny poté, co byly označeny za ztracené, což se může stát při přeuspořádání v síti.

Window

TBD. Obecné pokyny lze najít v RFC 9002.

Connection Migration

IP adresa nebo port protějšku se může během životnosti relace změnit. Změna IP adresy může být způsobena rotací dočasných IPv6 adres, periodickou změnou IP adresy řízenou ISP, mobilním klientem přecházejícím mezi WiFi a mobilními IP adresami, nebo jinými změnami v místní síti. Změna portu může být způsobena NAT rebindingem poté, co vypršel časový limit předchozího bindingu.

IP adresa nebo port protějška se může zdát měnit kvůli různým útokům na cestě i mimo cestu, včetně modifikace nebo vkládání paketů.

Migrace připojení je proces, při kterém je validován nový zdrojový endpoint (IP+port), zatímco se zabraňuje změnám, které nejsou validovány. Tento proces je zjednodušenou verzí procesu definovaného v QUIC RFC 9000. Tento proces je definován pouze pro datovou fázi relace. Migrace není povolena během handshake. Všechny handshake pakety musí být ověřeny, že pocházejí ze stejné IP adresy a portu jako dříve odeslané a přijaté pakety. Jinými slovy, IP adresa a port protějšku musí být konstantní během handshake.

Threat Model

(Adaptováno z QUIC RFC 9000)

Poznámky

Peer může podvrhnout svou zdrojovou adresu, aby způsobil, že endpoint pošle nadměrné množství dat neochotnému hostiteli. Pokud endpoint pošle výrazně více dat než podvrhující peer, migrace připojení může být použita k zesílení objemu dat, který může útočník generovat směrem k oběti.

Fragmentace potvrzené relace

Útočník na cestě by mohl způsobit falešnou migraci připojení zkopírováním a přeposláním paketu se spoofovanou adresou tak, aby dorazil před původním paketem. Paket se spoofovanou adresou bude vnímán jako pocházející z migrujícího připojení a původní paket bude považován za duplikát a zahozen. Po falešné migraci selže validace zdrojové adresy, protože entita na zdrojové adrese nemá potřebné kryptografické klíče k přečtení nebo odpovědi na Path Challenge, který jí je poslán, i kdyby chtěla.

Off-Path Packet Forwarding

Útočník mimo cestu, který může pozorovat pakety, může předávat kopie pravých paketů koncovým bodům. Pokud zkopírovaný paket dorazí před pravým paketem, bude se to jevit jako NAT rebinding. Jakýkoli pravý paket bude zahozen jako duplikát. Pokud je útočník schopen pokračovat v předávání paketů, může být schopen způsobit migraci na cestu přes útočníka. To postaví útočníka na cestu a dá mu možnost pozorovat nebo zahazovat všechny následující pakety.

Privacy Implications

QUIC RFC 9000 specifikuje změnu ID připojení při změně síťových cest. Použití stabilního ID připojení na více síťových cestách by umožnilo pasivnímu pozorovateli korelovat aktivitu mezi těmito cestami. Koncový bod, který se přesouvá mezi sítěmi, si nemusí přát, aby byla jejich aktivita korelována jakoukoliv entitou jinou než jejich protějškem. QUIC však nešifruje ID připojení v hlavičce. SSU2 to dělá, takže únik soukromí by vyžadoval, aby pasivní pozorovatel měl také přístup k síťové databázi, aby získal klíč pro představení potřebný k dešifrování ID připojení. I s klíčem pro představení se nejedná o silný útok a po migraci v SSU2 neměníme ID připojení, protože by to bylo významné zkomplikování.

Initiating Path Validation

Během datové fáze musí protějšky zkontrolovat zdrojovou IP adresu a port každého přijatého datového paketu. Pokud se IP adresa nebo port liší od dříve přijatých, A paket není duplikát čísla paketu, A paket se úspěšně dešifruje, relace vstoupí do fáze validace cesty.

Navíc musí peer ověřit, že nová IP adresa a port jsou platné podle místních validačních pravidel (nejsou blokovány, nejsou nepovolené porty atd.). Peery NEJSOU povinny podporovat migraci mezi IPv4 a IPv6 a mohou považovat novou IP adresu v jiné adresní rodině za neplatnou, protože se nejedná o očekávané chování a může to přidat významnou implementační složitost. Po obdržení paketu z neplatné IP adresy/portu může implementace paket jednoduše zahodit nebo může zahájit validaci cesty se starou IP adresou/portem.

Po vstupu do fáze validace cesty proveďte následující kroky:

• Spustit časovač pro timeout validace cesty na několik sekund, nebo několikrát současné RTO (TBD)
• Zmenšit okno zahlcení na minimum
• Zmenšit PMTU na minimum (1280)
• Poslat datový paket obsahující blok Path Challenge, blok Address (obsahující nové IP/port), a typicky blok ACK, na nové IP a port. Tento paket používá stejné ID připojení a šifrovací klíče jako současná relace. Data bloku Path Challenge musí obsahovat dostatečnou entropii (nejméně 8 bajtů), aby nemohla být podvržena.
• Volitelně také poslat Path Challenge na staré IP/port, s odlišnými daty bloku. Viz níže.
• Spustit časovač pro timeout Path Response založený na současném RTO (typicky RTT + násobek RTTdev)

Během fáze validace cesty může relace pokračovat ve zpracovávání příchozích paketů. Ať už ze starého nebo nového IP/portu. Relace může také pokračovat v odesílání a potvrzování datových paketů. Congestion window a PMTU však musí zůstat na minimálních hodnotách během fáze validace cesty, aby se zabránilo jejich využití pro útoky typu denial of service zasíláním velkého množství provozu na falešnou adresu.

Implementace může, ale nemusí, se pokoušet o současné ověření více cest. Toto pravděpodobně nestojí za složitost. Může, ale nemusí, si pamatovat předchozí IP/port jako již ověřený a přeskočit ověření cesty, pokud se peer vrátí ke své předchozí IP/portu.

Pokud je přijata Path Response obsahující identická data odeslaná v Path Challenge, Path Validation byla úspěšná. Zdrojová IP adresa/port zprávy Path Response nemusí být stejná jako ta, na kterou byla odeslána Path Challenge.

Pokud není Path Response přijata před vypršením časovače Path Response, odešlete další Path Challenge a zdvojnásobte časovač Path Response.

Pokud není Path Response přijata před vypršením časovače Path Validation, Path Validation selhala.

Message Contents

Zprávy Data by měly obsahovat následující bloky. Pořadí není specifikováno kromě toho, že Padding musí být poslední:

• Blok Path Validation nebo Path Response. Path Validation obsahuje neprůhledná data, doporučuje se minimálně 8 bajtů. Path Response obsahuje data z Path Validation.
• Blok Address obsahující zjevnou IP adresu příjemce
• Blok DateTime
• Blok ACK
• Blok Padding

Nedoporučuje se do zprávy zahrnovat žádné jiné bloky (například I2NP).

Je povoleno zahrnout blok Path Validation do zprávy obsahující Path Response, aby se iniciovala validace v opačném směru.

Bloky Path Challenge a Path Response vyvolávají ACK. Path Challenge bude potvrzen zprávou Data obsahující bloky Path Response a ACK. Path Response by měl být potvrzen zprávou Data obsahující blok ACK.

Routing during Path Validation

Specifikace QUIC není jasná ohledně toho, kam odesílat datové pakety během validace cesty - na starou nebo novou IP/port? Je potřeba najít rovnováhu mezi rychlou reakcí na změny IP/portu a neodesíláním provozu na falešné adresy. Falešné pakety také nesmí výrazně ovlivnit existující relaci. Změny pouze portu jsou pravděpodobně způsobeny rebindingem NAT po období nečinnosti; změny IP se mohou stát během fází s vysokým provozem v jednom nebo obou směrech.

Strategie podléhají výzkumu a zdokonalování. Možnosti zahrnují:

• Neodesílání datových paketů na novou IP/port dokud není validována
• Pokračování v odesílání datových paketů na starou IP/port dokud není nová IP/port validována
• Současná revalidace staré IP/port
• Neodesílání žádných dat dokud není validována buď stará nebo nová IP/port
• Různé strategie pro změnu pouze portu oproti změně IP
• Různé strategie pro IPv6 změnu ve stejné /32, pravděpodobně způsobenou rotací dočasných adres

Responding to Path Challenge

Po obdržení Path Challenge musí peer odpovědět datovým paketem obsahujícím Path Response s daty z Path Challenge. TODO Možná???: Path Response musí být odeslána na IP/port, ze kterého byla Path Challenge přijata. Toto NEMUSÍ NUTNĚ být IP/port, který byl dříve navázán pro peer. Tím se zajistí, že validace cesty peerem uspěje pouze pokud je cesta funkční v obou směrech. Viz sekce Validace po lokální změně níže.

Pokud se IP/port liší od dříve známé IP/portu pro peer, zacházejte s Path Challenge jako s jednoduchým pingem a jednoduše bezpodmínečně odpovězte pomocí Path Response. Příjemce neuchovává ani nemění žádný stav na základě přijatého Path Challenge. Pokud se IP/port liší, peer musí ověřit, že nová IP a port jsou platné podle místních ověřovacích pravidel (nejsou blokované, nejsou nepovolené porty atd.). Peers NEJSOU povinni podporovat odpovědi napříč rodinami adres mezi IPv4 a IPv6 a mohou zacházet s novou IP v jiné rodině adres jako s neplatnou, protože se nejedná o očekávané chování.

Pokud není omezena řízením zahlcení, měla by být Path Response odeslána okamžitě. Implementace by měly přijmout opatření k omezení rychlosti Path Responses nebo použité šířky pásma, pokud je to nutné.

Blok Path Challenge je obecně doprovázen blokem Address ve stejné zprávě. Pokud blok address obsahuje novou IP/port, peer může ověřit tuto IP/port a zahájit peer testing této nové IP/port se session peerem nebo jakýmkoliv jiným peerem. Pokud si peer myslí, že je za firewallem a změnil se pouze port, tato změna je pravděpodobně způsobena NAT rebindingem a další peer testing pravděpodobně není potřebný.

Successful Path Validation

Po úspěšném ověření cesty je připojení plně migrováno na novou IP/port. Při úspěchu:

• Ukončit fázi validace cesty
• Všechny pakety jsou odesílány na novou IP a port.
• Omezení na congestion window a PMTU jsou odstraněna a je jim povoleno se zvyšovat. Neobnovujte je jednoduše na staré hodnoty, protože nová cesta může mít odlišné charakteristiky.
• Pokud se IP změnila, nastavte vypočítané RTT a RTO na počáteční hodnoty. Protože změny pouze portu jsou běžně výsledkem NAT rebindingu nebo jiné aktivity middleboxů, peer může místo toho zachovat svůj stav řízení přetížení a odhad round-trip času v těchto případech namísto návratu k počátečním hodnotám.
• Smazat (zneplatnit) jakékoli tokeny odeslané nebo přijaté pro starou IP/port (volitelné)
• Odeslat nový blok tokenů pro novou IP/port (volitelné)

Cancelling Path Validation

Během fáze validace cesty způsobí jakékoli platné, neduplikované pakety, které jsou přijaty ze staré IP/portu a úspěšně dešifrovány, zrušení Path Validation. Je důležité, aby zrušená validace cesty způsobená podvrženým paketem nezpůsobila ukončení platné relace nebo její významné narušení.

Při zrušené validaci cesty:

• Ukončit fázi validace cesty
• Všechny pakety jsou odesílány na starou IP adresu a port.
• Omezení na congestion window a PMTU jsou odstraněna a je jim dovoleno se zvýšit, nebo případně obnovit předchozí hodnoty
• Retransmitovat všechny datové pakety, které byly dříve odeslány na novou IP/port na starou IP/port.

Failed Path Validation

Je důležité, aby neúspěšná validace cesty, způsobená falešným paketem, nezpůsobila ukončení nebo významné narušení platné relace.

Při neúspěšné validaci cesty:

• Ukončit fázi validace cesty
• Všechny pakety jsou odesílány na starou IP adresu a port.
• Omezení okna zahltění a PMTU jsou odstraněna a mohou se zvyšovat.
• Volitelně spustit validaci cesty na staré IP adrese a portu. Pokud selže, ukončit relaci.
• Jinak následovat standardní pravidla pro timeout a ukončení relace.
• Znovu odeslat všechny datové pakety, které byly dříve odeslány na novou IP/port, na starou IP adresu/port.

Validation After Local Change

Výše uvedený proces je definován pro peery, kteří obdrží paket ze změněné IP/portu. Může však být také iniciován opačným směrem, peerem, který zjistí, že se jeho IP nebo port změnily. Peer může být schopen zjistit, že se jeho místní IP změnila; je však mnohem méně pravděpodobné, že zjistí změnu svého portu kvůli NAT rebindingu. Proto je toto volitelné.

Při obdržení path challenge od peera, jehož IP nebo port se změnil, by druhý peer měl iniciovat path challenge v opačném směru.

Bezpečnost relay

Bloky Path Validation a Path Response mohou být použity kdykoli jako Ping/Pong pakety. Příjem bloku Path Validation nemění žádný stav u příjemce, pokud není přijat z jiné IP/portu.

Multiple Sessions

Peeři by neměli navazovat více relací se stejným peerem, ať už SSU 1 nebo 2, nebo se stejnými či různými IP adresami. To se však může stát, buď kvůli chybám, nebo kvůli ztrátě předchozí zprávy o ukončení relace, nebo v situaci, kdy zpráva o ukončení ještě nedorazila.

Pokud má Bob existující session s Alice, když Bob obdrží Session Confirmed od Alice, dokončující handshake a navazující novou session, Bob by měl:

• Migrovat všechny neodeslané nebo nepotvrzené odchozí I2NP zprávy ze staré relace do nové
• Odeslat ukončení s kódem důvodu 22 na staré relaci
• Odstranit starou relaci a nahradit ji novou

Session Termination

Bezpečnost Peer Test

Relace ve fázi handshake jsou obecně ukončovány jednoduše vypršením časového limitu nebo dalším neodpovídáním. Volitelně mohou být ukončeny zahrnutím bloku Termination v odpovědi, ale na většinu chyb není možné odpovědět kvůli nedostupnosti kryptografických klíčů. I když jsou klíče pro odpověď včetně bloku termination k dispozici, obvykle nestojí za CPU výkon potřebný k provedení DH pro odpověď. Výjimkou MŮŽE být blok Termination v retry zprávě, která je levná na vygenerování.

Cíle návrhu Relay a Peer Test

Relace ve fázi dat jsou ukončeny odesláním datové zprávy, která obsahuje blok Termination. Tato zpráva by také měla obsahovat blok ACK. Může, pokud byla relace aktivní dostatečně dlouho na to, aby dříve odeslaný token vypršel nebo měl brzy vypršet, obsahovat blok New Token. Tato zpráva nevyžaduje potvrzení. Při přijetí bloku Termination s jakýmkoliv důvodem kromě “Termination Received” protějšek odpovídá datovou zprávou obsahující blok Termination s důvodem “Termination Received”.

Po odeslání nebo přijetí bloku Termination by relace měla vstoupit do fáze uzavírání na nějakou maximální dobu, která bude určena později. Stav uzavírání je nezbytný pro ochranu proti ztrátě paketu obsahujícího blok Termination a paketů, které jsou právě přenášeny v opačném směru. Během fáze uzavírání neexistuje požadavek na zpracování jakýchkoli dalších přijatých paketů. Relace ve stavu uzavírání odešle paket obsahující blok Termination jako odpověď na jakýkoli příchozí paket, který přiřadí k relaci. Relace by měla omezit rychlost, s jakou generuje pakety ve stavu uzavírání. Například relace může čekat na progresivně rostoucí počet přijatých paketů nebo množství času před odpovídáním na přijaté pakety.

Pro minimalizaci stavu, který router udržuje pro ukončovanou relaci, mohou relace, ale není to povinné, poslat naprosto stejný paket se stejným číslem paketu tak, jak je, v odpovědi na jakýkoliv přijatý paket. Poznámka: Povolení retransmise ukončovacího paketu je výjimkou z požadavku, aby bylo pro každý paket použito nové číslo paketu. Posílání nových čísel paketů je primárně výhodné pro obnovu po ztrátě a řízení zahlcení, což se u uzavřeného spojení nepředpokládá, že bude relevantní. Retransmise posledního paketu vyžaduje méně stavu.

Po obdržení Termination bloku s důvodem “Termination Received” může relace ukončit fázi zavírání.

Cleanup

Při jakémkoliv normálním nebo abnormálním ukončení by měly routery vynulovat všechna dočasná data v paměti, včetně dočasných klíčů pro handshake, symetrických kryptografických klíčů a souvisejících informací.

MTU

Požadavky se liší podle toho, zda je publikovaná adresa sdílena s SSU 1. Současné minimum SSU 1 IPv4 je 620, což je rozhodně příliš málo.

Minimální SSU2 MTU je 1280 pro IPv4 i IPv6, což je stejné jako specifikováno v RFC 9000. Viz níže. Zvýšením minimální MTU se 1 KB tunnel zprávy a krátké tunnel build zprávy vejdou do jednoho datagramu, což výrazně sníží typické množství fragmentace. To také umožňuje zvýšení maximální velikosti I2NP zprávy. 1820-bajtové streaming zprávy by se měly vejít do dvou datagramů.

Router nesmí povolit SSU2 nebo publikovat SSU2 adresu, pokud MTU pro tuto adresu není alespoň 1280.

Routery musí publikovat jiné než výchozí MTU v každé SSU nebo SSU2 adrese routeru.

Shrnutí

Sdílená adresa s SSU 1, musí následovat pravidla SSU 1. IPv4: Výchozí a maximum je 1484. Minimum je 1292. (IPv4 MTU + 4) musí být násobek 16. IPv6: Musí být publikována, minimum je 1280 a maximum je 1488. IPv6 MTU musí být násobek 16.

Záruky doručení

IPv4: Výchozí a maximum je 1500. Minimum je 1280. IPv6: Výchozí a maximum je 1500. Minimum je 1280. Žádná pravidla násobků 16, ale pravděpodobně by to měl být alespoň násobek 2.

Noise Protocol Framework

Pro SSU 1 současná Java I2P provádí zjišťování PMTU tím, že začíná s malými pakety a postupně zvyšuje velikost, nebo zvyšuje na základě velikosti přijatých paketů. To je primitivní řešení a výrazně snižuje efektivitu. Pokračování této funkce v SSU 2 je zatím nejisté.

Nedávné studie PMTU naznačují, že minimum pro IPv4 1200 nebo více by fungovalo pro více než 99% spojení. QUIC RFC 9000 vyžaduje minimální velikost IP paketu 1280 bajtů.

citace RFC 9000:

Maximální velikost datagramu je definována jako největší velikost UDP payload, která může být odeslána přes síťovou cestu pomocí jediného UDP datagramu. QUIC NESMÍ být použit, pokud síťová cesta nepodporuje maximální velikost datagramu alespoň 1200 bytů.

QUIC předpokládá minimální velikost IP paketu alespoň 1280 bajtů. Toto je minimální velikost pro IPv6 [IPv6] a je také podporována většinou moderních IPv4 sítí. Za předpokladu minimální velikosti IP hlavičky 40 bajtů pro IPv6 a 20 bajtů pro IPv4 a velikosti UDP hlavičky 8 bajtů to má za následek maximální velikost datagramu 1232 bajtů pro IPv6 a 1252 bajtů pro IPv4. Očekává se tedy, že moderní IPv4 a všechny IPv6 síťové cesty budou schopny podporovat QUIC.

Poznámka: Tento požadavek na podporu UDP payload o velikosti 1200 bajtů omezuje dostupný prostor pro IPv6 extension headers na 32 bajtů nebo IPv4 options na 52 bajtů, pokud cesta podporuje pouze minimální IPv6 MTU 1280 bajtů. Toto ovlivňuje Initial packety a path validation.

konec citace

Dodatky k Frameworku

QUIC vyžaduje, aby počáteční datagramy v obou směrech měly alespoň 1200 bytů, aby se zabránilo zesilovacím útokům a zajistilo se, že PMTU to podporuje v obou směrech.

Mohli bychom to vyžadovat pro Session Request a Session Created, za značnou cenu v šířce pásma. Možná bychom to mohli dělat pouze pokud nemáme token, nebo po přijetí zprávy Retry. TBD

QUIC vyžaduje, aby Bob neposílal více než trojnásobek množství dat obdržených, dokud nebude adresa klienta ověřena. SSU2 tento požadavek splňuje inherentně, protože zpráva Retry má přibližně stejnou velikost jako zpráva Token Request a je menší než zpráva Session Request. Také zpráva Retry je poslána pouze jednou.

Odhad režijních nákladů na zpracování

QUIC vyžaduje, aby zprávy obsahující PATH_CHALLENGE nebo PATH_RESPONSE bloky měly alespoň 1200 bytů, aby se zabránilo amplifikačním útokům a zajistilo se, že PMTU to podporuje v obou směrech.

Mohli bychom to také vyžadovat za značné ceny v šířce pásma. Nicméně tyto případy by měly být vzácné. TBD

Max I2NP Message Size

IPv4: Nepředpokládá se fragmentace IP. Hlavička IP + datagram má 28 bytů. Toto předpokládá žádné IPv4 volby. Maximální velikost zprávy je MTU - 28. Hlavička datové fáze má 16 bytů a MAC má 16 bytů, celkem 32 bytů. Velikost payload je MTU - 60. Maximální payload datové fáze je 1440 pro maximální MTU 1500. Maximální payload datové fáze je 1220 pro minimální MTU 1280.

IPv6: Fragmentace IP není povolena. Hlavička IP + datagram má 48 bajtů. Toto předpokládá žádné IPv6 rozšiřující hlavičky. Maximální velikost zprávy je MTU - 48. Hlavička datové fáze má 16 bajtů a MAC má 16 bajtů, celkem 32 bajtů. Velikost payload je MTU - 80. Maximální payload datové fáze je 1420 pro maximální MTU 1500. Maximální payload datové fáze je 1200 pro minimální MTU 1280.

V SSU 1 byla směrnice striktní maximum přibližně 32 KB pro I2NP zprávu založenou na 64 maximálních fragmentech a 620 minimální MTU. Kvůli režii pro sdružené LeaseSets a session keys byl praktický limit na úrovni aplikace přibližně o 6 KB nižší, tedy přibližně 26 KB. Protokol SSU 1 umožňuje 128 fragmentů, ale současné implementace jej omezují na 64 fragmentů.

Zvýšením minimální MTU na 1280, s datovou částí payload přibližně 1200, je možná SSU 2 zpráva o velikosti asi 76 KB v 64 fragmentech a 152 KB ve 128 fragmentech. To snadno umožňuje maximum 64 KB.

Kvůli fragmentaci v tunelech a fragmentaci v SSU 2 se pravděpodobnost ztráty zprávy exponenciálně zvyšuje s velikostí zprávy. Nadále doporučujeme praktický limit přibližně 10 KB na aplikační vrstvě pro I2NP datagramy.

Peer Test Process

Viz Bezpečnost Peer Test výše pro analýzu SSU1 Peer Test a cíle pro SSU2 Peer Test.

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

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

Když je odmítnut Bobem:

Alice                     Bob                  Charlie
1. PeerTest ------------------->
4.      <------------------ PeerTest (reject)

Když je odmítnut Charlie:

Alice                     Bob                  Charlie
1. PeerTest ------------------->
                              Alice RI ------------------->
2.                          PeerTest ------------------->
3.                             <------------------ PeerTest (reject)
                        (optional: Bob could try another Charlie here)
4.      <------------------ PeerTest (reject)

POZNÁMKA: RI může být zasláno buď jako I2NP Database Store zprávy v I2NP blocích, nebo jako RI bloky (pokud jsou dostatečně malé). Tyto mohou být obsaženy ve stejných paketech jako bloky peer testu, pokud jsou dostatečně malé.

Zprávy 1-4 jsou v rámci relace pomocí bloků Peer Test v Data zprávě. Zprávy 5-7 jsou mimo relaci pomocí bloků Peer Test v Peer Test zprávě.

POZNÁMKA: Stejně jako v SSU 1, zprávy 4 a 5 mohou přijít v libovolném pořadí. Zpráva 5 a/nebo 7 nemusí být vůbec přijaty, pokud je Alice za firewallem. Když zpráva 5 přijde před zprávou 4, Alice nemůže okamžitě odeslat zprávu 6, protože ještě nemá Charlieho intro klíč pro šifrování hlavičky. Když zpráva 4 přijde před zprávou 5, Alice by neměla okamžitě odeslat zprávu 6, protože by měla počkat, zda přijde zpráva 5, aniž by otevírala firewall zprávou 6.

Versions

Testování mezi různými verzemi není podporováno. Jediná povolená kombinace verzí je taková, kde všichni peeři jsou verze 2.

Navázání relace

Zprávy 1-4 jsou v rámci relace a jsou pokryty procesy ACK a retransmise datové fáze. Bloky Peer Test vyžadují potvrzení.

Zprávy 5-7 mohou být znovu přeneseny, nezměněné.

Hlavička paketu

Stejně jako v SSU 1 je podporováno testování IPv6 adres a komunikace Alice-Bob a Alice-Charlie může probíhat přes IPv6, pokud Bob a Charlie označí podporu pomocí capability ‘B’ ve své publikované IPv6 adrese. Podrobnosti naleznete v Proposal 126.

Stejně jako v SSU 1 před verzí 0.9.50, Alice posílá požadavek Bobovi pomocí existující relace přes transport (IPv4 nebo IPv6), který chce testovat. Když Bob obdrží požadavek od Alice přes IPv4, Bob musí vybrat Charlieho, který inzeruje IPv4 adresu. Když Bob obdrží požadavek od Alice přes IPv6, Bob musí vybrat Charlieho, který inzeruje IPv6 adresu. Skutečná komunikace Bob-Charlie může probíhat přes IPv4 nebo IPv6 (tj. nezávisle na typu adresy Alice). Toto NENÍ chování SSU 1 od verze 0.9.50, kde jsou povoleny smíšené IPv4/v6 požadavky.

Processing by Bob

Na rozdíl od SSU 1 Alice specifikuje požadovanou testovací IP adresu a port ve zprávě 1. Bob by měl tuto IP adresu a port ověřit a odmítnout s kódem 5, pokud jsou neplatné. Doporučené ověření IP adresy je, že u IPv4 odpovídá Alicině IP adrese, a u IPv6 se shodují alespoň první 8 bajtů IP adresy. Ověření portu by mělo odmítnout privilegované porty a porty pro známé protokoly.

Relay Process

Viz Relay Security výše pro analýzu SSU1 Relay a cíle pro SSU2 Relay.

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 ------------------------------------------>

Když je odmítnut Bobem:

Alice                         Bob                  Charlie
     lookup Bob RI

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

1. RelayRequest ---------------------->
4.      <-------------- RelayResponse

Když je odmítnut Charliem:

Alice                         Bob                  Charlie
     lookup Bob RI

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

1. RelayRequest ---------------------->
                                           Alice RI  ------------>
2.                                       RelayIntro ----------->
3.                                  <-------------- RelayResponse
4.      <-------------- RelayResponse

POZNÁMKA: RI může být odesláno buď jako I2NP Database Store zprávy v I2NP blocích, nebo jako RI bloky (pokud jsou dostatečně malé). Tyto mohou být obsaženy ve stejných paketech jako relay bloky, pokud jsou dostatečně malé.

V SSU 1 obsahují informace o Charlieho routeru IP, port, intro klíč, relay tag a expiraci každého introducera.

V SSU 2 obsahují informace o routeru Charlie hash routeru, relay tag a expiraci každého introducera.

Alice by měla snížit počet round tripů tím, že nejprve vybere introducer (Bob), ke kterému už má připojení. Pokud žádný takový není, měla by vybrat introducer, pro kterého už má router info.

Přeposílání mezi verzemi by také mělo být podporováno, pokud je to možné. To usnadní postupný přechod ze SSU 1 na SSU 2. Povolené kombinace verzí jsou (TODO):

Retransmissions

Relay Request, Relay Intro a Relay Response jsou všechny v rámci relace a jsou pokryty procesy ACK a retransmise datové fáze. Bloky Relay Request, Relay Intro a Relay Response vyvolávají potvrzení.

Hole punch může být retransmitován, jako v SSU 1.

IPv4/v6

Všechny funkce SSU 1 relay jsou podporovány, včetně těch zdokumentovaných v Proposal 158 a podporovaných od verze 0.9.50. IPv4 a IPv6 introdukce jsou podporovány. Relay Request může být odeslán přes IPv4 relaci pro IPv6 introdukci a Relay Request může být odeslán přes IPv6 relaci pro IPv4 introdukci.

Processing by Alice

Následují rozdíly oproti SSU 1 a doporučení pro implementaci SSU 2.

Poznámky

V SSU 1 je představení relativně levné a Alice obecně posílá Relay Requests všem introducer-ům. V SSU 2 je představení nákladnější, protože musí být nejprve navázáno spojení s introducer-em. Pro minimalizaci latence představení a režijních nákladů se doporučují následující kroky zpracování:

• Ignorovat všechny introducery, které jsou prošlé na základě hodnoty iexp v adrese
• Pokud je již navázáno SSU2 spojení k jednomu nebo více introducerům, vybrat jeden a poslat Relay Request pouze tomuto introduceru.
• Jinak, pokud je Router Info lokálně známo pro jeden nebo více introducerů, vybrat jeden a připojit se pouze k tomuto introduceru.
• Jinak vyhledat Router Info pro všechny introducery, připojit se k introduceru, jehož Router Info je přijato jako první.

Poznámky

V SSU 1 i SSU 2 mohou být Relay Response a Hole Punch přijaty v libovolném pořadí, nebo nemusí být přijaty vůbec.

V SSU 1 Alice obvykle obdrží Relay Response (1 RTT) před Hole Punch (1 1/2 RTT). V těchto specifikacích to možná není dobře zdokumentováno, ale Alice musí obdržet Relay Response od Boba před pokračováním, aby získala IP adresu Charlieho. Pokud je Hole Punch obdržen jako první, Alice jej nerozpozná, protože neobsahuje žádná data a zdrojová IP adresa není rozpoznána. Po obdržení Relay Response by Alice měla čekat BUĎTO na obdržení Hole Punch od Charlieho, NEBO krátké zpoždění (doporučených 500 ms) před zahájením handshake s Charliem.

V SSU 2 Alice obvykle obdrží Hole Punch (1 1/2 RTT) před Relay Response (2 RTT). SSU 2 Hole Punch je jednodušší zpracovat než v SSU 1, protože je to úplná zpráva s definovanými connection ID (odvozené z relay nonce) a obsahem včetně Charlie IP. Relay Response (Data zpráva) a Hole Punch zpráva obsahují identický podepsaný Relay Response blok. Proto může Alice iniciovat handshake s Charlie poté, co BUĎ obdrží Hole Punch od Charlie, NEBO obdrží Relay Response od Boba.

Ověření podpisu Hole Punch zahrnuje hash routeru představitele (Boba). Pokud byly Relay Requests odeslány více než jednomu představiteli, existuje několik možností pro validaci podpisu:

• Zkuste každý hash, na který byla poslána žádost
• Použijte různé nonce pro každého introducera a použijte to k určení, kterému introducerovi tento Hole Punch odpovídal
• Neověřujte znovu podpis, pokud je obsah identický s tím v Relay Response, pokud již byla přijata
• Neověřujte podpis vůbec

Pokud je Charlie za symetrickým NAT, jeho hlášený port v Relay Response a Hole Punch nemusí být přesný. Proto by Alice měla zkontrolovat zdrojový UDP port zprávy Hole Punch a použít jej, pokud se liší od hlášeného portu.

Tag Requests by Bob

V SSU 1 mohla pouze Alice požádat o tag v Session Request. Bob nemohl nikdy požádat o tag a Alice nemohla fungovat jako relay pro Boba.

V SSU2 Alice obecně vyžádá tag v Session Request, ale jak Alice, tak Bob mohou také vyžádat tag ve fázi dat. Bob obecně není za firewallem po přijetí příchozí žádosti, ale může být po relay, nebo se Bobův stav může změnit, nebo může vyžádat introducer pro jiný typ adresy (IPv4/v6). Takže v SSU2 je možné, aby jak Alice, tak Bob současně fungovali jako relay pro druhou stranu.

Published Router Info

Address Properties

Následující vlastnosti adres mohou být publikovány, nezměněné od SSU 1, včetně změn v Proposal 158 podporovaných od API 0.9.50:

• caps: [B,C,4,6] schopnosti

• host: IP (IPv4 nebo IPv6). Zkrácená IPv6 adresa (s “::”) je povolena. Může nebo nemusí být přítomna, pokud je za firewallem. Názvy hostů nejsou povoleny.

• iexp[0-2]: Vypršení platnosti tohoto introduceru. ASCII číslice, v sekundách od epochy. Přítomno pouze pokud je za firewallem a introducery jsou vyžadovány. Volitelné (i když jsou přítomny další vlastnosti pro tento introducer).

• ihost[0-2]: IP adresa představovatele (IPv4 nebo IPv6). Zkrácená IPv6 adresa (s “::”) je povolena. Přítomno pouze pokud je za firewallem a představovatelé jsou vyžadováni. Názvy hostů nejsou povoleny. Pouze SSU adresa.

• ikey[0-2]: Introducer’s Base 64 introduction key. Přítomen pouze v případě, že je za firewallem a introducery jsou vyžadovány. Pouze SSU adresa.

• iport[0-2]: Port introducera 1024 - 65535. Přítomen pouze pokud je za firewallem a introduceři jsou vyžadováni. Pouze SSU adresa.

• itag[0-2]: Tag představovatele 1 - (2**32 - 1) ASCII číslice. Přítomno pouze pokud je za firewallem a jsou vyžadováni introducers.

• key: Base 64 úvodní klíč.

• mtu: Volitelné. Viz sekce MTU výše.

• port: 1024 - 65535 Může nebo nemusí být přítomen, pokud je za firewallem.

Published Addresses

Publikovaná RouterAddress (část RouterInfo) bude mít protokolový identifikátor buď “SSU” nebo “SSU2”.

RouterAddress musí obsahovat tři možnosti pro indikaci podpory SSU2:

• s=(Base64 klíč) Současný Noise statický veřejný klíč (s) pro tuto RouterAddress. Kódovaný pomocí Base 64 se standardní I2P Base 64 abecedou. 32 bajtů v binární podobě, 44 bajtů jako Base 64 kódovaný, little-endian X25519 veřejný klíč.

• i=(Base64 klíč) Aktuální introdukční klíč pro šifrování hlaviček této RouterAddress. Kódován v Base 64 pomocí standardní I2P Base 64 abecedy. 32 bajtů v binární podobě, 44 bajtů jako Base 64 kódovaný, big-endian ChaCha20 klíč.

• v=2 Aktuální verze (2). Při publikování jako “SSU” je implicitně zahrnuta dodatečná podpora pro verzi 1. Podpora budoucích verzí bude s hodnotami oddělenými čárkami, např. v=2,3 Implementace by měla ověřit kompatibilitu, včetně více verzí, pokud je přítomna čárka. Verze oddělené čárkami musí být v číselném pořadí.

Alice musí ověřit, že jsou všechny tři možnosti přítomny a platné před připojením pomocí protokolu SSU2.

Když je publikován jako “SSU” s možnostmi “s”, “i” a “v” a s možnostmi “host” a “port”, router musí přijímat příchozí spojení na daném hostiteli a portu pro protokoly SSU i SSU2 a automaticky detekovat verzi protokolu.

Když je publikován jako “SSU2” s možnostmi “s”, “i” a “v” a s možnostmi “host” a “port”, router přijímá příchozí připojení na daném hostu a portu pouze pro protokol SSU2.

Pokud router podporuje jak SSU1, tak SSU2 připojení, ale neimplementuje automatickou detekci verze pro příchozí spojení, musí inzerovat jak “SSU”, tak “SSU2” adresy a zahrnout SSU2 možnosti pouze v “SSU2” adrese. Router by měl nastavit nižší hodnotu nákladů (vyšší prioritu) v “SSU2” adrese než v “SSU” adrese, takže je SSU2 upřednostňováno.

Pokud je ve stejném RouterInfo publikováno více SSU2 RouterAddresses (buď jako “SSU” nebo “SSU2”) pro dodatečné IP adresy nebo porty, všechny adresy specifikující stejný port musí obsahovat identické SSU2 volby a hodnoty. Konkrétně všechny musí obsahovat stejný statický klíč “s” a introduction klíč “i”.

Introducers

Když je publikován jako SSU nebo SSU2 s introducers, jsou přítomny následující možnosti:

• ih[0-2]=(Base64 hash) Hash routeru pro introducer. Kódováno v Base 64 pomocí standardní I2P Base 64 abecedy. 32 bajtů v binární podobě, 44 bajtů jako Base 64 kódování

• iexp[0-2]: Vypršení platnosti tohoto introduceru. Nezměněno oproti SSU 1.

• itag[0-2]: Tag představitele 1 - (2**32 - 1) Nezměněno od SSU 1.

Následující možnosti jsou pouze pro SSU a nejsou používány pro SSU2. V SSU2 Alice získává tyto informace místo toho z Charlie’s RI.

• ihost[0-2]
• ikey[0-2]
• itag[0-2]

Router nesmí publikovat host nebo port v adrese při publikování introducerů. Router musí publikovat caps 4 a/nebo 6 v adrese při publikování introducerů, aby indikoval podporu pro IPv4 a/nebo IPv6. Toto je stejné jako současná praxe pro nedávné SSU 1 adresy.

Poznámka: Pokud je publikováno jako SSU a existuje kombinace SSU 1 a SSU2 introducer, SSU 1 introducer by měly být na nižších indexech a SSU2 introducer by měly být na vyšších indexech kvůli kompatibilitě se staršími routery.

Unpublished SSU2 Address

Pokud Alice nezveřejní svou SSU2 adresu (jako “SSU” nebo “SSU2”) pro příchozí spojení, musí zveřejnit router adresu “SSU2” obsahující pouze její statický klíč a SSU2 verzi, aby Bob mohl validovat klíč po přijetí Alice RouterInfo v Session Confirmed části 2.

• s=(Base64 klíč) Jak je definováno výše pro publikované adresy.

• i=(Base64 klíč) Jak je definováno výše pro publikované adresy.

• v=2 Jak je definováno výše pro publikované adresy.

Tato adresa routeru nebude obsahovat možnosti “host” nebo “port”, protože tyto nejsou vyžadovány pro odchozí SSU2 připojení. Publikované náklady pro tuto adresu přísně nevadí, jelikož je pouze příchozí; nicméně může být užitečné pro ostatní routery, pokud jsou náklady nastaveny vyšší (nižší priorita) než u ostatních adres. Doporučená hodnota je 14.

Alice může také jednoduše přidat možnosti “i”, “s” a “v” k existující publikované “SSU” adrese.

Integrita paketů

Používání stejných statických klíčů pro NTCP2 a SSU2 je povoleno, ale nedoporučuje se.

Kvůli cachování RouterInfo nesmějí routery rotovat statický veřejný klíč nebo IV, dokud je router spuštěný, ať už v publikované adrese nebo ne. Routery musí tento klíč a IV trvale uložit pro opětovné použití po okamžitém restartu, aby příchozí spojení nadále fungovala a časy restartů nebyly odhaleny. Routery musí trvale uložit nebo jinak určit čas posledního vypnutí, aby při startu mohla být vypočítána předchozí doba nečinnosti.

S ohledem na obavy ze zveřejnění času restartů mohou routery rotovat tento klíč nebo IV při startu, pokud byl router předtím vypnutý po nějakou dobu (alespoň několik dní).

Pokud má router nějaké publikované SSU2 RouterAddresses (jako SSU nebo SSU2), minimální doba nečinnosti před rotací by měla být mnohem delší, například jeden měsíc, pokud se nezměnila místní IP adresa nebo se router “rekeys”.

Pokud má router nějaké publikované SSU RouterAddresses, ale ne SSU2 (jako SSU nebo SSU2), minimální doba výpadku před rotací by měla být delší, například jeden den, pokud se nezměnila místní IP adresa nebo router neprovádí “rekeys”. To platí i v případě, že publikovaná SSU adresa má introducers.

Pokud router nemá žádné publikované RouterAddresses (SSU, SSU2, nebo SSU), minimální doba výpadku před rotací může být až dvě hodiny, i když se IP adresa změní, pokud se router “nepřeklíčuje”.

Pokud router “přegeneruje klíče” na jiný Router Hash, měl by vygenerovat také nový noise klíč a intro klíč.

Implementace si musí být vědomy toho, že změna statického veřejného klíče nebo IV znemožní příchozí SSU2 spojení od routerů, které mají v mezipaměti starší RouterInfo. Publikování RouterInfo, výběr tunnel peerů (včetně OBGW i IB nejbližšího hopu), výběr zero-hop tunnelů, výběr transportu a další implementační strategie musí toto brát v úvahu.

Rotace intro klíčů podléhá stejným pravidlům jako rotace klíčů.

Poznámka: Minimální doba výpadku před rekeying může být upravena za účelem zajištění zdraví sítě a předcházení reseeding routerem, který byl po středně dlouhou dobu nefunkční.

Identity Hiding

Popiratelnost není cílem. Viz přehled výše.

Každému vzoru jsou přiřazeny vlastnosti popisující důvěrnost poskytovanou statickému veřejnému klíči iniciátora a statickému veřejnému klíči respondenta. Základní předpoklady jsou, že dočasné soukromé klíče jsou bezpečné a že strany přeruší handshake, pokud obdrží statický veřejný klíč od druhé strany, které nedůvěřují.

Tato sekce se zabývá pouze únikem identity prostřednictvím statických polí veřejných klíčů v handshake protokolech. Samozřejmě, identity účastníků Noise protokolu mohou být odhaleny jinými způsoby, včetně polí datové části, analýzy provozu nebo metadat, jako jsou IP adresy.

Alice: (8) Šifrováno s forward secrecy k ověřené straně.

Bob: (3) Nepřenášeno, ale pasivní útočník může kontrolovat kandidáty na soukromý klíč respondéra a určit, zda je kandidát správný.

Bob publikuje svůj statický veřejný klíč v netDb. Alice to nemusí dělat, ale musí ho zahrnout do RI odeslaného Bobovi.

Packet Guidelines

Autentizované šifrování

Zprávy handshake (Session Request/Created/Confirmed, Retry) základní kroky, v pořadí:

• Vytvořit 16 nebo 32 bytovou hlavičku
• Vytvořit payload
• mixHash() hlavičku (kromě Retry)
• Zašifrovat payload pomocí Noise (kromě Retry, použít ChaChaPoly s hlavičkou jako AD)
• Zašifrovat hlavičku a pro Session Request/Created, ephemeral klíč

Základní kroky zpráv datové fáze, v pořadí:

• Vytvořit 16-bajtový header
• Vytvořit payload
• Zašifrovat payload pomocí ChaChaPoly s použitím headeru jako AD
• Zašifrovat header

Inbound Packet Handling

Datová část

Počáteční zpracování všech příchozích zpráv:

• Dešifrovat prvních 8 bajtů hlavičky (Destination Connection ID) pomocí intro klíče
• Vyhledat spojení podle Destination Connection ID
• Pokud je spojení nalezeno a je ve fázi dat, přejít do sekce fáze dat
• Pokud spojení není nalezeno, přejít do sekce handshake
• Poznámka: Zprávy Peer Test a Hole Punch mohou být také vyhledány podle Destination Connection ID vytvořeného z test nebo relay nonce.

Zpracování handshake zpráv (Session Request/Created/Confirmed, Retry, Token Request) a dalších mimosezónních zpráv (Peer Test, Hole Punch):

• Dešifrovat bajty 8-15 hlavičky (typ paketu, verze a net ID) pomocí intro klíče. Pokud se jedná o validní Session Request, Token Request, Peer Test nebo Hole Punch, pokračovat
• Pokud se nejedná o validní zprávu, vyhledat čekající odchozí spojení podle zdrojové IP/portu paketu, považovat paket za Session Created nebo Retry. Znovu dešifrovat prvních 8 bajtů hlavičky se správným klíčem, a bajty 8-15 hlavičky (typ paketu, verze a net ID). Pokud se jedná o validní Session Created nebo Retry, pokračovat
• Pokud se nejedná o validní zprávu, selhat, nebo zařadit do fronty jako možný paket datové fáze mimo pořadí
• Pro Session Request/Created, Retry, Token Request, Peer Test a Hole Punch dešifrovat bajty 16-31 hlavičky
• Pro Session Request/Created dešifrovat ephemeral klíč
• Validovat všechna pole hlavičky, zastavit pokud nejsou validní
• mixHash() hlavičku
• Pro Session Request/Created/Confirmed dešifrovat payload pomocí Noise
• Pro Retry a datovou fázi dešifrovat payload pomocí ChaChaPoly
• Zpracovat hlavičku a payload

Zpracování zpráv datové fáze:

• Dešifrovat bajty 8-15 hlavičky (typ paketu, verze a net ID) se správným klíčem
• Dešifrovat payload pomocí ChaChaPoly s použitím hlavičky jako AD
• Zpracovat hlavičku a payload

Details

V SSU 1 je klasifikace příchozích paketů obtížná, protože neexistuje hlavička indikující číslo relace. Routery musí nejprve porovnat zdrojovou IP adresu a port s existujícím stavem protějšku, a pokud není nalezen, pokusit se o několik dešifrování s různými klíči, aby našly odpovídající stav protějšku nebo spustily nový. V případě, že se změní zdrojová IP adresa nebo port pro existující relaci, možná kvůli chování NAT, může router použít nákladnou heuristiku k pokusu o přiřazení paketu k existující relaci a obnovení obsahu.

SSU 2 je navrženo k minimalizaci úsilí při klasifikaci příchozích paketů při zachování odolnosti proti DPI a dalším hrozbám na cestě. Číslo Connection ID je zahrnuto v hlavičce pro všechny typy zpráv a je šifrováno (obfuskováno) pomocí ChaCha20 se známým klíčem a nonce. Navíc je typ zprávy také zahrnut v hlavičce (šifrován s ochranou hlavičky známým klíčem a poté obfuskován pomocí ChaCha20) a může být použit pro další klasifikaci. V žádném případě není nutná zkušební DH nebo jiná asymetrická kryptografická operace pro klasifikaci paketu.

Pro téměř všechny zprávy od všech peerů je ChaCha20 klíč pro šifrování Connection ID introduction key cílového routeru, jak je publikován v netDb.

Jedinými výjimkami jsou první zprávy odeslané z Boba k Alici (Session Created nebo Retry), kde Bobovi ještě není znám Alicin introduction key. V těchto případech se jako klíč použije Bobův introduction key.

Protokol je navržen tak, aby minimalizoval zpracování klasifikace paketů, které by mohlo vyžadovat dodatečné kryptografické operace v několika záložních krocích nebo komplexní heuristiky. Navíc, naprostá většina přijatých paketů nebude vyžadovat (případně nákladné) záložní vyhledávání podle zdrojové IP/portu a druhé dešifrování hlavičky. Pouze Session Created a Retry (a případně další TBD) budou vyžadovat záložní zpracování. Pokud se endpoint změní IP nebo port po vytvoření relace, connection ID se stále používá k vyhledání relace. Nikdy není nutné používat heuristiky k nalezení relace, například hledáním jiné relace se stejnou IP, ale jiným portem.

Proto jsou doporučené kroky zpracování v logice smyčky přijímače:

1. Dešifrujte prvních 8 bajtů pomocí ChaCha20 s použitím lokálního introduction key, k obnovení Destination Connection ID. Pokud se Connection ID shoduje s aktuální nebo čekající příchozí relací:

a) Pomocí příslušného klíče dešifrujte bajty hlavičky 8-15

  to recover the version, net ID, and message type.

b) Pokud je typ zprávy Session Confirmed, jedná se o dlouhé záhlaví.

  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) Pokud je typ zprávy platný, ale není Session Confirmed,

  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) (volitelné) Pokud je ID připojení čekající příchozí relace

  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) Pokud selže b) nebo c), zprávu zahoď.

2. Pokud ID připojení neodpovídá aktuální relaci: Zkontrolujte, zda je plaintext hlavička na bytech 8-15 platná (bez provádění jakékoli operace ochrany hlavičky). Ověřte, zda jsou net ID a verze protokolu platné, a typ zprávy je Session Request, nebo jiný typ zprávy povolený mimo relaci (TBD).

a) Pokud je vše platné a typ zprávy je Session Request,

  decrypt bytes 16-31 of the header and the 32-byte X value
  with ChaCha20 using the local intro key.

• Pokud je token v hlavičce na bytech 24-31 přijat, pak proveďte MixHash() na dešifrovanou 32bajtovou hlavičku a dešifrujte zprávu pomocí Noise. Odešlete v odpovědi Session Created.
• Pokud token není přijat, odešlete zprávu Retry na zdrojovou IP/port s tokenem. Nepokoušejte se dešifrovat zprávu pomocí Noise, abyste předešli DDoS útokům.

b) Pokud je typ zprávy nějaká jiná zpráva, která je platná

  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) Pokud a) nebo b) selže, přejděte ke kroku 3)

3. Vyhledejte čekající odchozí relaci podle zdrojové IP/portu paketu.

a) Pokud je nalezen, znovu dešifrovat prvních 8 bytů pomocí ChaCha20 s použitím Bobova introduction key

  to recover the Destination Connection ID.

b) Pokud ID připojení odpovídá čekající relaci:

  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).

• Pokud je vše platné a typ zprávy je Session Created, dešifruj dalších 16 bajtů hlavičky a 32-bajtovou hodnotu Y pomocí ChaCha20 s použitím Bobova intro klíče. Poté proveď MixHash() na dešifrované 32-bajtové hlavičce a dešifruj zprávu pomocí Noise. Pošli Session Confirmed jako odpověď.

  • Pokud je vše platné a typ zprávy je Retry, dešifruj bajty 16-31 hlavičky pomocí ChaCha20 s použitím Bobova intro klíče. Dešifruj a validuj zprávu pomocí ChaCha20/Poly1305 s použitím TBD jako klíč a TBD jako nonce a dešifrovanou 32-bajtovou hlavičku jako AD. Znovu pošli Session Request s přijatým tokenem jako odpověď.
  • Pokud je typ zprávy nějaká jiná zpráva, která je platná mimo relaci, pravděpodobně s krátkou hlavičkou, dešifruj zbytek zprávy pomocí ChaCha20/Poly1305 s použitím intro klíče a s použitím dešifrované 16-bajtové hlavičky jako AD. Zpracuj zprávu.

  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. Pokud běží SSU 1 na stejném portu, pokusit se zpracovat zprávu jako SSU 1 paket.

Error Handling

Obecně by relace (ve fázi handshake nebo dat) nikdy neměla být zničena po přijetí paketu s neočekávaným typem zprávy. Toto zabraňuje útokům typu packet injection. Tyto pakety budou také běžně přijímány po retransmisi handshake paketu, kdy dešifrovací klíče hlavičky již nejsou platné.

Ve většině případů jednoduše zahoďte paket. Implementace může, ale není povinná, znovu odeslat dříve odeslaný paket (handshake zprávu nebo ACK 0) jako odpověď.

Po odeslání Session Created jako Bob jsou neočekávané pakety obvykle Data pakety, které nelze dešifrovat, protože Session Confirmed pakety byly ztraceny nebo došly mimo pořadí. Zařaďte pakety do fronty a pokuste se je dešifrovat až po přijetí Session Confirmed paketů.

Po obdržení Session Confirmed jako Bob jsou neočekávané pakety běžně retransmitované pakety Session Confirmed, protože ACK 0 paketu Session Confirmed bylo ztraceno. Neočekávané pakety mohou být zahozeny. Implementace může, ale není povinna, v odpovědi odeslat paket Data obsahující blok ACK.

Notes

Pro Session Created a Session Confirmed musí implementace pečlivě validovat všechna dešifrovaná pole hlavičky (Connection ID, číslo paketu, typ paketu, verzi, id, frag a flags) PŘED voláním mixHash() na hlavičku a pokusem o dešifrování payload pomocí Noise AEAD. Pokud dešifrování Noise AEAD selže, nesmí být provedeno žádné další zpracování, protože mixHash() by poškodil stav handshake, pokud implementace neuloží a “nevrátí” stav hash.

Version Detection

Nemusí být možné efektivně detekovat, zda příchozí pakety jsou verze 1 nebo 2 na stejném příchozím portu. Výše uvedené kroky může být rozumné provést před zpracováním SSU 1, aby se zabránilo pokusům o zkušební DH operace pomocí obou verzí protokolu.

Bude určeno podle potřeby.

Recommended Constants

• Timeout pro retransmisi odchozího handshake: 1,25 sekundy, s exponenciálním backoff (retransmise na 1,25, 3,75 a 8,75 sekundy)
• Celkový timeout odchozího handshake: 15 sekund
• Timeout pro retransmisi příchozího handshake: 1 sekunda, s exponenciálním backoff (retransmise na 1, 3 a 7 sekund)
• Celkový timeout příchozího handshake: 12 sekund
• Timeout po odeslání opakování: 9 sekund
• ACK zpoždění: max(10, min(rtt/6, 150)) ms
• Okamžité ACK zpoždění: min(rtt/16, 5) ms
• Max ACK rozsahy: 256?
• Max ACK hloubka: 512?
• Distribuce paddingu: 0-15 bytů, nebo více

Variants, Fallbacks, and General Issues

TBD

Packet Overhead Analysis

Předpokládá IPv4, nezahrnuje dodatečné doplnění, nezahrnuje velikosti IP a UDP hlaviček. Doplnění je mod-16 doplnění pouze pro SSU 1.

SSU 1