Tổng quan
Giao thức Khách hàng I2P (I2CP) tạo ra sự tách biệt rõ ràng giữa bộ định tuyến và bất kỳ khách hàng nào muốn giao tiếp qua mạng. Nó cho phép gửi và nhận tin nhắn một cách an toàn và không đồng bộ thông qua một cổng kết nối TCP duy nhất. Với I2CP, một ứng dụng khách sẽ thông báo cho bộ định tuyến biết họ là ai (điểm đến “destination” của họ), các mức độ ẩn danh, độ tin cậy và độ trễ phù hợp, cũng như nơi cần gửi tin nhắn đến. Đổi lại, bộ định tuyến sử dụng I2CP để thông báo cho khách hàng khi có tin nhắn đến, và yêu cầu cấp quyền để sử dụng một số đường hầm nhất định.
Giao thức này được triển khai bằng Java nhằm cung cấp SDK dành cho khách hàng. SDK này được cung cấp trong gói i2p.jar, thực hiện phần phía khách hàng của I2CP. Khách hàng không bao giờ cần truy cập vào gói router.jar, gói này chứa bộ định tuyến và phần phía bộ định tuyến của I2CP. Một khách hàng không dùng Java cũng sẽ phải triển khai thư viện streaming để thiết lập kết nối theo kiểu TCP.
Các ứng dụng có thể tận dụng I2CP cơ bản cùng với các thư viện streaming và datagram bằng cách sử dụng giao thức Simple Anonymous Messaging (SAM) , giao thức này không yêu cầu khách hàng phải xử lý bất kỳ hình thức mã hóa nào. Ngoài ra, các khách hàng có thể truy cập mạng thông qua một trong các proxy - HTTP, CONNECT và SOCKS 4/4a/5. Ngoài ra, các khách hàng Java có thể truy cập các thư viện đó trong ministreaming.jar và streaming.jar. Do đó, có một số lựa chọn cho cả ứng dụng Java và không phải Java.
Việc mã hóa đầu cuối ở phía máy khách (mã hóa dữ liệu qua kết nối I2CP) đã bị tắt trong bản phát hành I2P 0.6, chỉ giữ lại việc mã hóa đầu cuối ElGamal/AES được thực hiện trong bộ định tuyến. Nhiệm vụ mã hóa duy nhất mà các thư viện máy khách vẫn phải triển khai là chữ ký khóa công khai/khóa riêng DSA cho LeaseSets và Cấu hình phiên , cùng với việc quản lý các khóa đó.
Trong một cài đặt I2P tiêu chuẩn, cổng 7654 được các ứng dụng khách Java bên ngoài sử dụng để giao tiếp với bộ định tuyến cục bộ thông qua I2CP. Theo mặc định, bộ định tuyến liên kết với địa chỉ 127.0.0.1. Để liên kết với 0.0.0.0, hãy đặt tùy chọn cấu hình nâng cao của bộ định tuyến là i2cp.tcp.bindAllInterfaces=true và khởi động lại. Các ứng dụng khách chạy trong cùng JVM với bộ định tuyến sẽ truyền tin nhắn trực tiếp đến bộ định tuyến thông qua một giao diện JVM nội bộ.
Một số triển khai bộ định tuyến và máy khách cũng có thể hỗ trợ kết nối bên ngoài thông qua SSL, được cấu hình bằng tùy chọn i2cp.SSL=true. Mặc dù SSL không phải là mặc định, nhưng được khuyến nghị mạnh mẽ đối với mọi lưu lượng có thể bị phơi nhiễm ra Internet công cộng. Thông tin xác thực người dùng/mật khẩu (nếu có), Khóa riêng
và Khóa riêng ký
cho Đích đến
đều được truyền không mã hóa trừ khi SSL được bật. Một số triển khai bộ định tuyến và máy khách cũng có thể hỗ trợ kết nối bên ngoài thông qua cổng kết nối (domain sockets).
Đặc tả Giao thức I2CP
Xem trang Thông số kỹ thuật I2CP để biết thông số giao thức đầy đủ.
Khởi tạo I2CP
Khi một client kết nối với router, nó trước tiên gửi một byte duy nhất thể hiện phiên bản giao thức (0x2A). Sau đó, nó gửi một Tin nhắn GetDate và chờ phản hồi Tin nhắn SetDate . Tiếp theo, nó gửi một Tin nhắn CreateSession chứa cấu hình phiên làm việc. Sau đó, client chờ một Tin nhắn RequestLeaseSet từ router, cho biết các tunnel nhận đã được tạo xong, rồi phản hồi bằng một CreateLeaseSetMessage chứa LeaseSet đã ký. Giờ đây, client có thể bắt đầu hoặc nhận các kết nối từ các đích I2P khác.
Tùy chọn I2CP
Tùy chọn phía bộ định tuyến
Các tùy chọn sau đây thường được truyền tới bộ định tuyến thông qua một SessionConfig nằm trong tin nhắn CreateSession hoặc tin nhắn ReconfigureSession .
| Router-side Options | |||||
|---|---|---|---|---|---|
| Option | As Of Release | Recommended Arguments | Allowable Range | Default | Description |
| clientMessageTimeout | 8*1000 - 120*1000 | 60*1000 | The timeout (ms) for all sent messages. Unused. See the protocol specification for per-message settings. | ||
| crypto.lowTagThreshold | 0.9.2 | 1-128 | 30 | Minimum number of ElGamal/AES Session Tags before we send more. Recommended: approximately tagsToSend * 2/3 | |
| crypto.ratchet.inboundTags | 0.9.47 | 1-? | 160 | Inbound tag window for ECIES-X25519-AEAD-Ratchet. Local inbound tagset size. See proposal 144. | |
| crypto.ratchet.outboundTags | 0.9.47 | 1-? | 160 | Outbound tag window for ECIES-X25519-AEAD-Ratchet. Advisory to send to the far-end in the options block. See proposal 144. | |
| crypto.tagsToSend | 0.9.2 | 1-128 | 40 | Number 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. | |
| explicitPeers | null | Comma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only | |||
| i2cp.dontPublishLeaseSet | true, false | false | Should generally be set to true for clients and false for servers | ||
| i2cp.fastReceive | 0.9.4 | true, false | false | If true, the router just sends the MessagePayload instead of sending a MessageStatus and awaiting a ReceiveMessageBegin. | |
| i2cp.leaseSetAuthType | 0.9.41 | 0 | 0-2 | 0 | The 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.leaseSetEncType | 0.9.38 | 4,0 | 0-65535,... | 0 | The 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.leaseSetOfflineExpiration | 0.9.38 | The expiration of the offline signature, 4 bytes, seconds since the epoch. See proposal 123. | |||
| i2cp.leaseSetOfflineSignature | 0.9.38 | The base 64 of the offline signature. See proposal 123. | |||
| i2cp.leaseSetPrivKey | 0.9.41 | A 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.leaseSetSecret | 0.9.39 | "" | Base 64 encoded UTF-8 secret used to blind the leaseset address. See proposal 123. | ||
| i2cp.leaseSetTransientPublicKey | 0.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.leaseSetType | 0.9.38 | 1,3,5,7 | 1-255 | 1 | The 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.messageReliability | BestEffort, None | BestEffort | Guaranteed 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.password | 0.8.2 | string | For 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.username | 0.8.2 | string | |||
| inbound.allowZeroHop | true, false | true | If incoming zero hop tunnel is allowed | ||
| outbound.allowZeroHop | true, false | true | If outgoing zero hop tunnel is allowed | ||
| inbound.backupQuantity | number from 0 to 3 | No limit | 0 | Number of redundant fail-over for tunnels in | |
| outbound.backupQuantity | number from 0 to 3 | No limit | 0 | Number of redundant fail-over for tunnels out | |
| inbound.IPRestriction | number from 0 to 4 | 0 to 4 | 2 | Number of IP bytes to match to determine if two routers should not be in the same tunnel. 0 to disable. | |
| outbound.IPRestriction | number from 0 to 4 | 0 to 4 | 2 | Number of IP bytes to match to determine if two routers should not be in the same tunnel. 0 to disable. | |
| inbound.length | number from 0 to 3 | 0 to 7 | 3 | Length of tunnels in | |
| outbound.length | number from 0 to 3 | 0 to 7 | 3 | Length of tunnels out | |
| inbound.lengthVariance | number from -1 to 2 | -7 to 7 | 0 | Random 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.lengthVariance | number from -1 to 2 | -7 to 7 | 0 | Random 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.nickname | string | Name of tunnel - generally used in routerconsole, which will use the first few characters of the Base64 hash of the destination by default. | |||
| outbound.nickname | string | Name of tunnel - generally ignored unless inbound.nickname is unset. | |||
| outbound.priority | 0.9.4 | number from -25 to 25 | -25 to 25 | 0 | Priority adjustment for outbound messages. Higher is higher priority. |
| inbound.quantity | number from 1 to 3 | 1 to 16 | 2 | Number 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.quantity | number from 1 to 3 | No limit | 2 | Number of tunnels out | |
| inbound.randomKey | 0.9.17 | Base 64 encoding of 32 random bytes | Used for consistent peer ordering across restarts. | ||
| outbound.randomKey | 0.9.17 | Base 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. | ||||
| shouldBundleReplyInfo | 0.9.2 | true, false | true | Set 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:
| |
Lưu ý: Kể từ phiên bản 0.7.7, tên và giá trị tùy chọn phải sử dụng mã hóa UTF-8. Điều này chủ yếu hữu ích cho biệt danh. Trước phiên bản này, các tùy chọn có ký tự đa byte bị hỏng. Vì các tùy chọn được mã hóa trong một Mapping , tất cả tên và giá trị tùy chọn đều bị giới hạn tối đa 255 byte (không phải ký tự).
Tùy chọn phía máy khách
Các tùy chọn sau được diễn giải ở phía máy khách và sẽ được xử lý nếu được truyền tới I2PSession thông qua lời gọi I2PClient.createSession(). Thư viện streaming cũng nên chuyển các tùy chọn này tới I2CP. Các triển khai khác có thể có giá trị mặc định khác nhau.
| Client-side Options | |||||
|---|---|---|---|---|---|
| Option | As Of Release | Recommended Arguments | Allowable Range | Default | Description |
| i2cp.closeIdleTime | 0.7.1 | 1800000 | 300000 minimum | (ms) Idle time required (default 30 minutes) | |
| i2cp.closeOnIdle | 0.7.1 | true, false | false | Close I2P session when idle | |
| i2cp.encryptLeaseSet | 0.7.1 | true, false | false | Encrypt the lease | |
| i2cp.fastReceive | 0.9.4 | true, false | true | If true, the router just sends the MessagePayload instead of sending a MessageStatus and awaiting a ReceiveMessageBegin. | |
| i2cp.gzip | 0.6.5 | true, false | true | Gzip outbound data | |
| i2cp.leaseSetAuthType | 0.9.41 | 0 | 0-2 | 0 | The 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.leaseSetBlindedType | 0.9.39 | 0-65535 | See prop. 123 | The sig type of the blinded key for encrypted LS2. Default depends on the destination sig type. See proposal 123. | |
| i2cp.leaseSetClient.dh.nnn | 0.9.41 | b64name:b64pubkey | The 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.nnn | 0.9.41 | b64name:b64privkey | The 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.leaseSetEncType | 0.9.38 | 0 | 0-65535,... | 0 | The 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.leaseSetKey | 0.7.1 | For encrypted leasesets. Base 64 SessionKey (44 characters) | |||
| i2cp.leaseSetOption.nnn | 0.9.66 | srvKey=srvValue | A 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.leaseSetPrivateKey | 0.9.18 | Base 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.leaseSetSecret | 0.9.39 | "" | Base 64 encoded UTF-8 secret used to blind the leaseset address. See proposal 123. | ||
| i2cp.leaseSetSigningPrivateKey | 0.9.18 | Base 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.leaseSetType | 0.9.38 | 1,3,5,7 | 1-255 | 1 | The 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.messageReliability | BestEffort, None | None | Guaranteed is disabled; None implemented in 0.8.1; None is the default as of 0.9.4 | ||
| i2cp.reduceIdleTime | 0.7.1 | 1200000 | 300000 minimum | (ms) Idle time required (default 20 minutes, minimum 5 minutes) | |
| i2cp.reduceOnIdle | 0.7.1 | true, false | false | Reduce tunnel quantity when idle | |
| i2cp.reduceQuantity | 0.7.1 | 1 | 1 to 5 | 1 | Tunnel quantity when reduced (applies to both inbound and outbound) |
| i2cp.SSL | 0.8.3 | true, false | false | Connect 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.host | 127.0.0.1 | Router 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.port | 1-65535 | 7654 | Router 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. | ||
Định dạng Dữ liệu Payload I2CP và Đa hợp kênh
Các tin nhắn đầu cuối được xử lý bởi I2CP (tức là dữ liệu do client gửi trong một SendMessageMessage và nhận bởi client trong một MessagePayloadMessage ) được nén gzip với tiêu đề gzip tiêu chuẩn 10 byte bắt đầu bằng 0x1F 0x8B 0x08 như được quy định trong RFC 1952 . Kể từ phiên bản 0.7.1, I2P sử dụng các phần bỏ qua trong tiêu đề gzip để bao gồm thông tin giao thức, cổng-gửi (from-port) và cổng-nhận (to-port), do đó hỗ trợ cả luồng (streaming) và datagram trên cùng một đích, đồng thời cho phép truy vấn/phản hồi sử dụng datagram hoạt động đáng tin cậy khi có nhiều kênh.
Hàm gzip không thể bị tắt hoàn toàn, tuy nhiên việc thiết lập i2cp.gzip=false sẽ đặt mức nỗ lực nén gzip về 0, điều này có thể tiết kiệm một chút tài nguyên CPU. Các triển khai có thể lựa chọn các mức nỗ lực gzip khác nhau tùy theo từng socket hoặc từng tin nhắn, dựa trên đánh giá khả năng nén của nội dung. Do khả năng nén được thực hiện thông qua việc đệm địa chỉ đích theo API 0.9.57 (đề xuất 161), việc nén các gói tin SYN truyền theo luồng theo cả hai hướng và các gói tin datagram có thể phản hồi là được khuyến nghị, ngay cả khi phần tải (payload) không thể nén được. Các triển khai có thể muốn viết một hàm gzip/gunzip đơn giản cho mức nỗ lực gzip bằng 0, điều này sẽ mang lại hiệu quả lớn hơn so với việc sử dụng một thư viện gzip trong trường hợp này.
| Bytes | Content |
|---|---|
| 0-2 | Gzip header 0x1F 0x8B 0x08 |
| 3 | Gzip flags |
| 4-5 | I2P Source port (Gzip mtime) |
| 6-7 | I2P Destination port (Gzip mtime) |
| 8 | Gzip xflags (set to 2 to be indistinguishable from the Java implementation) |
| 9 | I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS) |
Tính toàn vẹn dữ liệu được xác minh bằng chuẩn gzip CRC-32 như đã nêu trong RFC 1952 .
Những khác biệt quan trọng so với IP tiêu chuẩn
Các cổng I2CP dành cho các socket và datagram I2P. Chúng không liên quan đến các socket hoặc cổng cục bộ của bạn. Vì I2P không hỗ trợ cổng và số giao thức trước phiên bản 0.7.1, nên các cổng và số giao thức trong I2P có phần khác biệt so với chuẩn IP, nhằm đảm bảo tính tương thích ngược:
- Cổng 0 là hợp lệ và có ý nghĩa đặc biệt.
- Các cổng 1-1023 không đặc biệt hay được cấp quyền gì.
- Máy chủ lắng nghe trên cổng 0 theo mặc định, có nghĩa là “tất cả các cổng”.
- Máy khách gửi đến cổng 0 theo mặc định, có nghĩa là “bất kỳ cổng nào”.
- Máy khách gửi đi từ cổng 0 theo mặc định, có nghĩa là “chưa xác định”.
- Máy chủ có thể có một dịch vụ đang lắng nghe trên cổng 0 và các dịch vụ khác đang lắng nghe trên các cổng cao hơn. Trong trường hợp đó, dịch vụ trên cổng 0 sẽ là mặc định, và sẽ được kết nối nếu cổng socket hoặc datagram đầu vào không khớp với dịch vụ nào khác.
- Hầu hết các điểm đến I2P chỉ chạy một dịch vụ, do đó bạn có thể sử dụng các giá trị mặc định và bỏ qua cấu hình cổng I2CP.
- Giao thức 0 là hợp lệ và có nghĩa là “bất kỳ giao thức nào”. Tuy nhiên, điều này không được khuyến khích và có thể sẽ không hoạt động. Giao thức streaming yêu cầu số giao thức phải được đặt thành 6.
- Các socket streaming được theo dõi thông qua một ID kết nối nội bộ. Do đó, không yêu cầu bắt buộc 5-tuple gồm dest:port:dest:port:protocol phải là duy nhất. Ví dụ, có thể có nhiều socket với cùng cổng giữa hai điểm đến. Máy khách không cần phải chọn một “cổng trống” cho kết nối đi.
Công việc trong tương lai
- Cơ chế xác thực hiện tại có thể được sửa đổi để sử dụng mật khẩu đã băm.
- Khóa riêng ký được bao gồm trong tin nhắn Tạo bộ thuê (Create Lease Set), nhưng nó không bắt buộc. Việc thu hồi khóa chưa được triển khai. Thành phần này nên được thay thế bằng dữ liệu ngẫu nhiên hoặc loại bỏ hoàn toàn.
- Một số cải tiến có thể tận dụng các tin nhắn đã được định nghĩa trước đó nhưng chưa được triển khai.