Главная страница
Навигация по странице:

  • Configure-Request , Configure-Ack , Configure-Nak и Configure-Reject

  • Configure-Ack

  • Terminate-Request

  • NETWORK

  • Configure-Request : IP-Compression-Protocol

  • IP-Address

  • Path MTU discovery

  • Аутентификатор

  • Одноранговый узел

  • Запрос аутентификации

    		•

    1. 1 История tcpIP


    Скачать 340.83 Kb.
    Название1. 1 История tcpIP
    АнкорDLink
    Дата30.05.2022
    Размер340.83 Kb.
    Формат файлаdocx
    Имя файлаDLink.docx
    ТипПротокол
    #557168
    страница4 из 26
    1   2   3   4   5   6   7   8   9   ...   26

    2.4 Network Control Protocol (NCP)


    После завершения фазы установления канала протоколом LCP и аутентификации (которая необязательна и может не выполняться), независимо друг от друга должны быть сконфигурированы протоколы сетевого уровня, такие как IP, IPX и т. п. Конфигурирование параметров протоколов сетевого уровня выполняется протоколами управления сетью (NCP). Для каждого протокола сетевого уровня, пакеты которого передаются по каналу PPP, используется собственный протокол NCP. Каждый из протоколов NCP обладает специфическими свойствами, зависящими от соответствующего протокола сетевого уровня, и поддерживает конфигурационные запросы, характерные только для этого протокола. Каждый из протоколов NCP может переходить в открытое состояние и закрываться в любое время.

    Стандарты протокола NCP



    Аналогично LCP, каждый протокол NCP выполняет установление, обслуживание и завершение канала. Для выполнения этих функций обе стороны канала обмениваются пакетами протокола NCP. Процесс установки канала и переговоров о параметрах соответствующего протокола сетевого уровня выполняется с помощью пакетов Configure-Ack_,_Configure-Nak_и_Configure-Reject'>Configure-Request, Configure-Ack, Configure-Nak и Configure-Reject, аналогичных LCP. Конфигурационные параметры, передаваемые в этих пакетах, зависят от используемого протокола NCP. Протокол NCP переходит в открытое состояние после согласования параметров, т. е. после получения инициатором пакета Configure-Ack. Пакет Code-Reject отправляется в том случае, когда одна из сторон канала получила пакет NCP с неизвестным кодом. Для завершения канала одна из его сторон отправляет пакет Terminate-Request, на который другая сторона отвечает пакетом Terminate-Ack.

    Протокол конфигурирования IPv4 (IPCP)

    Рассмотрим в качестве примера протокол NCP для IPv4 (IPCP). Протокол управления IP (Internet Protocol Control Protocol, IPCP) предназначен для конфигурирования протокола IPv4 на обоих концах канала PPP. Обмен IPCP-пакетами аналогичен LCP и начинается в состоянии обмена дейтаграммами сетевого уровня (NETWORK). IPCP отличается от LCP следующим:

    • Поле Протокол кадра PPP. Пакет IPCP инкапсулируется в поле Информация кадра PPP, поле Протокол которого имеет значение 0х8021.

    • Поле Код пакета IPCP. Используются только коды с номерами 0-7: Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, Code-Reject.

    Процесс установки канала и переговоров о параметрах протокола IP выполняется с помощью пакетов Configure-Request, Configure-Ack, Configure-Nak и Configure-Reject.

    Для протокола IP определены две конфигурационные опции, которые могут быть указаны в пакете IPCP Configure-Request:

    1. IP-Compression-Protocol (протокол сжатия IP). Данный параметр позволяет договориться об использовании конкретного протокола сжатия заголовков протоколов TCP и IP. По умолчанию сжатие не требуется.

    2. IP-Address (IP-адрес). Данный параметр служит для ведения переговоров об IP-адресе, который будет назначен локальной стороне канала. Он позволяет отправителю запроса Configure-Request указать желаемый IP-адрес или запросить противоположную сторону выдать ему IP-адрес. Противоположная сторона может предоставить данную информацию, отвергнув этот параметр с помощью Configure-Nak и указав правильный IP-адрес. Также параметр позволяет договориться об IP-адресах первичного и вторичного DNS-серверов, которые будут использоваться на локальной стороне. Когда отвечающий узел соглашается с параметрами, он отправляет пакет Configure-Ack.

    После того, как протокол IPCP перейдет в открытое состояние, по каналу PPP смогут передаваться любые IP-пакеты. Максимальная длина IP-пакета соответствует максимальной длине поля Информация кадра РРР. IP-дейтаграммы большего размера будут фрагментированы. Если необходимо избежать фрагментирования и последующего сбора пакетов, то следует использовать механизм Path MTU discovery. Фрагментация пакетов IPv4 и работа процесса Path MTU discovery будет рассмотрена далее в этом курсе.

    2.5 Протоколы аутентификации PPP

    Аутентификация в протоколе PPP не является обязательной и выполняется только по согласованию сторон. Взаимодействующие устройства договариваются об используемом протоколе аутентификации в процессе переговоров LCP. В случае успешной договоренности, аутентификация выполняется сразу же после установления канала. Продолжение настройки канала при этом будет возможно только после успешной аутентификации.


    Аутентификация (Authentication) — сервис безопасности, который обеспечивает подтверждение того, что информация получена от законного источника и получатель является требуемым.

    Идентификация (Identification) — сервис, с помощью которого определяются уникальные свойства пользователей, которые позволяют отличать их друг от друга, и способы, с помощью которых пользователи указывают свои идентификации информационной системе. Идентификация тесно связана с аутентификацией.

    Первоначально в стеке протоколов PPP были определены два протокола аутентификации: Password Authentication Protocol (PAP) и Challenge Handshake Authentication Protocol (CHAP). Они описаны в RFC 1334 «PPP Authentication Protocols».

    В настоящее время PPP поддерживает несколько протоколов аутентификации:

    • Password Authentication Protocol (PAP);

    • Challenge Handshake Authentication Protocol (CHAP);

    • Microsoft Challenge-Handshake Authentication Protocol version 1.0 (MS-CHAP v1);

    • Microsoft Challenge Handshake Authentication Protocol version 2.0 (MS-CHAP v2);

    • Extensible Authentication Protocol — Transport Level Security (EAP-TLS);

    • Protected Extensible Authentication Protocol (PEAP).

    В PPP используется следующая терминология для описания аутентифицируемых узлов:

    • Аутентификатор (authenticator) — конец канала, требующий выполнения аутентификации. Аутентификатор определяет протокол аутентификации, который будет указан в пакетах Configure-Request, передаваемых в фазе установления канала.

    • Одноранговый узел (peer) — другая сторона канала «точка-точка», чья подлинность проверяется аутентификатором.

    2.5.1 Протокол Password Authentication Protocol (PAP)

    Протокол PAP — простой протокол двухстороннего рукопожатия (2-way handshake). Процесс аутентификации состоит из двух шагов:

    1. Запрос аутентификации. Узел отправляет аутентификатору запрос Authenticate-Request, который содержит имя пользователя и пароль.

    2. Ответ на запрос аутентификации. Аутентификатор проверяет полученные имя пользователя и пароль в локальной базе данных или пересылает их серверу аутентификации (например, RADIUS или TACACS+), и если они достоверны, отправляет узлу сообщение Authenticate-Ack. Аутентификация успешно завершается и начинается фаза конфигурирования протоколов сетевого уровня. Если аутентификация не успешна, аутентификатор отправляет узлу сообщение Authenticate-Nak и соединение завершается.

    В процесс аутентификации пароль передается в открытом виде, т. е. он не шифруется. В связи с этим, аутентификация PAP не является безопасной, т. к. не обеспечивает защиты от различного рода атак.
    1   2   3   4   5   6   7   8   9   ...   26

    написать администратору сайта