rfc2341.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,513 行 · 第 1/5 页

   Treatment of Checksum, Length, and Offset are as in 4.3.1.

         1. NAS->GW
             Proto=L2F, Seq=2, MID=1, CLID=73, Key=C(Rnd2)
             L2F_OPEN
                 Type: CHAP
                 Name: CHAP-name
                 Challenge: Rnd3
                 Response: <Value received, presumably C(Rnd3)>
                 ID: <ID used in challenge>

   The NAS has received a call, tried CHAP with a challenge value of
   Rnd3, and found that the client responded.  The claimed name lead the
   NAS to believe it was a Virtual dial-up client hosted by the Home
   Gateway.  The next free MID is allocated, and the information
   associated with the CHAP challenge/response is included in the
   connect notification.

      2. GW->NAS
          Proto=L2F, Seq=2, MID=1, CLID=22, Key=C(Rnd)
          L2F_OPEN

   The Home Gateway, by sending back the L2F_OPEN, accepts the client.

      3. NAS->GW
          Proto=PPP, Seq=0, MID=1, CLID=73, Key=C(Rnd2)
          <Frame follows>

      4. GW->NAS
          Proto=PPP, Seq=0, MID=1, CLID=22, Key=C(Rnd)
          <Frame follows>

   Traffic is now free to flow in either direction as sent by the remote
   client or the home site.  The contents is uninterpreted data, HDLC in
   this case.  Data traffic, since it is not the L2F protocol, does not
   usually use the Seq field, which is set to 0 in non-L2F messages (see
   the S bit in section 4.2.5 for details on an exception to this).







Valencia, et. al.               Historic                       [Page 17]

RFC 2341                       Cisco L2F                        May 1998


4.4 L2F management message types

   When an L2F packet's Proto field specifies L2F management, the body
   of the packet is encoded as zero or more options.  An option is a
   single octet "message type", followed by zero or more sub-options.
   Each sub-option is a single byte sub-option value, and further bytes
   as appropriate for the sub-option.

   Options in L2F are:


   Hex Value       Abbreviation       Description
   --------        ------------       -----------
    0x00            Invalid           Invalid message
    0x01            L2F_CONF          Request configuration
    0x02            L2F_CONF_NAME     Name of peer sending L2F_CONF
    0x03            L2F_CONF_CHAL     Random number peer challenges with
    0x04            L2F_CONF_CLID     Assigned_CLID for peer to use
    0x02            L2F_OPEN          Accept configuration
    0x01            L2F_OPEN_NAME     Name received from client
    0x02            L2F_OPEN_CHAL     Challenge client received
    0x03            L2F_OPEN_RESP     Challenge response from client
    0x04            L2F_ACK_LCP1      LCP CONFACK accepted from client
    0x05            L2F_ACK_LCP2      LCP CONFACK sent to client
    0x06            L2F_OPEN_TYPE     Type of authentication used
    0x07            L2F_OPEN_ID       ID associated with authentication
    0x08            L2F_REQ_LCP0      First LCP CONFREQ from client
    0x03            L2F_CLOSE         Request disconnect
    0x01            L2F_CLOSE_WHY     Reason code for close
    0x02            L2F_CLOSE_STR     ASCII string description
    0x04            L2F_ECHO          Verify presence of peer
    0x05            L2F_ECHO_RESP     Respond to L2F_ECHO

4.4.1 L2F message type: Invalid

   If a message is received with this value, or any value higher than
   the last recognized option value, or if an illegal packet as defined
   by other parts of this specification is received, the packet is
   considered invalid.  The packet MUST be discarded, and an L2F_CLOSE
   of the entire tunnel MUST be requested.  Upon receipt of an
   L2F_CLOSE, the tunnel itself may be closed.  All other received
   message MUST be discarded.  An implementation MAY close the tunnel
   after an interval of time appropriate to the characteristics of the
   tunnel.







Valencia, et. al.               Historic                       [Page 18]

RFC 2341                       Cisco L2F                        May 1998


   Note that packets with an invalid Key are discarded, but disconnect
   is not initiated.  This prevents denial-of-service attacks.  Invalid
   option types within a message MUST be treated as if the entire
   message type was invalid.

4.4.2 L2F_CONF

   The L2F message type is used to establish the tunnel between the NAS
   and the Home Gateway.  MID is always set to 0.  The body of such a
   message starts with the octet 0x01 (L2F_CONF), followed by all three
   of the sub-options below.

   The L2F_CONF_NAME sub-option MUST be present.  It is encoded as the
   octet value 0x02, followed by an octet specifying a non-zero length,
   followed by the indicated number of bytes, which are interpreted as
   the sender's ASCII name.

   The L2F_CONF_CHAL sub-option MUST be present.  It is encoded as the
   octet value 0x03, followed by a non-zero octet, followed by a number
   of bytes specified by this non-zero octet.

   The challenge value should be generated using whatever techniques
   provide the highest quality of random numbers available to a given
   implementation.

   The L2F_CONF_CLID sub-option MUST be present.  It is encoded as the
   octet 0x04, followed by four bytes of Assigned_CLID value.  The
   Assigned_CLID value is generated as a non-zero 16-bit integer value
   unique across all tunnels which exist on the sending system.  The
   least significant two octets of Assigned_CLID are set to this value,
   and the most significant two octets MUST be set to 0.

   The CLID field is sent as 0 in the initial L2F_CONF packet from NAS
   to Home Gateway, and otherwise MUST be sent containing the value
   specified in the Assigned_CLID field of the last L2F_CONF message
   received.

   Key MUST be set to 0 in all L2F_CONF packets, and no key field is
   included in the packet.

   When sent from a NAS to a Home Gateway, the L2F_CONF is the initial
   packet in the conversation.

   When sent from the Home Gateway to the NAS, an L2F_CONF indicates the
   Home Gateway's recognition of the tunnel creation request.  The Home
   Gateway MUST provide its name and its own challenge in the message
   body.




Valencia, et. al.               Historic                       [Page 19]

RFC 2341                       Cisco L2F                        May 1998


   In all packets following the L2F_CONF, the Key MUST be set to the
   CHAP-style hash of the received challenge bytes.  The CHAP-style hash
   is done over the concatenation of the low 8 bits of the assigned
   CLID, the secret, and the challenge value.  Generation of the 32-bit
   key value is discussed in section 4.2.11.

4.4.3 L2F_OPEN, tunnel establishment

   The L2F_OPEN message is used to provide tunnel setup closure (for a
   MID of 0) or to establish a client connection within a tunnel
   previously established by L2F_CONF and L2F_OPEN messages (MID not
   equal to 0).  This section describes tunnel establishment; section
   4.4.4 following describes clients established within the tunnel.

   An L2F_OPEN for tunnel establishment MUST contain only the sub-option
   0x03, L2F_OPEN_RESP.  This option MUST be followed by the octet 0x10,
   specifying the size of the 128-bit MD5 digest resulting from
   encrypting the challenge value in the L2F_CONF, along with the low
   byte of the Assigned_CLID.  After this byte MUST be the sixteen bytes
   of the generated MD5 digest.

   If during tunnel establishment an L2F_OPEN is received with an
   incorrect L2F_OPEN_RESP, the packet MUST be silently discarded.  It
   is recommended that such an event generate a log event as well.

4.4.4 L2F_OPEN, client establishment

   An L2F_OPEN (with non-zero MID) sent from the NAS to the Home Gateway
   indicates the presence of a new dial-in client.  When sent back from
   the Home Gateway to the NAS, it indicates acceptance of the client.
   This message starts with the octet 0x02.  When sent from the NAS, it
   may contain further sub-options.  When sent from the Home Gateway, it
   may not contain any sub-options.  All further discussion of sub-
   options in this section apply only to the NAS to Home Gateway
   direction.

   The L2F_OPEN_TYPE sub-option MUST be present.  It is encoded as the
   octet 0x06, followed by a single byte describing the type of
   authentication the NAS exchanged with the client in detecting the
   client's claimed identification.  Implicit in the authentication type
   is the encapsulation to be carried over the life of the session.  The
   authentication types are:

      0x01 Textual username/password exchange for SLIP
      0x02 PPP CHAP
      0x03 PPP PAP
      0x04 PPP no authentication
      0x05 SLIP no authentication



Valencia, et. al.               Historic                       [Page 20]

RFC 2341                       Cisco L2F                        May 1998


   The L2F_OPEN_NAME sub-option is encoded as the octet 0x01, followed
   by an octet specifying the length of the name, followed by the
   indicated number of bytes of the name.  This field MUST be present
   for any authentication type except 0x04 (None).  It MUST contain the
   name specified in the client's authentication response.

   The L2F_OPEN_CHAL sub-option is encoded as the octet 0x02, followed
   by an octet specifying the length of the challenge sent, followed by
   the challenge itself.  This field is only present for CHAP, and MUST
   contain the challenge value sent to the client by the NAS.

   The L2F_OPEN_RESP sub-option is encoded as the octet 0x03, followed
   by an octet specifying the length of the response received, followed
   by the client's response to the challenge.  For CHAP, this field
   contains the response value received by the NAS.  For PAP or textual
   authentication, it contains the clear text password received from the
   client by the NAS.  This field is absent for authentication 0x04
   "None".

   The L2F_ACK_LCP1 and L2F_ACK_LCP2 sub-options are encoded as the
   octets 0x04 and 0x05 respectively, followed in either case by two
   octets in network byte order specifying the length of the LCP CONFACK
   last received from or sent to the client.  Following these octets is
   an exact copy of the CONFACK packet.  L2F_ACK_LCP1 specifies a copy
   of the closing CONFACK received from the client, and L2F_ACK_LCP2
   specifies a copy of the closing CONFACK sent to the client by the
   NAS.

   The L2F_REQ_LCP0 sub-option is encoded as the octet 0x08, followed by
   two octets in network byte order specifying the length of the LCP
   CONFREQ initially received from the client.  This may be used by the
   Home Gateway to detect capabilities of the client which were
   negotiated away while starting LCP with the NAS.  Detection of such
   options may be used by the Home Gateway to decide to renegotiate LCP.

   The L2F_OPEN_ID sub-option is encoded as the octet 0x06, followed by
   a single octet.  This sub-option is only present for CHAP; the single
   octet contains the CHAP Identifier value sent to the client during
   the CHAP challenge.

   The Home Gateway may choose to ignore any sub-option of the L2F_OPEN,
   and accept the connection anyway.  The Home Gateway would then have
   to undertake its own LCP negotiations and authentication.  To
   maximize the transparency of the L2F tunnel, it is recommended that
   extra negotiations and authentication be avoided if possible.






Valencia, et. al.               Historic                       [Page 21]

RFC 2341                       Cisco L2F                        May 1998


4.4.5 L2F_CLOSE

   This message is encoded as the byte 0x03.  An L2F_CLOSE may be sent
   by either side of the tunnel at any time.  When sent with MID of 0,
   it indicates the desire to terminate the entire tunnel and all
   clients within the tunnel.  When sent from the Home Gateway in
   response to an L2F_OPEN, it indicates that the Home Gateway has
   declined the connection.  When sent with a non-zero MID, it indicates
   the termination of that client within the tunnel.

   The L2F_CLOSE_WHY sub-option is encoded as the byte 0x01 followed
   four bytes in network byte order specifying a bit mask of reasons for
   the disconnection.  The bits are encoded as:

      0x00000001 Authentication failed
      0x00000002 Out of resources
      0x00000004 Administrative intervention
      0x00000008 User quota exceeded
      0x00000010 Protocol error
      0x00000020 Unknown user
      0x00000040 Incorrect password
      0x00000080 PPP configuration incompatible
      0x00000100 Wrong multilink PPP destination

   Bits in the mask 0xFF000000 are reserved for per-vendor
   interpretation.

   An implementation can choose to not provide status bits even if it
   detects a condition described by one of these bits.  For instance, an
   implementation may choose to not use 0x00000020 due to security