Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Understanding Extensible Authentication Protocol

    The JunosE Software supports Extensible Authentication Protocol (EAP) for authenticating a peer before allowing network layer protocols to transmit over the link. EAP supports multiple authentication methods, including EAP-TLS and EAP-MD5-Challenge. The EAP server and the peer negotiate the specific authentication method to be used. Figure 1 illustrates the three components required for EAP: an EAP authenticator, an EAP server, and an EAP client.

    Figure 1: Authentication with EAP

    Authentication with EAP

    After LCP negotiation, JunosE starts the EAP negotiation process by initiating an identity exchange with the EAP client on the peer. The router sends an EAP identity request packet to the peer, which replies with an EAP identity response packet. After this exchange, the E Series router acts only as a pass-through device, enabling the EAP server residing on the backend authentication server to select and negotiate the particular EAP authentication method directly with the EAP client on the peer.

    The JunosE Software forwards or discards packets received from the backend authentication router and the peer depending on the identifying code contained in the packet.

    The E Series router forwards:

    • Packets received from the peer with a Response code
    • Packets received from the backend authentication server with a Request, Success, or Failure code

    The E Series router discards:

    • Packets received from the peer with a Request, Success, or Failure code
    • Packets received from the backend authentication server with a Response code

    The JunosE Software determines the outcome of the authentication based only on the Accept or Reject indication sent by the RADIUS server

    EAP Types

    The JunosE Software has been qualified to work with the EAP authentication methods—known as EAP types—described in Table 1. Other EAP authentication methods have not been qualified with the JunosE Software

    Table 1: Supported EAP Types

    EAP Type

    Behavior

    1—Identity

    When LCP negotiation completes, PPP sends an initial EAP identity request packet to the peer. The EAP identity response packet received from the peer is forwarded to AAA. AAA forwards the response as an Access-Request to the RADIUS server hosted on the backend authentication server.

    2—Notification

    The JunosE Software forwards Notification requests from the backend authentication server to the peer and Notification responses from the peer to the server. The JunosE Software does not initiate any Notification requests or responses.

    3—NAK

    The JunosE Software forwards the NAKs received from the peer to the backend authentication server.

    4—MD5-Challenge

    The JunosE Software acts as a pass-through for the EAP-MD5-Challenge negotiated between the peer and backend authentication server.

    13—TLS

    The JunosE Software acts as a pass-through for the EAP-TLS negotiated between the peer and backend authentication server.

    EAP Packet Retransmission

    PPP retransmits the EAP request packets to the peer. The RADIUS client retransmits the EAP response packets to the RADIUS Server. The request packets to the peer are governed by nonconfigurable values for retransmission attempts and interval. The configuration of the RADIUS client determines retransmission values for response packets to the RADIUS server. The retransmission values are as follows:

    • PPP makes five attempts to retransmit an EAP request before the authentication attempt is terminated. You cannot configure the number of retransmission attempts.
    • When an EAP request is transmitted, a timer is started with a nonconfigurable retransmission interval value of 3 seconds. When the timer expires, the EAP request is retransmitted.

    In some cases, you might want a longer retransmission interval. For example, you might need to accommodate the additional time required by a user to enter information or scan a fingerprint or retina. RADIUS can instruct the JunosE Software to wait longer by passing an appropriate Session-Timeout attribute in the RADIUS Access-Challenge packet. This retransmission interval value applies only to the EAP request packet present in the RADIUS Access-Challenge packet.

    The Session-Timeout attribute value overrides the default retransmission interval value, up to a maximum of 30 seconds. If RADIUS recommends a greater value, then PPP resets it back to 30 seconds in order to avoid longer or infinite delays.

    EAP Behavior in an L2TP Environment

    EAP behavior in an L2TP environment varies depending on whether the router acts as a LAC or an LNS,

    When the E Series Router Acts as a LAC

    When PPP forwards an EAP identity response packet to AAA, AAA might be configured to return a tunnel response upon successful validation of the packet. You can use AAA domain maps, a AAA profile, or both to force such tunneling.

    On an LAC, PPP forwards the PPP EAP authentication information to the LNS during the establishment of the L2TP session. This authentication information consists of the EAP type, the data appropriate to the type (such as a username) contained in the EAP identity response packet, and the identifier of the EAP identity response packet. If the LNS trusts the LAC, then the LNS uses this authentication information to resume the EAP negotiation where the LAC left off.

    L2TP on an LAC forwards the PPP EAP authentication information in the Proxy Authen AVPs as described in L2TP Proxy Authenticate Extensions for EAP—draft-ietf-l2tpext-proxy-authen-ext-eap-01.txt (December 2006 expiration).

    When the E Series Router Acts as an LNS

    PPP on an LNS resumes the EAP negotiation operation by detecting the presence of EAP information in the proxy authentication data supplied by L2TP. PPP reconstructs the EAP identity response packet from the proxy authentication data and forwards it to AAA.

    L2TP on an LNS processes the received Proxy Authen AVPs as described in L2TP Proxy Authenticate Extensions for EAP—draft-ietf-l2tpext-proxy-authen-ext-eap-01.txt (December 2006 expiration).

    Limitations

    EAP is subject to internal limits. When the E Series router acts as a pass-through between the backend authentication server and the peer, EAP packets traverse the controllers within the router. The size of EAP packets and fragments tends to be larger than the buffer exchange limit—1450 bytes—between the controllers. This intercontroller buffer exchange limit is tuned for the optimal system performance and scalability; also, when stacked over L2TP on LNS, it prevents PPP control packets from causing IP fragmentation and reassembly on the Ethernet downlink. Hence, if EAP is configured as a PPP authentication protocol, then EAP packet or fragment size is affected by the intercontroller buffer exchange limit as follows:

    • The MRU value advertised by JunosE in the LCP request packet takes the lowest of the following values:
      • the lower layer MRU minus the PPP overhead
      • the configured MRU
      • 1450 bytes
    • The MTU value is initialized by JunosE to the lowest of the following values:
      • the lower layer MTU minus the PPP overhead
      • the peer MRU
      • 1450 bytes

    The MTU value is passed to RADIUS in an Access-Request packet by means of the Framed-Mtu attribute.

    Performance

    When EAP is configured on the router, it affects the performance and scalability of PPP in terms of round-trip packet exchanges, negotiations, EAP server requirements, and EAP client requirements. For information on the number of PPP interfaces supported with EAP, see the Link Layer Maximums tables in Appendix A, System Maximums, of the current JunosE Release Notes.

    • Performance depends on the number of packets exchanged during the negotiation. When the number of packets exchanged increases—that is, when the number of round-trips increases—it takes longer to finish the interface negotiation. System resources are locked for a longer duration. As a result it takes longer to bring up all the interfaces.

      The number of round-trip message exchanges varies with the EAP authentication method. When no retransmission of packets takes place and there is no fragmentation, PAP and CHAP require one round-trip, EAP-MD5-Challenge requires two round-trips, and EAP-TLS requires four round-trips.

      Retransmission increases the number of round-trips. When the negotiated EAP authentication method requires fragmentation, such as for the exchange of large certificate chains, then the number of round-trips increases.

    • The number of simultaneous EAP negotiations is limited to 50 because of resource limitations. Consequently, the time required to bring up interfaces when you configure EAP authentication is longer than when you specify PAP or CHAP authentication.
    • EAP authentication methods fragment packets when the EAP packet size is greater than the link MTU. The EAP server must fragment the EAP packet to the size of the Framed-Mtu attribute contained in the RADIUS Access-Request packet.

      If the server fragments the packet to a larger size than specified by the attribute, then JunosE drops the packet, because the E Series router acts as a pass-through device and is not involved in the authentication method's fragmentation and reassembly mechanisms.

      On the other hand, if the EAP server fragments the EAP packet to a smaller size than specified by the attribute, then performance decreases because of the increased number of smaller packets that must be exchanged.

    • The EAP client on the peer must fragment the EAP packets to the size of the link MTU on the E Series router. When it does not do so, performance can be affected.

    Published: 2014-08-14