Примечание
Развертывание и тестирование сети в процессе. Возможны незначительные изменения.
Обзор
Резюме
ECIES сокращает накладные расходы на существующие сеансовые (ES) сообщения примерно на 90 байт. Поэтому мы можем увеличить MTU примерно на 90 байт для соединений ECIES. См. the ECIES specification, Streaming specification, and Streaming API documentation.
Без увеличения MTU, во многих случаях экономия на накладных расходах на самом деле не “сохраняется”, так как сообщения будут дополнены для использования двух полных туннельных сообщений в любом случае.
Это предложение не требует изменений в спецификациях. Оно размещено как предложение исключительно для содействия обсуждению и консенсусу по поводу рекомендуемой величины и деталей реализации.
Цели
- Увеличение согласованного MTU
- Максимальное использование 1 КБ туннельных сообщений
- Не изменять стриминговый протокол
Дизайн
Используйте существующий вариант MAX_PACKET_SIZE_INCLUDED и переговоры по MTU. Стриминг продолжает использовать минимум из отправленных и полученных MTU. По умолчанию остается 1730 для всех соединений, независимо от используемых ключей.
Рекомендуется включать вариант MAX_PACKET_SIZE_INCLUDED во всех SYN-пакетах, в обоих направлениях, хотя это и не является требованием.
Если пункт назначения только ECIES, используйте большее значение (как для Alice, так и для Bob). Если пункт назначения с двойным ключом, поведение может варьироваться:
Если клиент с двойным ключом находится вне маршрутизатора (во внешнем приложении), он может не “знать” ключ удаленного конца, и Alice может запросить большее значение в SYN, в то время как максимальные данные в SYN остаются 1730.
Если клиент с двойным ключом находится внутри маршрутизатора, информация о том, какой ключ используется, может быть известна клиенту или нет. Leaseset, возможно, еще не был получен, или внутренние API интерфейсы могут не легко сделать эту информацию доступной клиенту. Если информация доступна, Alice может использовать большее значение; в противном случае, Alice должна использовать стандартное значение 1730 до согласования.
Клиент с двойным ключом как Bob может отправить большее значение в ответ, даже если не было получено никакого значения или было получено значение 1730 от Alice; однако, не предусмотрено возможности переговоров по увеличению в стриминге, поэтому MTU должно оставаться на уровне 1730.
Как отмечено в the Streaming API documentation, данные в SYN-пакетах, отправляемых от Alice к Bob, могут превышать MTU Bob. Это слабость в стриминговом протоколе. Таким образом, клиенты с двойным ключом должны ограничивать данные в отправляемых SYN-пакетах до 1730 байт, отправляя при этом более высокий вариант MTU. Когда от Bob получено более высокое значение MTU, Alice может увеличить фактически отправляемую максимальную полезную нагрузку.
Анализ
Как описано в the ECIES specification, накладные расходы ElGamal для существующих сеансовых сообщений составляют 151 байт, а накладные расходы Ratchet составляют 69 байт. Следовательно, мы можем увеличить MTU для соединений Ratchet на (151 - 69) = 82 байта, с 1730 до 1812.
Спецификация
Добавьте следующие изменения и пояснения к разделу выбора и переговоров MTU the Streaming API documentation. Изменения в the Streaming specification не требуются.
Значение по умолчанию для варианта i2p.streaming.maxMessageSize остается 1730 для всех соединений, независимо от используемых ключей. Клиенты должны использовать минимум из отправленного и полученного MTU, как обычно.
Существуют четыре связанных с MTU констант и переменных:
- DEFAULT_MTU: 1730, без изменений, для всех соединений
- i2cp.streaming.maxMessageSize: по умолчанию 1730 или 1812, может быть изменено настройками
- ALICE_SYN_MAX_DATA: Максимальные данные, которые Alice может включить в SYN-пакет
- negotiated_mtu: Минимум из MTU Alice и Bob, который будет использоваться как максимальный размер данных в SYN ACK от Bob к Alice и во всех последующих пакетах, отправляемых в обоих направлениях
Есть пять случаев, которые нужно рассмотреть:
1) Только ElGamal для Alice
Без изменений, 1730 MTU во всех пакетах.
- ALICE_SYN_MAX_DATA = 1730
- i2cp.streaming.maxMessageSize по умолчанию: 1730
- Alice может отправить MAX_PACKET_SIZE_INCLUDED в SYN, не требуется, если не равно 1730
2) Только ECIES для Alice
1812 MTU во всех пакетах.
- ALICE_SYN_MAX_DATA = 1812
- i2cp.streaming.maxMessageSize по умолчанию: 1812
- Alice должна отправить MAX_PACKET_SIZE_INCLUDED в SYN
3) Alice с двойным ключом и знает, что Bob - ElGamal
1730 MTU во всех пакетах.
- ALICE_SYN_MAX_DATA = 1730
- i2cp.streaming.maxMessageSize default: 1812
- Alice может отправить MAX_PACKET_SIZE_INCLUDED в SYN, не требуется, если не равно 1730
4) Alice с двойным ключом и знает, что Bob - ECIES
1812 MTU во всех пакетах.
- ALICE_SYN_MAX_DATA = 1812
- i2cp.streaming.maxMessageSize по умолчанию: 1812
- Alice должна отправить MAX_PACKET_SIZE_INCLUDED в SYN
5) Alice с двойным ключом и ключ Bob неизвестен
Отправьте 1812 как MAX_PACKET_SIZE_INCLUDED в SYN-пакете, но ограничьте данные SYN-пакета до 1730.
- ALICE_SYN_MAX_DATA = 1730
- i2cp.streaming.maxMessageSize по умолчанию: 1812
- Alice должна отправить MAX_PACKET_SIZE_INCLUDED в SYN
Для всех случаев
Alice и Bob рассчитывают negotiated_mtu, минимум из MTU Alice и Bob, который будет использоваться как максимальный размер данных в SYN ACK от Bob к Alice и во всех последующих пакетах, отправляемых в обоих направлениях.
Обоснование
См. the Java I2P source code почему текущее значение 1730. См. the ECIES specification почему накладные расходы ECIES на 82 байта меньше, чем у ElGamal.
Примечания к реализации
Если стриминг создает сообщения оптимального размера, очень важно, чтобы слой ECIES-Ratchet не добавлял заполнение сверх этого размера.
Оптимальный размер Garlic Message для размещения в двух туннельных сообщениях, включая 16-байтный заголовок Garlic Message I2NP, 4-байтную длину Garlic Message, 8 байт метку ES и 16 байт MAC, составляет 1956 байт.
Рекомендуемый алгоритм заполнения в ECIES следующий:
- Если общая длина Garlic Message составляет 1954-1956 байт, не добавляйте блок заполнения (нет места)
- Если общая длина Garlic Message составляет 1938-1953 байта, добавьте блок заполнения, чтобы дополнить до точно 1956 байт.
- В противном случае, заполняйте как обычно, например, случайным количеством 0-15 байт.
Похожие стратегии можно использовать для оптимального размера одного туннельного сообщения (964) и размера трех туннельных сообщений (2952), хотя такие размеры должны быть редкими на практике.
Проблемы
Значение 1812 является предварительным. Подлежит подтверждению и возможной корректировке.
Миграция
Нет проблем с обратной совместимостью. Это существующий вариант, и переговоры по MTU уже являются частью спецификации.
Старые пункты назначения ECIES будут поддерживать 1730. Любой клиент, получающий более высокое значение, ответит 1730, и противоположная сторона обычно согласует снижение.