SSU2

Stav

Plán nasazení:

Základní relace zahrnuje handshake a datovou fázi. Rozšířený protokol zahrnuje relé a test protějšku.

Přehled

Tento návrh popisuje protokol ověřené dohody o klíči, který zlepšuje odolnost SSU proti různým formám automatické identifikace a útokům.

Návrh je uspořádán následovně: nejprve jsou uvedeny bezpečnostní cíle, následuje diskuse o základním protokolu. Poté je uvedena úplná specifikace všech zpráv protokolu. Nakonec jsou diskutovány adresy směrovače a identifikace verze.

Stejně jako u jiných přenosů I2P je SSU2 definován pro bodové připojení (směrovač na směrovač) přenosu zpráv I2NP. Není to univerzální datová trubka. Stejně jako SSU také poskytuje dvě další služby: Relé pro průchod NAT a test protějšku pro určení dosažitelnosti směrem dovnitř. Poskytuje také třetí službu, která není v SSU, pro migraci připojení, když protějšek změní IP nebo port.

Motivace

SSU je jediná zbývající vrstva protokolu, která vyžaduje ElGamal, což je velmi pomalé. Řízení toku pro SSU je složité a nefunguje dobře. Části SSU jsou náchylné k útokům typu spoofing adres. Handshake nepoužívá Noise.

Cíle návrhu

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

• Zachovat funkce testu protějšku a relé a zvýšit jejich bezpečnost.

• Umožnit snazší implementaci tím, že umožní použití standardních algoritmů řízení toku.

• Snížit latenci nastavení. Mediánová doba nastavení je aktuálně asi 135 ms pro NTCP2 a 187 ms pro SSU, i když NTCP2 má dodatečnou výměnu zpráv; nahrazení ElGamal v SSU2 by to mělo snížit, ale mohou pomoci i jiné změny.

• Zachovat nebo zvýšit maximální propustnost ve srovnání s SSU 1, měřeno v rámci rozsahu simulovaných latencí a procent ztráty paketů na testovací síti.

• Zabránit útokům typu amplifikace provozu a špatného směrování z důvodu spoofing adresy prostřednictvím „ověření adresy“.

• Umožnit snazší identifikaci paketů, aby se snížila závislost na záložních mechanismech a heuristikách, které způsobují příliš složitý kód.

• Formalizovat a zlepšit migraci připojení, když protějšek změní IP nebo port. Neprovádět migraci připojení, dokud není ověření adresy dokončeno, aby se zabránilo útokům. Některé implementace SSU 1 používají nákladné heuristiky ke zpracování změn portu kvůli opětovnému navázání NAT. Žádná známá implementace SSU 1 nemůže zpracovat změny IP vůbec.

• Podporovat SSU 1 a 2 na jednom portu, automatické zjištění a publikování jako jediného „přenosu“ (tj. RouterAddress) v NetDB .

• Publikovat podporu verze 1 pouze, 2 pouze, nebo 1+2 v NetDB v samostatném poli a výchozí nastavení na verzi 1 pouze (nezáviset podporu verze na konkrétní verzi směrovače)

• Zajistit, aby všechny implementace (Java/i2pd/Go) mohly přidat podporu verze 2 (nebo ne) podle svého vlastního plánu

• Přidat náhodné doplňování do všech zpráv včetně handshake a datových zpráv. Všechno doplňování musí být pokryto MAC, na rozdíl od doplňování na konci paketu v SSU 1. Poskytnout mechanismus možností pro obě strany, aby požadovaly minimální a maximální doplňování a/nebo distribuci doplňování. Konkrétní detaily distribuce doplňování jsou závislé na implementaci a mohou být nebo nemusí být specifikovány v protokolu sám o sobě.

• Zamaskovat hlavičky a obsah zpráv, které nejsou plně šifrovány, dostatečně, aby DPI boxy a podpisy AV nemohly snadno klasifikovat. Také zajistit, aby zprávy směřující k jednomu protějšku nebo sadě protějšků neměly podobný vzor bitů.

• Opravit ztrátu bitů v DH kvůli formátu Java Ticket1112 a zrychlit DH přepnutím na X25519.

• Přepnout na skutečnou funkci odvození klíče (KDF) namísto použití výsledku DH tak jak je

• Přidat „odolnost proti prohledávání“ (jak to nazývá Tor); to zahrnuje odolnost proti opakování.

• Zachovat dvoucestnou ověřenou výměnu klíčů (2W-AKE). 1W-AKE nestačí pro naši aplikaci.

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

• Přidat možnosti/verzi v handshake pro budoucí rozšiřitelnost.

• Nezvyšovat významně CPU požadované pro nastavení připojení; pokud je možné, snížit to významně.

• Odstranit požadavek na doplňování na násobek 16 bajtů vynucený šifrováním AES v SSU 1.

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

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

• Použít handshake se 3 zprávami, jednou výměnou zpráv, jako v NTCP2 . Odstranit zpoždění čekání na datové zprávy, které způsobuje, že SSU je efektivně handshake se dvěma výměnami zpráv.

• Výrazně zlepšit efektivitu potvrzení a negativních potvrzení, což je hrozné v SSU 1. Snížit šířku pásma potřebnou pro potvrzení a negativní potvrzení a zvýšit velikost paketu dostupnou pro data. Efektivně kódovat negativní potvrzení pro výbuch chybějících zpráv, což je běžné přes WiFi.

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

• Minimalizovat režii protokolu před doplňováním, zejména pro potvrzení. I když bude přidáno doplňování, režie před doplňováním je stále režie. Směrovače s nízkou šířkou pásma musí být schopny používat SSU2.

• Zachovat časová razítka pro detekci opakování a posunu.

• Vyhnout se jakýmkoli problémům s rokem 2038 v časových razítkách, musí fungovat alespoň do roku 2106.

• Zvýšit minimální MTU z 620 na 1280 pro efektivitu, snadnost implementace a zvýšení maximální velikosti zprávy I2NP. Fragmentace a reasemble jsou velmi nákladné. Poskytnutím prostoru pro 1028 bajtové zprávy tunelu bude většina zpráv I2NP nepotřebovat fragmentaci.

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

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

• Odstranit podpis polí IP a port v handshake, aby směrovače, které neznají svou externí IP a port, mohly připojit.

• Zachovat mechanismus zjištění IP/port z SSU 1 v handshake, aby směrovače mohly zjistit svou externí IP a port.

• Zahrnout zástupce vývojářů směrovačů Java, C++ a Go do návrhu.

Není cílem

• Dokonalá odolnost proti DPI… to by byly připojitelné přenosy, Návrh 109 .

• Přenos založený na TLS (nebo podobný HTTPS)… to by byl Návrh 104 .

• Odolnost proti DPI založená na časování (časování/delays mezi zprávami může být závislé na implementaci; delays uvnitř zpráv mohou být zavedeny kdekoli, včetně před odesláním náhodného doplňování, například). Umělé delays (což obfs4 nazývá IAT nebo inter-arrival time) jsou nezávislé na samotném protokolu.

• Zamítnutí účasti v relaci (tam jsou podpisy).

Není cílem, co může být částečně znovu zváženo nebo diskutováno:

• Stupeň ochrany proti hloubkové kontrole paketů (DPI)

• Bezpečnost post-kvantové (PQ)

• Zamítnutí

Bezpečnostní cíle

Uvažujeme tři strany:

• Alice, která si přeje vytvořit novou relaci.
• Bob, s nímž Alice si přeje vytvořit relaci.
• Mallory, „muž uprostřed“ mezi Alicí a Bobem.

Nejvýše dva účastníci mohou účastnit v aktivních útocích.

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

Navrhovaný protokol se snaží 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 soukromého klíče: ani Bob ani Mallory se nedozví nic o Alicině statickém soukromém klíči. Symetricky, Alice se nedozví nic o Bobově statickém soukromém klíči.

2. Sdílený klíč K je znám pouze Alici a Bobovi.

3. Dokonalá předchozí tajnost: dohodnutý relační klíč zůstává tajný v budoucnu, i když statické soukromé klíče Alice a/nebo Boba budou odhaleny po dohodnutí klíče.

4. Dvoucestné ověření: Alice je si jistá, že vytvořila relaci s Bobem, a naopak.

5. Ochrana proti online DPI: Zajistit, že není triviální detekovat, že Alice a Bob se účastní protokolu pouze pomocí přímých technik hloubkové kontroly paketů (DPI). Viz níže.

6. Omezené zamítnutí: ani Alice ani Bob nemohou zamítnout účast v protokolu, ale pokud někdo z nich zveřejní sdílený klíč, druhá strana může zamítnout autentičnost obsahu přenášených dat.

Současný návrh se snaží poskytnout všech pět požadavků na základě protokolu Station-To-Station (STS) protokol Station-To-Station (STS) protokol. Všimněte si, že tento protokol je také základem pro SSU protokol.

Další diskuse o DPI

Předpokládáme dva komponenty DPI:

Online DPI

Online DPI kontroluje všechny toky v reálném čase. Připojení mohou být blokována nebo jinak narušována. Data nebo metadata připojení mohou být identifikována a uložena pro offline analýzu. Online DPI nemá přístup k síťové databázi I2P. Online DPI má pouze omezené reálné výpočetní možnosti v reálném čase, včetně výpočtu délky, inspekce 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 hašování, ale ty by byly příliš nákladné na použití na většině nebo všech tocích. Jakékoli použití těchto kryptografických operací by se vztahovalo pouze na toky na kombinacích IP/Port, které byly dříve identifikovány offline analýzou. Online DPI nemá schopnost vysokonákladových kryptografických funkcí, jako jsou DH nebo elligator2. Online DPI není navržen speciálně pro detekci I2P, i když může mít omezená klasifikační pravidla pro tento účel.

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

Pojem online nebo „přímé“ DPI je zde brán jako zahrnující následující schopnosti protivníka:

1. Schopnost inspektovat všechna odeslaná nebo přijatá data.

2. Schopnost provádět operace na pozorovaných datech, jako je použití blokových šifer nebo hašovacích 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. Neschopnost mapovat IP adresy na hash směrovače. Zatímco to je triviální s reálným přístupem k síťové databázi, vyžadovalo by to DPI systém speciálně navržený pro cílení na I2P.

6. Neschopnost použít časové informace k detekci protokolu.

7. Obecně řečeno, nástrojová sada online DPI neobsahuje žádné vestavěné nástroje, které jsou speciálně navrženy pro detekci I2P. To zahrnuje vytváření „návnad“, které by například zahrnovaly nedeterministické doplňování ve svých zprávách. Všimněte si, že to nevylučuje systémy strojového učení nebo vysoce konfigurovatelné nástroje DPI, pokud splňují ostatní požadavky.

Pro boj proti analýze obsahu je zajištěno, že všechny zprávy jsou nerozlišitelné od náhodných. To také vyžaduje, aby jejich délka byla náhodná, což je složitější než pouhé přidání náhodného doplňování. Ve skutečnosti v Dodatku A autoři argumentují, že naivní (tj. uniformní) schéma doplňování problém nevyřeší. Dodatek A proto navrhuje zahrnout buď náhodná zpoždění nebo vyvinout alternativní schéma doplňování, které může poskytnout rozumnou ochranu pro navrhovaný útok.

Pro ochranu proti šesté položce 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 doplňování. Shrnutím, návrh poskytuje dobré ochrany proti analýze obsahu (když jsou zohledněny dodatečné úvahy v Dodatku A), ale pouze omezenou ochranu proti analýze toku.

Offline DPI

Offline DPI inspektuje data uložená online DPI pro pozdější analýzu. Offline DPI může být navržen speciálně pro detekci I2P. Offline DPI má reálný přístup k síťové databázi I2P. Offline DPI má přístup k této a jiným specifikacím I2P. 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 stávající připojení. Offline DPI má schopnost provádět téměř v reálném čase (během několika minut od nastavení) odesílání na hostitele/port stran pomocí injektování paketů. Offline DPI má schopnost provádět téměř v reálném čase (během několika minut od nastavení) opakování předchozích zpráv (upravených nebo ne) pro „probing“ nebo jiné důvody.

Není cílem zabránit identifikaci protokolu offline DPI. Všechno dešifrování maskovaných dat ve prvních dvou zprávách, které je implementováno směrovači I2P, může být také implementováno offline DPI.

Cílem je odmítnout pokusy o připojení pomocí opakování předchozích zpráv.

Ověření adresy

Následující je zkopírováno z QUIC RFC 9000 . Pro každou sekci zkontrolujte a upravte.

Ověření adresy zajišťuje, že koncový bod nemůže být použit pro útok amplifikace provozu. V takovém útoku je paket odeslán serveru s padělanými informacemi o zdrojové adrese, které identifikují oběť. Pokud server generuje více nebo větší pakety v reakci na tento paket, ú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.

Hlavní obranou proti útokům amplifikace je ověření, že protějšek je schopen přijímat pakety na transportní adrese, kterou uvádí. Proto po přijetí paketů z adresy, která ještě nebyla ověřena, koncový bod MUSÍ omezit množství dat, která odesílá na neověřenou adresu na třikrát větší množství dat přijatých z této adresy. Tento limit velikosti odpovědí je znám jako anti-amplifikace limit.

Ověření adresy se provádí během vytváření připojení (see Section 8.1) a během migrace připojení (see Section 8.2).

Ověření adresy během vytváření připojení

Vytváření připojení implicitně poskytuje ověření adresy pro oba koncové body. Zejména přijetí paketu chráněného klíči handshake potvrzuje, že protějšek úspěšně zpracoval počáteční paket. Jakmile koncový bod úspěšně zpracoval paket handshake od protějšku, může považovat adresu protějšku za ověřenou.

Navíc koncový bod MŮŽE považovat adresu protějšku za ověřenou, pokud protějšek používá ID připojení vybrané koncovým bodem a ID připojení obsahuje alespoň 64 bitů entropie.

Pro klienta hodnota pole Cílové ID připojení v jeho prvním počátečním paketu mu umožňuje ověřit adresu serveru jako součást úspěšného zpracování jakéhokoli paketu. Počáteční pakety ze serveru jsou chráněny klíči, které jsou odvozeny z této hodnoty (see Section 5.2 of QUIC-TLS ). Alternativně je hodnota opakována serverem v paketech Verze Negotiation (Section 6) nebo zahrnuta v Integrity Tag v paketech Retry (Section 5.8 of QUIC-TLS ).

Před ověřením adresy klienta servery NESMÍ odesílat více než třikrát tolik bajtů, kolik bajtů obdržely. To omezuje velikost jakéhokoli útoku amplifikace, který může být proveden pomocí padělaných zdrojových adres. Za účelem vyhnutí se amplifikaci před ověřením adresy servery MUSÍ počítat všechny bajty dat přijaté v datagramech, které jsou jednoznačně přiřazeny jednomu připojení. To zahrnuje datagramy obsahující pakety, které jsou úspěšně zpracovány, a datagramy obsahující pakety, které jsou všechny zahozeny.

Klienti MUSÍ zajistit, aby UDP datagramy obsahující počáteční pakety měly UDP datové části alespoň 1200 bajtů, přidáním polí PADDING podle potřeby. Klient, který odesílá doplněné datagramy, umožňuje serveru odeslat více dat před dokončením ověření adresy.

Ztráta počátečního nebo handshake paketu ze serveru může způsobit zablokování, pokud klient neodesílá další počáteční nebo handshake pakety. Zablokování by mohlo nastat, když server dosáhne svého anti- amplifikace limitu a klient obdržel potvrzení pro všechna data, která odeslal. V tomto případě, když klient nemá důvod k odeslání dalších paketů, server nebude moci odeslat více dat, protože neověřil adresu klienta. Aby se tomu zabránilo, klienti MUSÍ odeslat paket při Probe Timeout (PTO); viz Section 6.2 of QUIC-RECOVERY . Konkrétně klient MUSÍ odeslat počáteční 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 počátečním paketu k poskytnutí ověření adresy před dokončením handshake. Tento token je doručen klientovi během vytváření připojení s paketem Retry (see Section 8.1.2) nebo v předchozím připojení pomocí rámce NEW_TOKEN (see Section 8.1.3).

Kromě odesílacích limitů uvalených před ověřením adresy jsou servery také omezeny tím, co mohou odeslat, limity nastavené řízením přetížení. Klienti jsou omezeni pouze řízením přetížení.

Konstrukce tokenu

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

Ověření adresy pomocí paketů Retry

Po přijetí počátečního paketu klienta může server požadovat ověření adresy odesláním paketu Retry (Section 17.2.5) obsahující token. Tento token MUSÍ být opakován klientem ve všech počátečních paketech, které odesílá pro toto připojení po přijetí paketu Retry.

V reakci na zpracování počátečního paketu obsahujícího token, který byl poskytnut v paketu Retry, server nemůže odeslat další paket Retry; může pouze odmítnout připojení nebo jej povolit pokračovat.

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

Server může také použít paket Retry k odložení stavu a nákladů na zpracování vytváření připojení. Vyžadování, aby server poskytl jiné ID připojení, spolu s původním_destination_connection_id transportním parametrem definovaným v Section 18.2, donutí server prokázat, že on, nebo entita, se kterou spolupracuje, obdržela původní počáteční paket od klienta. Poskytnutí jiného ID připojení také poskytuje serveru nějakou kontrolu nad tím, jak jsou následné pakety směrovány. To může být použito k přesměrování připojení na jinou instanci serveru.

Pokud server obdrží počáteční paket klienta obsahující neplatný Retry token, ale jinak je platný, ví, že klient nebude přijímat další Retry token. Server může takový paket zahodit a umožnit klientovi vypršet časový limit, aby detekoval selhání handshake, ale to by mohlo způsobit významnou latenci klientovi. Místo toho by měl server okamžitě uzavřít (Section 10.2) připojení s chybou INVALID_TOKEN. Všimněte si, že server nezavedl žádný stav pro připojení v tomto okamžiku a proto nevstupuje do uzavíracího období.

Tok ukazující použití paketu Retry je zobrazen 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

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

Server MŮŽE poskytnout klientům token pro ověření adresy během jednoho připojení, který může být použit pro následné připojení. Ověření adresy je obzvláště důležité s 0-RTT, protože server potenciálně odesílá významné množství dat klientovi v reakci na data 0-RTT.

Server používá rámec NEW_TOKEN (Section 19.7) k poskytnutí klientovi tokenu pro ověření adresy, který může být použit k ověření budoucích připojení. V budoucím připojení klient zahrne tento token v počátečních paketech k poskytnutí ověření adresy. Klient MUSÍ zahrnout token ve všech počátečních paketech, které odesílá, pokud Retry nezamění token za novější. Klient NESMÍ použít token poskytnutý v Retry pro budoucí připojení. Servery MŮŽOU zahodit jakýkoli počáteční paket, který nepřenáší očekávaný token.

Na rozdíl od tokenu vytvořeného pro paket Retry, který se používá ihned, token odeslaný ve frame NEW_TOKEN může být použit po nějakém čase. Proto by měl mít token dobu expirace, která může být buď explicitní čas expirace nebo vydané časové razítko, které lze použít k dynamickému výpočtu doby expirace. Server může uložit dobu expirace nebo ji zahrnout do šifrované formy v tokenu.

Token vydaný s NEW_TOKEN NESMÍ obsahovat informace, které by umožnily propojit hodnoty pozorovatelem s připojením, na kterém byl vydán. Například nemůže obsahovat předchozí ID připojení nebo informace o adresách, pokud hodnoty nejsou zašifrovány. Server MUSÍ zajistit, že každý frame NEW_TOKEN, který odesílá, je jedinečný pro všechny klienty, s výjimkou těch odeslaných k opravě ztrát dříve odeslaných frame NEW_TOKEN. Informace, které umožňují serveru rozlišovat mezi tokeny z Retry a NEW_TOKEN MŮŽOU být přístupné entitám jiným než serveru.

Je nepravděpodobné, že číslo portu klienta bude stejné na dvou různých připojeních; ověření portu proto pravděpodobně nebude úspěšné.

Token přijatý ve frame NEW_TOKEN je aplikovatelný na jakéhokoli servera, který je považován za autoritativní pro připojení (např. názvy serverů zahrnuté v certifikátu). Při připojování k serveru, pro který klient uchovává aplikovatelný a nepoužitý token, by MĚL zahrnout tento token do pole Token svého počátečního paketu. Zahrnutí tokenu by mohlo umožnit serveru ověřit adresu klienta bez dodatečné výměny zpráv. Klient NESMÍ zahrnout token, který není aplikovatelný na server, ke kterému se připojuje, pokud klient nemá znalost, že server, který vydal token, 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 připojení k tomuto 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í frame NEW_TOKEN. Ve srovnání s tokenem získaným v paketu Retry MUSÍ být použit ihned během pokusu o připojení a nemůže být použit v následných pokusech o připojení.

Klient by NESMĚL opakovaně používat token z frame NEW_TOKEN pro různé pokusy o připojení. Opakované použití tokenu umožňuje propojení připojení entitami na cestě sítě; viz Section 9.5.

Klienti mohou obdržet více tokenů na jednom připojení. Kromě zabránění propojitelnosti může být jakýkoli token použit v jakémkoli pokusu o připojení. Servery mohou odesílat další tokeny buď k povolení ověření adresy pro více pokusů o připojení nebo k nahrazení starších tokenů, které by mohly ztratit platnost. Pro klienta znamená tato nejistota, že odeslání nejnovějšího nepoužitého tokenu je nejpravděpodobnější, že bude účinné. I když ukládání a používání starších tokenů nemá žádné negativní důsledky, klienti mohou považovat starší tokeny za méně pravděpodobné, že budou pro server užitečné pro ověření adresy.

Když server obdrží počáteční paket s tokenem pro ověření adresy, MUSÍ se pokusit ověřit token, pokud již nedokončil ověření adresy. Pokud je token neplatný, pak by měl server pokračovat, jako by klient neměl ověřenou adresu, včetně možnosti odeslání paketu Retry. Tokeny poskytnuté s frame NEW_TOKEN a pakety Retry mohou být rozlišeny servery (viz Section 8.1.1), a posledně jmenované mohou být ověřeny přísněji. Pokud ověření uspěje, server by MĚL pak umožnit handshake pokračovat.

Poznámka: Důvodem pro považování klienta za neověřeného spíše než zahození paketu je, že klient mohl obdržet token v předchozím připojení pomocí frame NEW_TOKEN, a pokud server ztratil stav, mohl by být nemohl ověřit token vůbec, což by vedlo k selhání připojení, pokud by byl paket zahozen.

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

Klienti MŮŽOU používat tokeny získané na jednom připojení pro jakýkoli pokus o připojení pomocí stejné verze. Při výběru tokenu k použití klienti nemusí uvažovat o jiných vlastnostech připojení, které se pokouší, včetně výběru možných aplikačních protokolů, lístků relací nebo jiných vlastností připojení.

Integrity tokenu pro ověření adresy

Token pro ověření adresy MUSÍ být obtížný uhodnout. Zahrnutí náhodné hodnoty s alespoň 128 bity entropie v tokenu by bylo dostačující, ale to závisí na serveru, který si pamatuje hodnotu, kterou odesílá klientům.

Schéma založené na tokenu umožňuje serveru přesunout jakýkoli stav spojený s ověřením na klienta. Aby tento design fungoval, MUSÍ být token pokryt ochranou integrity proti modifikaci nebo falšování klienty. Bez ochrany integrity by mohli zlomyslní klienti generovat nebo hádat hodnoty pro tokeny, které by byly přijaty serverem. Pouze server vyžaduje přístup k klíči ochrany integrity pro tokeny.

Není potřeba jednoznačný formát pro token, protože server, který generuje token, jej také spotřebovává. Tokeny odeslané v paketech Retry by MĚLY zahrnovat informace, které umožní serveru ověřit, že zdrojová IP adresa a port v paketech klienta zůstávají konstantní.

Tokeny odeslané ve frame NEW_TOKEN MUSÍ zahrnovat informace, které umožní serveru ověřit, že IP adresa klienta se nezměnila od doby, kdy byl token vydán. Servery mohou použít tokeny z NEW_TOKEN ve rozhodování, zda neodeslat paket Retry, i když se adresa klienta změnila. Pokud se IP adresa klienta změnila, server MUSÍ dodržet anti-amplifikace limit; viz Section 8. Všimněte si, že v přítomnosti NAT by tento požadavek mohl být nedostačující k ochraně jiných hostitelů, kteří sdílejí NAT před útoky amplifikace.

Útočníci by mohli opakovat tokeny, aby použili servery jako zesilovače v útocích DDoS. Aby se tomu zabránilo, servery MUSÍ zajistit, že opakování tokenů je zabráněno nebo omezeno. Servery by MĚLY zajistit, že tokeny odeslané v paketech Retry jsou přijímány pouze po krátkou dobu, protože jsou okamžitě vráceny klienty. Tokeny, které jsou poskytnuty ve frame NEW_TOKEN (Section 19.7) potřebují být platné déle, ale NESMĚJÍ 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 MŮŽOU zahrnovat další informace o klientech, aby dále omezily použitelnost nebo opakované použití.

Ověření cesty

Ověření cesty je používáno oběma protějšky během migrace připojení (see Section 9) k ověření dosažitelnosti po změně adresy. Při ověřování cesty koncové body testují dosažitelnost mezi konkrétní místní adresou a konkrétní adresou protějšku, kde adresa je 2-tice IP adresy a portu.

Ověření cesty testuje, že pakety odeslané po cestě k protějšku jsou přijímány tímto protějškem. Ověření cesty je používáno k zajištění, že pakety přijaté od migrujícího protějšku nenesou padělanou zdrojovou adresu.

Ověření cesty neověřuje, že protějšek může odesílat v opačném směru. Potvrzení nemohou být použita pro ověření návratové cesty, protože obsahují nedostatečnou entropii a mohou být padělaná. Koncové body nezávisle určují dosažitelnost v každém směru cesty, a proto návratová dosažitelnost může být založena pouze protějškem.

Ověření cesty může být použito kdykoli kterýmkoli koncovým bodem. Například koncový bod může zkontrolovat, že protějšek stále vlastní svou adresu po období klidu.

Ověření cesty není navrženo jako mechanismus pro průchod NAT. I když mechanismus popsaný zde může být efektivní pro vytvoření vazeb NAT, které podporují průchod NAT, očekává se, že jeden koncový bod bude schopen přijímat pakety bez nutnosti nejprve odeslat paket po této cestě. Efektivní průchod NAT vyžaduje další synchronizační mechanismy, které zde nejsou poskytovány.

Koncový bod MŮŽE zahrnovat jiné rámce s rámci PATH_CHALLENGE a PATH_RESPONSE používanými pro ověření cesty. Zejména koncový bod může zahrnovat rámce PADDING s rámcem PATH_CHALLENGE pro Zjišťování maximální přenosové jednotky cesty (PMTUD); viz Section 14.2.1. Koncový bod může také zahrnovat vlastní rámec PATH_CHALLENGE při odesílání rámcu PATH_RESPONSE.

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

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

Zahájení ověření cesty

Pro zahájení ověření cesty koncový bod odesílá rámec PATH_CHALLENGE obsahující nepředvídatelnou datovou část po cestě, která má být ověřena.

Koncový bod MŮŽE odeslat více rámců PATH_CHALLENGE pro ochranu proti ztrátě paketů. Nicméně koncový bod by NESMĚL odesílat více rámců PATH_CHALLENGE v jednom paketu.

Koncový bod by NESMĚL sondovat novou cestu pakety obsahující rámec PATH_CHALLENGE častěji, než by odesílal počáteční paket. To zajišťuje, že migrace připojení zatěžuje novou cestu ne více než vytvoření nového připojení.

Koncový bod MUSÍ použít nepředvídatelná data v každém rámcu PATH_CHALLENGE, aby mohl spojit odpověď protějšku s odpovídajícím PATH_CHALLENGE.

Koncový bod MUSÍ rozšířit datagramy, které obsahují rámec PATH_CHALLENGE, na alespoň nejmenší povolenou maximální velikost datagramu 1200 bajtů, pokud anti-amplifikace limit pro cestu neumožňuje odeslání datagramu této velikosti. Odesílání UDP datagramů této velikosti zajišťuje, že síťová cesta od koncového bodu k protějšku může být použita pro QUIC; viz Section 14.

Když koncový bod není schopen rozšířit velikost datagramu na 1200 bajtů kvůli anti-amplifikace limitu, MTU cesty nebude ověřeno. Aby se zajistilo, že MTU cesty je dostatečně velké, koncový bod MUSÍ provést druhé ověření cesty odesláním rámcu PATH_CHALLENGE v datagramu alespoň 1200 bajtů. Toto dodatečné ověření může být provedeno po úspěšném přijetí PATH_RESPONSE nebo když je přijato dostatečné množství bajtů na cestě, aby odeslání většího datagramu nevedlo k překročení anti- amplifikace limitu.

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

Odpovědi na ověření cesty

Po přijetí rámcu PATH_CHALLENGE koncový bod MUSÍ reagovat opakováním dat obsažených v rámcu PATH_CHALLENGE v rámcu PATH_RESPONSE. Koncový bod NESMÍ zpožďovat přenos paketu obsahujícího rámec PATH_RESPONSE, pokud není omezen řízením přetížení.

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 ověření cesty protějškem uspěje pouze v případě, že cesta je funkční v obou směrech. Tento požadavek NESMÍ být vynucen koncovým bodem, který zahajuje ověření cesty, protože by to umožnilo útok na migraci; viz Section 9.3.3.

Koncový bod MUSÍ rozšířit datagramy, které obsahují rámec PATH_RESPONSE, na alespoň nejmenší povolenou maximální velikost datagramu 1200 bajtů. To ověřuje, že cesta je schopna přenášet datagramy této velikosti v obou směrech. Nicméně koncový bod NESMÍ rozšířit datagram obsahující PATH_RESPONSE, pokud by výsledná data překročila anti-amplifikace limit. To se očekává, že nastane 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 rámec PATH_RESPONSE v reakci na jeden rámec PATH_CHALLENGE; viz Section 13.3. Protějšek očekává, že pošle více rámců PATH_CHALLENGE podle potřeby, aby vyvolal další rámce PATH_RESPONSE.

Úspěšné ověření cesty

Ověření cesty uspěje, když je přijat rámec PATH_RESPONSE, který obsahuje data odeslaná v předchozím rámcu PATH_CHALLENGE. Rámec PATH_RESPONSE přijatý na jakékoli síťové cestě ověřuje cestu, po které byl odeslán rámec PATH_CHALLENGE.

Pokud koncový bod odesílá rámec PATH_CHALLENGE v datagramu, který není rozšířen na alespoň 1200 bajtů a pokud odpověď na něj ověří adresu protějšku, cesta je ověřena, ale ne MTU cesty. V důsledku toho koncový bod nyní může odesílat více než třikrát tolik dat, která byla přijata. Nicméně koncový bod MUSÍ zahájit další ověření cesty s rozšířeným datagramem, aby ověřil, že cesta podporuje požadované MTU.

Přijetí potvrzení pro paket obsahující rámec PATH_CHALLENGE není dostatečné ověření, protože potvrzení může být padělané zlomyslným protějškem.

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

Ověření cesty selže pouze v případě, že koncový bod, který se pokouší ověřit cestu, zanechá svůj pokus o ověření cesty.

Koncové body by MĚLY zanechat ověření cesty na základě časovače. Při nastavování tohoto časovače implementace jsou upozorněny, že nová cesta by mohla mít delší dobu kola než původní. Doporučuje se hodnota třikrát větší než větší z aktuálního PTO nebo PTO pro novou cestu (pomocí kInitialRtt, jak je definováno v QUIC-RECOVERY ).

Tento časový limit umožňuje vypršení více PTO před selháním ověření cesty, takže ztráta jednoho rámcu PATH_CHALLENGE nebo PATH_RESPONSE nezpůsobí selhání ověření cesty.

Všimněte si, že koncový bod může přijímat pakety obsahující jiné rámce na nové cestě, ale pro úspěšné ověření cesty je vyžadován rámec PATH_RESPONSE s příslušnými daty.

Když koncový bod zanechá ověření cesty, určí, že cesta je nepoužitelná. To nutně neznamená selhání připojení – 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 uzavřít připojení. Koncový bod, který nemá platnou síťovou cestu ke svému protějšku, MŮŽE to signalizovat pomocí chyby připojení NO_VIABLE_PATH, s tím, že to je možné pouze v případě, že síťová cesta existuje, ale nepodporuje požadované MTU (Section 14).

Ověření cesty může být zanecháno z jiných důvodů než selhání. Zejména k tomu dochází, pokud je zahájena migrace připojení na novou cestu, zatímco probíhá ověření cesty na staré cestě.

Migrace připojení

Následující je zkopírováno z QUIC RFC 9000 . Pro každou sekci zkontrolujte a upravte.

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 na novou síť. Tato sekce popisuje proces, jakým koncový bod migruje na novou adresu.

Návrh QUIC spoléhá na to, že koncové body si zachovají stabilní adresu po dobu handshake. Koncový bod NESMÍ zahájit migraci připojení před potvrzením handshake, jak je definováno v Section 4.1.2 of QUIC-TLS .

Pokud protějšek poslal transportní parametr disable_active_migration, koncový bod také NESMÍ odesílat pakety (včetně sondovacích paketů; viz Section 9.1) z jiné místní adresy na adresu, kterou protějšek použil během handshake, pokud koncový bod nejednal na transportním parametru preferred_address od protějšku. Pokud protějšek poruší tento požadavek, koncový bod MUSÍ buď zahodit příchozí pakety na této cestě bez generování Stateless Reset nebo pokračovat v ověření cesty a umožnit protějškovi migrovat. Generování Stateless Reset nebo uzavření připojení by umožnilo třetím stranám v síti uzavřít připojení tím, že padělají nebo jinak manipulují s pozorovaným provozem.

Ne všechny změny adresy protějšku jsou záměrné, nebo aktivní, migrace. Protějšek by mohl zažít opětovné navázání NAT: změnu adresy způsobenou middleboxem, obvykle NAT, který přiděluje nový odchozí port nebo dokonce novou odchozí IP adresu pro tok. Koncový bod MUSÍ provést ověření cesty (Section 8.2), pokud zjistí jakoukoli změnu adresy protějšku, pokud již dříve neověřil tuto adresu.

Když koncový bod nemá ověřenou cestu, po které by mohl odesílat pakety, MŮŽE zahodit stav připojení. Koncový bod schopný migrace připojení MŮŽE počkat na dostupnost nové cesty před zahozením stavu připojení.

Tento dokument omezuje migraci připojení na nové klientské adresy, s výjimkou popsané v Section 9.6. Klienti jsou zodpovědní za zahájení všech migrací. Servery neodesílají neprobingové pakety (viz Section 9.1) směrem ke klientské adrese, dokud neuvidí neprobingový paket z této adresy. Pokud klient obdrží pakety z nezn