rfc2341.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,585 行 · 第 1/5 页

   Each subsequent packet is sent with the next increment of the
   sequence number.  The sequence number is thus a free running counter
   represented modulo 256.  There is distinct Sequence number state
   (i.e., counter) for each distinct MID value.

   For packets with S bit and sequence number, the sequence number is
   used to protect against duplication of packets, as follows:

   The receiving side of the tunnel records the sequence number of each
   valid L2F packet it receives.  If a received packet appears to have a
   value less than or equal to the last received value, the packet MUST
   be silently discarded.  Otherwise, the packet is accepted and the
   sequence number in the packet recorded as the latest value last
   received.

   For purposes of detecting duplication, a received sequence value is
   considered less than or equal to the last received value if its value
   lies in the range of the last value and its 127 successor values.
   For example, if the last received sequence number was 15, then
   packets with sequence numbers 0 through 15, as well as 144 through
   255, would be considered less than or equal to, and would be silently
   discarded.  Otherwise it would be accepted.

4.2.6 Packet Multiplex ID

   The Multiplex ID ("MID") identifies a particular connection within
   the tunnel.  Each new connection is assigned a MID currently unused
   within the tunnel.  It is recommended that the MID cycle through the
   entire 16-bit namespace, to reduce aliasing between previous and
   current sessions.  A MID value which has been previously used within
   a tunnel, has been closed, and will now be used again, must be
   considered as an entirely new MID, and initialised as such.

   The MID with value 0 is special; it is used to communicate the state
   of the tunnel itself, as distinct from any connection within the
   tunnel.  Only L2F_PROTO packets may be sent using an MID of 0; if any



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


   other type is sent on MID 0, the packet is illegal and MUST be
   processed as defined in 4.4.1.

4.2.7 Client ID

   The Client ID ("CLID") is used to assist endpoints in demultiplexing
   tunnels when the underlying point-to-point substrate lacks an
   efficient or dependable technique for doing so directly.  Using the
   CLID, it is possible to demultiplex multiple tunnels whose packets
   arrive over the point-to-point media interleaved, without requiring
   media-specific semantics.

   When transmitting the L2F_CONF message (described below), the peer's
   CLID must be communicated via the Assigned_CLID field.  This MUST be
   a unique non-zero value on the sender's side, which is to be expected
   in the Home Gateway's L2F_CONF response, as well as all future non-
   L2F_CONF packets received.

   The CLID value from the last valid L2F_CONF message received MUST be
   recorded and used as the CLID field value for all subsequent packets
   sent to the peer.

   Packets with an unknown Client ID MUST be silently discarded.

   For the initial packet sent during tunnel establishment, where no
   L2F_CONF has yet been received, the CLID field MUST be set to 0.

   Thus, during L2F_CONF each side is told its CLID value.  All later
   packets sent, tagged with this CLID value, serve as a tag which
   uniquely identifies this peer.

4.2.8 Length

   Length is the size in octets of the entire packet, including header,
   all fields present, and payload.  Length does not reflect the
   addition of the checksum, if one is present.  The packet should be
   silently discarded if the received packet is shorter than the
   indicated length.  Additional bytes present in the packet beyond the
   indicated length MUST be silently ignored.

4.2.9 Packet Checksum

   The Checksum is present if the C bit is present in the header flags.
   It is a 16-bit CRC as used by PPP/HDLC (specifically, FCS-16 [3]).
   Is is applied over the entire packet starting with the first byte of
   L2F flags, through the last byte of payload data.  The checksum is
   then added as two bytes immediately following the last byte of
   payload data.



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


4.2.10 Payload Offset

   The Offset is present if the F bit is set in the header flags.  This
   field specifies the number of bytes past the L2F header at which the
   payload data is expected to start.  If it is 0, or the F bit is not
   set, the first byte following the last byte of L2F header is the
   first byte of payload data.

   It is recommended that data skipped due to the payload offset be
   initialized to 0's.

   For architectures where it is more efficient to have the payload
   start at an aligned 32-bit boundary with respect to the L2F header,
   it is recommended that the F bit be set, and an offset of 0 be used.

4.2.11 Packet Key

   The Key field is present if the K bit is set in the L2F header.  The
   Key is based on the authentication response last given to the peer
   during tunnel creation (the details of tunnel creation are provided
   in the next section).  It serves as a key during the life of a
   session to resist attacks based on spoofing.  If a packet is received
   in which the Key does not match the expected value, the packet MUST
   be silently discarded.  Such handling takes precedence over 4.4.1.

   The Key value is generated by taking the 128-bit authentication
   response from the peer, interpreting it as four adjacent 32-bit words
   in network byte order, XOR'ing these words together, and using the
   resulting 32-bit value as the Key.

4.2.12 Packet priority

   If the P bit in the L2F header is set, this packet is a "priority"
   packet.  When possible for an implementation, a packet received with
   the P bit should be processed in preference to previously received
   unprocessed packets without the P bit.

   The P bit may be set by an implementation based on criteria beyond
   the scope of this specification.  However, it is recommended that PPP
   keepalive traffic, if any, be sent with this bit set.

4.3 L2F Tunnel Establishment

   When the point-to-point link is first initiated between the NAS and
   the Home Gateway, the endpoints communicate on MID 0 prior to
   providing general L2F services to clients.  This communication is
   used to verify the presence of L2F on the remote end, and to permit
   any needed authentication.



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


   The protocol for such negotiation is always 1, indicating L2F
   management.  The message itself is structured as a sequence of single
   octets indicating an option, followed by zero or more further octets
   formatted as needed for the option.

4.3.1 Normal Tunnel Negotiation Sequence

   The establishment sequence is best illustrated by a "typical"
   connection sequence.  Detailed description of each functions follows,
   along with descriptions of the handling of exceptional conditions.

   Each packet is described as a source->destination on one line, a
   description of the L2F packet field contents on the next, and the
   contents of the packet's body on following lines.  The exact encoding
   of octets will be described later.

   Note that this example uses the Key option, but does not use the
   Offset and Checksum options.  The Length field would be present,
   reflecting the actual length of the packets as encoded as an octet
   stream.

      1. NAS->GW:
          Proto=L2F, Seq=0, MID=0, CLID=0, Key=0
          L2F_CONF
              Name: NAS_name
              Challenge: Rnd
              Assigned_CLID: 22

   The NAS decides that a tunnel must be initiated from the NAS to the
   GW.  An L2F packet is sent with the Proto field indicating an L2F
   management message is contained.

   Because the tunnel is being initiated, Key is set to 0.  The sequence
   number starts at 0; the MID is 0 to reflect the establishment of the
   tunnel itself.  Since the NAS has not yet received an L2F_CONF, the
   CLID is set to 0.

   The body of the packet specifies the claimed name of the NAS, and a
   challenge random number which GW will use in authenticating itself as
   a valid tunnel endpoint.  Assigned_CLID is generated to be a value
   not currently assigned out to any other tunnel to any other Home
   Gateway.









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


      2. GW->NAS:
          Proto=L2F, Seq=0, MID=0, CLID=22, Key=0
          L2F_CONF
              Name: GW_name
              Challenge: Rnd2
              Assigned_CLID: 73

   The Home Gateway has processed the previous packet, and sends a
   response.  The protocol continues to be L2F, with a sequence number 0
   (each side maintains its own sequence number for transmissions).  MID
   continues to be 0 to reflect tunnel establishment.  CLID reflects the
   Assigned_CLID field of the L2F_CONF received.  The Key continues to
   be 0 during this phase of tunnel establishment.

   The body contains the Home Gateway's name, its own random number
   challenge, and its own Assigned_CLID for the NAS to place in the CLID
   field of future packets.  The CLID is generated in an analogous
   manner to that of the NAS.  After this, all packets received from the
   NAS must be tagged with a CLID field containing 73, and all packets
   sent to the NAS must be tagged with a CLID field containing 22.

      3. NAS->GW
          Proto=L2F, Seq=1, MID=0, CLID=73, Key=C(Rnd2)
          L2F_OPEN
              Response: C(Rnd2)

   The NAS responds with its Key now set to reflect the shared secret.
   The Key is a CHAP-style hash of the random number received; each
   packet hereafter will reflect this calculated value, which serves as
   a key for the life of the tunnel.  Both the Home Gateway and the NAS
   use such Keys for the life of the tunnel.  The Key is a 32-bit
   representation of the MD5 digest resulting from encrypting the shared
   secret; the full MD5 digest is included in the L2F_OPEN response, in
   the "response" field.

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

   The Home Gateway provides closure of the key from the NAS, reflected
   in both the Key field as well as the "response" field.  The tunnel is
   now available for clients to be established.








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


4.3.2 Normal Client Negotiation Sequence

   This section describes the establishment of a Virtual dial-up client
   on a NAS into a Home Gateway.  It assumes a tunnel has been created
   in the way described in 4.3.1.  The client for this example is a PPP
   client configured for CHAP.

   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).