Tento překlad byl vytvořen pomocí strojového učení a nemusí být 100% přesný. Zobrazit anglickou verzi

Přehled I2CP

Přehled I2P klientského protokolu (I2CP) – správa relací, možnosti, formát užitečného zatížení a multiplexování.

Přehled

I2P Client Protocol (I2CP) umožňuje silné oddělení odpovědností mezi směrovačem a libovolným klientem, který si přeje komunikovat přes síť. Zajišťuje bezpečnou a asynchronní výměnu zpráv prostřednictvím odesílání a příjmu zpráv přes jediné TCP spojení. Pomocí I2CP klientová aplikace sděluje směrovači, kým je (svou „cílovou adresou“), jaké kompromisy mezi anonymitou, spolehlivostí a latencí mají být zvoleny, a kam mají být zprávy posílány. Naopak směrovač prostřednictvím I2CP informuje klienta o příchozích zprávách a požaduje autorizaci pro použití některých tunelů.

Samotný protokol je implementován v jazyce Java, aby poskytoval klientskou SDK. Tato SDK je zpřístupněna v balíčku i2p.jar, který implementuje klientskou stranu I2CP. Klienti by nikdy neměli potřebovat přístup k balíčku router.jar, který obsahuje samotný směrovač a stranu směrovače I2CP. Klient, který nepoužívá Java, by také musel implementovat streamovací knihovnu pro TCP-style spojení.

Aplikace mohou využívat základní I2CP spolu s knihovnami pro streamování a datagramy pomocí protokolu Simple Anonymous Messaging (SAM) , který od klientů nevyžaduje práci s žádným druhem kryptografie. Klienti mohou také přistupovat k síti prostřednictvím několika typů proxy – HTTP, CONNECT a SOCKS 4/4a/5. Alternativně mohou klienti v Javě přistupovat k těmto knihovnám přes ministreaming.jar a streaming.jar. Existuje tedy několik možností jak pro aplikace v Javě, tak pro aplikace v jiných jazycích.

Šifrování typu end-to-end na straně klienta (šifrování dat přes I2CP připojení) bylo zakázáno v I2P verzi 0.6, přičemž bylo ponecháno end-to-end šifrování pomocí ElGamal/AES, které je implementováno v routeru. Jedinou kryptografií, kterou musí klientské knihovny stále implementovat, je podepisování veřejných a soukromých klíčů DSA pro LeaseSet a konfigurace relace , a správa těchto klíčů.

Ve standardní instalaci I2P se port 7654 používá pro komunikaci externích Java klientů s místním směrovačem přes I2CP. Ve výchozím nastavení se směrovač váže na adresu 127.0.0.1. Chcete-li se vázat na 0.0.0.0, nastavte pokročilou konfigurační možnost směrovače i2cp.tcp.bindAllInterfaces=true a restartujte směrovač. Klienti běžící ve stejném JVM jako směrovač předávají zprávy přímo směrovači přes interní rozhraní JVM.

Některé implementace směrovače a klienta mohou podporovat také externí připojení přes SSL, jak je nakonfigurováno volbou i2cp.SSL=true. I když SSL není výchozí, doporučuje se jej používat pro veškerý provoz, který může být vystaven otevřenému Internetu. Uživatelské jméno a heslo pro autorizaci (pokud je použito), soukromý klíč a klíč pro podepisování pro cíl jsou všechny přenášeny v otevřené podobě, pokud není SSL povoleno. Některé implementace směrovače a klienta mohou podporovat také externí připojení přes doménové sokety.

Specifikace protokolu I2CP

Kompletní specifikaci protokolu najdete na stránce specifikace I2CP .

Inicializace I2CP

Když se klient připojí k routeru, nejprve pošle jeden bajt určující verzi protokolu (0x2A). Poté pošle Zprávu GetDate a čeká na odpověď Zprávy SetDate . Následně pošle Zprávu CreateSession obsahující konfiguraci relace. Poté čeká na Zprávu RequestLeaseSet od routeru, která signalizuje, že byly vytvořeny příchozí tunely, a odpoví zprávou CreateLeaseSetMessage obsahující podepsaný LeaseSet. Klient nyní může iniciovat nebo přijímat spojení od jiných cílů v síti I2P.

Možnosti I2CP

Možnosti na straně směrovače

Následující možnosti jsou tradičně předávány routeru prostřednictvím SessionConfig obsažené v zprávě CreateSession Message nebo v zprávě ReconfigureSession Message .

Router-side Options
OptionAs Of ReleaseRecommended ArgumentsAllowable RangeDefaultDescription
clientMessageTimeout8*1000 - 120*100060*1000The timeout (ms) for all sent messages. Unused. See the protocol specification for per-message settings.
crypto.lowTagThreshold0.9.21-12830Minimum number of ElGamal/AES Session Tags before we send more. Recommended: approximately tagsToSend * 2/3
crypto.ratchet.inboundTags0.9.471-?160Inbound tag window for ECIES-X25519-AEAD-Ratchet. Local inbound tagset size. See proposal 144.
crypto.ratchet.outboundTags0.9.471-?160Outbound tag window for ECIES-X25519-AEAD-Ratchet. Advisory to send to the far-end in the options block. See proposal 144.
crypto.tagsToSend0.9.21-12840Number of ElGamal/AES Session Tags to send at a time. For clients with relatively low bandwidth per-client-pair (IRC, some UDP apps), this may be set lower.
explicitPeersnullComma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only
i2cp.dontPublishLeaseSettrue, falsefalseShould generally be set to true for clients and false for servers
i2cp.fastReceive0.9.4true, falsefalseIf true, the router just sends the MessagePayload instead of sending a MessageStatus and awaiting a ReceiveMessageBegin.
i2cp.leaseSetAuthType0.9.4100-20The type of authentication for encrypted LS2. 0 for no per-client authentication (the default); 1 for DH per-client authentication; 2 for PSK per-client authentication. See proposal 123.
i2cp.leaseSetEncType0.9.384,00-65535,...0The encryption type to be used, as of 0.9.38. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. As of 0.9.39, may be comma-separated values for multiple types. See PublicKey in common structures spec for values. See proposals 123, 144, and 145.
i2cp.leaseSetOfflineExpiration0.9.38The expiration of the offline signature, 4 bytes, seconds since the epoch. See proposal 123.
i2cp.leaseSetOfflineSignature0.9.38The base 64 of the offline signature. See proposal 123.
i2cp.leaseSetPrivKey0.9.41A base 64 X25519 private key for the router to use to decrypt the encrypted LS2 locally, only if per-client authentication is enabled. Optionally preceded by the key type and ':'. Only "ECIES_X25519:" is supported, which is the default. See proposal 123. Do not confuse with i2cp.leaseSetPrivateKey which is for the leaseset encryption keys.
i2cp.leaseSetSecret0.9.39""Base 64 encoded UTF-8 secret used to blind the leaseset address. See proposal 123.
i2cp.leaseSetTransientPublicKey0.9.38[type:]b64 The base 64 of the transient private key, prefixed by an optional sig type number or name, default DSA_SHA1. See proposal 123.
i2cp.leaseSetType0.9.381,3,5,71-2551The type of leaseset to be sent in the CreateLeaseSet2 Message. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. See proposal 123.
i2cp.messageReliabilityBestEffort, NoneBestEffortGuaranteed is disabled; None implemented in 0.8.1; the streaming lib default is None as of 0.8.1, the client side default is None as of 0.9.4
i2cp.password0.8.2stringFor authorization, if required by the router. If the client is running in the same JVM as a router, this option is not required. Warning - username and password are sent in the clear to the router, unless using SSL (i2cp.SSL=true). Authorization is only recommended when using SSL.
i2cp.username0.8.2string
inbound.allowZeroHoptrue, falsetrueIf incoming zero hop tunnel is allowed
outbound.allowZeroHoptrue, falsetrueIf outgoing zero hop tunnel is allowed
inbound.backupQuantitynumber from 0 to 3No limit0Number of redundant fail-over for tunnels in
outbound.backupQuantitynumber from 0 to 3No limit0Number of redundant fail-over for tunnels out
inbound.IPRestrictionnumber from 0 to 40 to 42Number of IP bytes to match to determine if two routers should not be in the same tunnel. 0 to disable.
outbound.IPRestrictionnumber from 0 to 40 to 42Number of IP bytes to match to determine if two routers should not be in the same tunnel. 0 to disable.
inbound.lengthnumber from 0 to 30 to 73Length of tunnels in
outbound.lengthnumber from 0 to 30 to 73Length of tunnels out
inbound.lengthVariancenumber from -1 to 2-7 to 70Random amount to add or subtract to the length of tunnels in. A positive number x means add a random amount from 0 to x inclusive. A negative number -x means add a random amount from -x to x inclusive. The router will limit the total length of the tunnel to 0 to 7 inclusive. The default variance was 1 prior to release 0.7.6.
outbound.lengthVariancenumber from -1 to 2-7 to 70Random amount to add or subtract to the length of tunnels out. A positive number x means add a random amount from 0 to x inclusive. A negative number -x means add a random amount from -x to x inclusive. The router will limit the total length of the tunnel to 0 to 7 inclusive. The default variance was 1 prior to release 0.7.6.
inbound.nicknamestringName of tunnel - generally used in routerconsole, which will use the first few characters of the Base64 hash of the destination by default.
outbound.nicknamestringName of tunnel - generally ignored unless inbound.nickname is unset.
outbound.priority0.9.4number from -25 to 25-25 to 250Priority adjustment for outbound messages. Higher is higher priority.
inbound.quantitynumber from 1 to 31 to 162Number of tunnels in. Limit was increased from 6 to 16 in release 0.9; however, numbers higher than 6 are incompatible with older releases.
outbound.quantitynumber from 1 to 3No limit2Number of tunnels out
inbound.randomKey0.9.17Base 64 encoding of 32 random bytesUsed for consistent peer ordering across restarts.
outbound.randomKey0.9.17Base 64 encoding of 32 random bytes
inbound.*Any other options prefixed with "inbound." are stored in the "unknown options" properties of the inbound tunnel pool's settings.
outbound.*Any other options prefixed with "outbound." are stored in the "unknown options" properties of the outbound tunnel pool's settings.
shouldBundleReplyInfo0.9.2true, falsetrueSet to false to disable ever bundling a reply LeaseSet. For clients that do not publish their LeaseSet, this option must be true for any reply to be possible. "true" is also recommended for multihomed servers with long connection times.

Setting to “false” may save significant outbound bandwidth, especially if the client is configured with a large number of inbound tunnels (Leases). If replies are still required, this may shift the bandwidth burden to the far-end client and the floodfill. There are several cases where “false” may be appropriate:

  • Unidirectional communication, no reply required
  • LeaseSet is published and higher reply latency is acceptable
  • LeaseSet is published, client is a “server”, all connections are inbound so the connecting far-end destination obviously has the leaseset already. Connections are either short, or it is acceptable for latency on a long-lived connection to temporarily increase while the other end re-fetches the LeaseSet after expiration. HTTP servers may fit these requirements.
Poznámka: Vysoká hodnota množství, délky nebo rozptylu může způsobit významné problémy s výkonem nebo spolehlivostí.

Poznámka: Počínaje verzí 0.7.7 musí názvy a hodnoty možností používat kódování UTF-8. To je především užitečné pro přezdívky. Před touto verzí docházelo ke poškození možností obsahujících znaky vícebajtových znaků. Jelikož jsou možnosti kódovány ve struktuře Mapování , jsou všechny názvy a hodnoty možností omezeny maximálně na 255 bajtů (nikoli znaků).

Možnosti na straně klienta

Následující možnosti jsou interpretovány na straně klienta a budou interpretovány, pokud jsou předány I2PSession prostřednictvím volání I2PClient.createSession(). Knihovna pro streamování by měla tyto možnosti rovněž předat do I2CP. Jiné implementace mohou mít odlišné výchozí hodnoty.

Client-side Options
OptionAs Of ReleaseRecommended ArgumentsAllowable RangeDefaultDescription
i2cp.closeIdleTime0.7.11800000300000 minimum(ms) Idle time required (default 30 minutes)
i2cp.closeOnIdle0.7.1true, falsefalseClose I2P session when idle
i2cp.encryptLeaseSet0.7.1true, falsefalseEncrypt the lease
i2cp.fastReceive0.9.4true, falsetrueIf true, the router just sends the MessagePayload instead of sending a MessageStatus and awaiting a ReceiveMessageBegin.
i2cp.gzip0.6.5true, falsetrueGzip outbound data
i2cp.leaseSetAuthType0.9.4100-20The type of authentication for encrypted LS2. 0 for no per-client authentication (the default); 1 for DH per-client authentication; 2 for PSK per-client authentication. See proposal 123.
i2cp.leaseSetBlindedType0.9.390-65535See prop. 123The sig type of the blinded key for encrypted LS2. Default depends on the destination sig type. See proposal 123.
i2cp.leaseSetClient.dh.nnn0.9.41b64name:b64pubkeyThe base 64 of the client name (ignored, UI use only), followed by a ':', followed by the base 64 of the public key to use for DH per-client auth. nnn starts with 0. See proposal 123.
i2cp.leaseSetClient.psk.nnn0.9.41b64name:b64privkeyThe base 64 of the client name (ignored, UI use only), followed by a ':', followed by the base 64 of the private key to use for PSK per-client auth. nnn starts with 0. See proposal 123.
i2cp.leaseSetEncType0.9.3800-65535,...0The encryption type to be used, as of 0.9.38. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. As of 0.9.39, may be comma-separated values for multiple types. See also i2cp.leaseSetPrivateKey. See PublicKey in common structures spec for values. See proposals 123, 144, and 145.
i2cp.leaseSetKey0.7.1For encrypted leasesets. Base 64 SessionKey (44 characters)
i2cp.leaseSetOption.nnn0.9.66srvKey=srvValueA service record to be placed in the LeaseSet2 options. Example: "_smtp._tcp=1 86400 0 0 25 ...b32.i2p". nnn starts with 0. See proposal 167.
i2cp.leaseSetPrivateKey0.9.18Base 64 private keys for encryption. Optionally preceded by the encryption type name or number and ':'. For LS1, only one key is supported, and only "0:" or "ELGAMAL_2048:" is supported, which is the default. As of 0.9.39, for LS2, multiple keys may be comma-separated, and each key must be a different encryption type. I2CP will generate the public key from the private key. Use for persistent leaseset keys across restarts. See proposals 123, 144, and 145. See also i2cp.leaseSetEncType. Do not confuse with i2cp.leaseSetPrivKey which is for encrypted LS2.
i2cp.leaseSetSecret0.9.39""Base 64 encoded UTF-8 secret used to blind the leaseset address. See proposal 123.
i2cp.leaseSetSigningPrivateKey0.9.18Base 64 private key for signatures. Optionally preceded by the key type and ':'. DSA_SHA1 is the default. Key type must match the signature type in the destination. I2CP will generate the public key from the private key. Use for persistent leaseset keys across restarts.
i2cp.leaseSetType0.9.381,3,5,71-2551The type of leaseset to be sent in the CreateLeaseSet2 Message. Interpreted client-side, but also passed to the router in the SessionConfig, to declare intent and check support. See proposal 123.
i2cp.messageReliabilityBestEffort, NoneNoneGuaranteed is disabled; None implemented in 0.8.1; None is the default as of 0.9.4
i2cp.reduceIdleTime0.7.11200000300000 minimum(ms) Idle time required (default 20 minutes, minimum 5 minutes)
i2cp.reduceOnIdle0.7.1true, falsefalseReduce tunnel quantity when idle
i2cp.reduceQuantity0.7.111 to 51Tunnel quantity when reduced (applies to both inbound and outbound)
i2cp.SSL0.8.3true, falsefalseConnect to the router using SSL. If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
i2cp.tcp.host127.0.0.1Router hostname. If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
i2cp.tcp.port1-655357654Router I2CP port. If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
Poznámka: Všechny argumenty, včetně čísel, jsou řetězce. Hodnoty true/false jsou řetězce nezávislé na velikosti písmen. Cokoli jiného než „true“ (bez rozlišení velikosti písmen) je interpretováno jako false. Názvy všech možností rozlišují velikost písmen.

Formát datové části I2CP a multiplexování

End-to-end zprávy zpracovávané přes I2CP (tj. data odeslaná klientem ve zprávě SendMessageMessage a přijatá klientem ve zprávě MessagePayloadMessage ) jsou komprimovány pomocí standardního 10bajtového gzip hlavičky začínající sekvencí 0x1F 0x8B 0x08, jak je specifikováno v RFC 1952 . Počínaje verzí 0.7.1 I2P využívá nepoužívané části gzip hlavičky k vložení informací o protokolu, zdrojovém portu (from-port) a cílovém portu (to-port), čímž umožňuje použití streamování a datagramů na stejné destinaci a spolehlivé fungování dotazů/odpovědí pomocí datagramů i při více kanálech.

Funkci gzip nelze úplně vypnout, ale nastavení i2cp.gzip=false nastaví úsilí komprese gzip na 0, což může ušetřit trochu výkonu CPU. Implementace mohou volit různé úrovně úsilí gzip pro jednotlivé sokety nebo zprávy, a to na základě odhadu komprimovatelnosti obsahu. Kvůli komprimovatelnosti doplňování cíle implementovaného v API 0.9.57 (návrh 161) se doporučuje komprese streamovacích SYN paketů v obou směrech i odpovědných datagramů, i když samotná užitečná zátěž není komprimovatelná. Implementace si mohou přát napsat triviální funkci gzip/gunzip pro úsilí 0, která v tomto případě přinese výrazné zvýšení efektivity oproti použití gzip knihovny.

BytesContent
0-2Gzip header 0x1F 0x8B 0x08
3Gzip flags
4-5I2P Source port (Gzip mtime)
6-7I2P Destination port (Gzip mtime)
8Gzip xflags (set to 2 to be indistinguishable from the Java implementation)
9I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS)
Poznámka: Čísla protokolů I2P 224–254 jsou vyhrazena pro experimentální protokoly. Číslo protokolu I2P 255 je vyhrazeno pro budoucí rozšíření.

Integrita dat je ověřena standardní kontrolní sumou gzip CRC-32 dle RFC 1952 .

Důležité rozdíly oproti standardnímu IP

Porty I2CP jsou určeny pro I2P sokety a datagramy. Nemají žádný vztah k vašim lokálním soketům nebo portům. Protože I2P nepodporoval porty a čísla protokolů před vydáním 0.7.1, jsou porty a čísla protokolů odlišná od těch ve standardním IP z důvodu zpětné kompatibility:

  • Port 0 je platný a má speciální význam.
  • Porty 1–1023 nejsou speciální ani privilegované.
  • Servery naslouchají ve výchozím nastavení na portu 0, což znamená „všechny porty“.
  • Klienti odesílají ve výchozím nastavení na port 0, což znamená „libovolný port“.
  • Klienti odesílají z portu 0 ve výchozím nastavení, což znamená „nespecifikováno“.
  • Servery mohou mít službu naslouchající na portu 0 a další služby naslouchající na vyšších portech. V takovém případě je služba na portu 0 výchozí a k ní se připojí, pokud příchozí port soketu nebo datagramu neodpovídá žádné jiné službě.
  • U většiny cílů I2P běží pouze jedna služba, takže můžete použít výchozí nastavení a konfiguraci portu I2CP ignorovat.
  • Protokol 0 je platný a znamená „libovolný protokol“. Toto ale není doporučeno a pravděpodobně nebude fungovat. Pro proudování je nutné nastavit číslo protokolu na 6.
  • Streamovací sokety jsou sledovány pomocí interního identifikátoru připojení. Proto není vyžadováno, aby byla pětice dest:port:dest:port:protokol unikátní. Například může existovat více soketů se stejnými porty mezi dvěma cíli. Klienti nemusí vybírat „volný port“ pro odchozí připojení.

Budoucí práce

  • Stávající autorizační mechanismus by mohl být upraven tak, aby používal hašovaná hesla.
  • Soukromý podpisový klíč je zahrnut v zprávě Create Lease Set, ale není vyžadován. Odvolání klíče není implementováno. Měl by být nahrazen náhodnými daty nebo odstraněn.
  • Některá vylepšení by mohla využít zprávy, které byly dříve definovány, ale nebyly implementovány.

Was this page helpful?