3. Поведение нижележащего уровня
3.1. Требования к нижележащему уровню
Ниже перечислены допущения EAP о нижележащем уровне.
Транспорт без гарантии доставки. В EAP идентифицирующая сторона продожает передавать запросы, пока на них не получено откликов, так что EAP не полагается на гарантию доставки на нижележащем уровне. Поскольку EAP определяет свое поведение для повторов передачи, возможно (хотя и нежелательно) повторение передачи на уровне EAP и на нижележащем уровне при обеспечении тем гарантий доставки.
Отметим, что пакеты Success и Failure не передаются повторно. Без гарантий нижележащего уровня и при заметном количестве ошибок эти пакеты могут теряться, что будет приводить к тайм-аутам. Следовательно, для реализаций желательно повысить свою устойчивость к потере пакетов Success и Failure, как описано в параграфе 4.2.
Детектирование ошибок. Хотя EAP не предполагает гарантированной доставки на нижележащем уровне, протокол опирается на детектирование ошибок этого уровня (например, CRC, Checksum, MIC и т.п.). Методы EAP могут не включать MIC или рассчитывать контрольную сумму не для всех полей пакета EAP (таких, как Code, Identifier, Length или Type). В результате без детектирования ошибок на нижележащем уровне незамеченные ошибки могут попадать в поля заголовков уровня EAP или уровня методов EAP, приводя к отказам в идентификации.
Например, метод EAP TLS [RFC2716] рассчитывает значение MIC только для поля Type-Data и трактует несовпадение MIC, как критическую ошибку. Без детектирования ошибок на нижележащем уровне этот метод и аналогичные ему методы не смогут работать надежно.
Защита. EAP не требует от нижележащего уровня поддержки услуг защиты типа конфиденциальности пакетов, идентификации, защиты целостности и защиты от повторного использования пакетов. Однако при доступности таких услуг для динамического получения ключевого материала могут использоваться методы EAP, поддерживающие Key Derivation (см. параграф 7.2.1). Это позволяет связать идентификацию EAP с последующими данными и обеспечить защиту от изменения данных, повторного использования пакетов или использования подставных пакетов (spoofing). Более подробное рассмотрение приведено в параграфе 7.1.
Минимальное значение MTU. EAP может работать с нижележащими уровнями, которые обеспечивают размер EAP MTU не менее 1020 октетов.
EAP не поддерживает определение MTU для пути, а фрагментация и сборка не поддерживаются ни EAP, ни определенными в этой спецификации методами Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6) и расширенным Nak (254).
Обычно партнер EAP получает информацию о EAP MTU от нижележащего уровня и устанавливат подходящее значение для размера кадров EAP. Когда идентифицирующая сторона работает в проходном режиме, у сервера идентификации нет прямого пути определения EAP MTU и, следовательно, он полагается на получение этой информации от идентифицирующей стороны (например, с помощью атрибута Framed-MTU, описанного в параграфе 2.4 [RFC3579]). Тогда как методы типа EAP-TLS [RFC2716] поддерживают фрагментацию и сборку, методы EAP изначально разработанные для использования с протоколом PPP, где гарантируется поддержка MTU размером 1500 октетов для кадров управления (см. параграф 6.1 [RFC1661]), могут не поддерживать функций фрагментации и сборки.
Методы EAP могут предполагать по умолчанию минимальное значение EAP MTU в 1020 октетов. Методам EAP следует включать поддержку фрагментации и сборки, если размер их элементов данных превышает указанное минимальное значение EAP MTU.
EAP является поэтапным протоколом, что ведет к снижению эффективности при использовании фрагментации. Следовательно, если нижележащий уровень поддерживает фрагментацию и сборку (как в случае работы EAP по протоколу IP), использование фрагментации на этом уровне может оказаться предпочтительней фрагментации в EAP. Этого можно достигнуть путем задания излишне большого значения EAP MTU, что приведет к использованию фрагментации и сборки на нижележащем уровне.
Возможность дублирования пакетов. Нижележащий уровень с гарантированной доставкой будет обеспечивать урояню EAP поток пакетов, не содержащий дубликатов. Отсутствие дубликатов на нижележащем уровне желательно, но не является обязательным. Поле Identifier позволяет идентифицирующей стороне и ее партнеру возможность детектирования дубликатов.
Гарантии порядка доставки. EAP не требует монотонного роста значения поля Identifier и для корректной работы ему нужно сохранение порядка доставки на нижележащем уровне. Изначально протокол EAP разрабатывался для использования с протоколом PPP, в спецификации которого [RFC1661] (раздел 1) сказано:
"Протокол PPP предназначен для простых каналов, передающих пакеты между двумя партнерами. Эти каналы обеспечивают полнодуплексную двухстороннюю передачу и предполагается, что порядок доставки пакетов сохраняется".
Нижележащий транспорт для EAP должен сохранять порядок доставки между отправителем и получателем для заданного уровня приоритета (гарантии сохранения прорядка в [IEEE-802]).
Нарушение порядка доставки обычно будет приводить к отказу идентификации EAP и необходимости повторного запуска процедур идентификации. В среде, где нарушение порядка является обычным делом, столь же обычными будут и отказы при идентификации EAP. Рекомендуется использовать EAP только с нижележащими уровнями, обеспечивающими сохранение порядка доставки. Использование EAP с транспортом raw IP или UDP не рекомендуется. Инкапсуляция EAP в RADIUS [RFC3579] удовлетворяет требованиям по сохранению порядка, поскольку протокол RADIUS гарантирует такое сохранение.