rfc2661.txt

第二层隧道模块l2tp源码,开发环境为linux

4.0 Control Message Attribute Value Pairs

   To maximize extensibility while still permitting interoperability, a
   uniform method for encoding message types and bodies is used
   throughout L2TP.  This encoding will be termed AVP (Attribute-Value
   Pair) in the remainder of this document.











Townsley, et al.            Standards Track                    [Page 12]

RFC 2661                          L2TP                       August 1999


4.1 AVP Format

   Each AVP is encoded as:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H| rsvd  |      Length       |           Vendor ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Attribute Type        |        Attribute Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       [until Length is reached]...                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first six bits are a bit mask, describing the general attributes
   of the AVP.

   Two bits are defined in this document, the remaining are reserved for
   future extensions.  Reserved bits MUST be set to 0. An AVP received
   with a reserved bit set to 1 MUST be treated as an unrecognized AVP.

   Mandatory (M) bit: Controls the behavior required of an
   implementation which receives an AVP which it does not recognize. If
   the M bit is set on an unrecognized AVP within a message associated
   with a particular session, the session associated with this message
   MUST be terminated. If the M bit is set on an unrecognized AVP within
   a message associated with the overall tunnel, the entire tunnel (and
   all sessions within) MUST be terminated. If the M bit is not set, an
   unrecognized AVP MUST be ignored. The control message must then
   continue to be processed as if the AVP had not been present.

   Hidden (H) bit: Identifies the hiding of data in the Attribute Value
   field of an AVP.  This capability can be used to avoid the passing of
   sensitive data, such as user passwords, as cleartext in an AVP.
   Section 4.3 describes the procedure for performing AVP hiding.

   Length: Encodes the number of octets (including the Overall Length
   and bitmask fields) contained in this AVP. The Length may be
   calculated as 6 + the length of the Attribute Value field in octets.
   The field itself is 10 bits, permitting a maximum of 1023 octets of
   data in a single AVP. The minimum Length of an AVP is 6. If the
   length is 6, then the Attribute Value field is absent.

   Vendor ID: The IANA assigned "SMI Network Management Private
   Enterprise Codes" [RFC1700] value.  The value 0, corresponding to
   IETF adopted attribute values, is used for all AVPs defined within
   this document. Any vendor wishing to implement their own L2TP
   extensions can use their own Vendor ID along with private Attribute



Townsley, et al.            Standards Track                    [Page 13]

RFC 2661                          L2TP                       August 1999


   values, guaranteeing that they will not collide with any other
   vendor's extensions, nor with future IETF extensions. Note that there
   are 16 bits allocated for the Vendor ID, thus limiting this feature
   to the first 65,535 enterprises.

   Attribute Type: A 2 octet value with a unique interpretation across
   all AVPs defined under a given Vendor ID.

   Attribute Value: This is the actual value as indicated by the Vendor
   ID and Attribute Type. It follows immediately after the Attribute
   Type field, and runs for the remaining octets indicated in the Length
   (i.e., Length minus 6 octets of header). This field is absent if the
   Length is 6.

4.2 Mandatory AVPs

   Receipt of an unknown AVP that has the M-bit set is catastrophic to
   the session or tunnel it is associated with. Thus, the M bit should
   only be defined for AVPs which are absolutely crucial to proper
   operation of the session or tunnel. Further, in the case where the
   LAC or LNS receives an unknown AVP with the M-bit set and shuts down
   the session or tunnel accordingly, it is the full responsibility of
   the peer sending the Mandatory AVP to accept fault for causing an
   non-interoperable situation. Before defining an AVP with the M-bit
   set, particularly a vendor-specific AVP, be sure that this is the
   intended consequence.

   When an adequate alternative exists to use of the M-bit, it should be
   utilized. For example, rather than simply sending an AVP with the M-
   bit set to determine if a specific extension exists, availability may
   be identified by sending an AVP in a request message and expecting a
   corresponding AVP in a reply message.

   Use of the M-bit with new AVPs (those not defined in this document)
   MUST provide the ability to configure the associated feature off,
   such that the AVP is either not sent, or sent with the M-bit not set.

4.3 Hiding of AVP Attribute Values

   The H bit in the header of each AVP provides a mechanism to indicate
   to the receiving peer whether the contents of the AVP are hidden or
   present in cleartext.  This feature can be used to hide sensitive
   control message data such as user passwords or user IDs.

   The H bit MUST only be set if a shared secret exists between the LAC
   and LNS. The shared secret is the same secret that is used for tunnel
   authentication (see Section 5.1.1).  If the H bit is set in any




Townsley, et al.            Standards Track                    [Page 14]

RFC 2661                          L2TP                       August 1999


   AVP(s) in a given control message, a Random Vector AVP must also be
   present in the message and MUST precede the first AVP having an H bit
   of 1.

   Hiding an AVP value is done in several steps. The first step is to
   take the length and value fields of the original (cleartext) AVP and
   encode them into a Hidden AVP Subformat as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length of Original Value    |   Original Attribute Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ...                          |             Padding ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length of Original Attribute Value:  This is length of the Original
   Attribute Value to be obscured in octets. This is necessary to
   determine the original length of the Attribute Value which is lost
   when the additional Padding is added.

   Original Attribute Value:  Attribute Value that is to be obscured.

   Padding:  Random additional octets used to obscure length of the
   Attribute Value that is being hidden.

   To mask the size of the data being hidden, the resulting subformat
   MAY be padded as shown above. Padding does NOT alter the value placed
   in the Length of Original Attribute Value field, but does alter the
   length of the resultant AVP that is being created. For example, If an
   Attribute Value to be hidden is 4 octets in length, the unhidden AVP
   length would be 10 octets (6 + Attribute Value length). After hiding,
   the length of the AVP will become 6 + Attribute Value length + size
   of the Length of Original Attribute Value field + Padding. Thus, if
   Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24
   octets.

   Next, An MD5 hash is performed on the concatenation of:

   + the 2 octet Attribute number of the AVP
   + the shared secret
   + an arbitrary length random vector

   The value of the random vector used in this hash is passed in the
   value field of a Random Vector AVP. This Random Vector AVP must be
   placed in the message by the sender before any hidden AVPs. The same
   random vector may be used for more than one hidden AVP in the same




Townsley, et al.            Standards Track                    [Page 15]

RFC 2661                          L2TP                       August 1999


   message. If a different random vector is used for the hiding of
   subsequent AVPs then a new Random Vector AVP must be placed in the
   command message before the first AVP to which it applies.

   The MD5 hash value is then XORed with the first 16 octet (or less)
   segment of the Hidden AVP Subformat and placed in the Attribute Value
   field of the Hidden AVP.  If the Hidden AVP Subformat is less than 16
   octets, the Subformat is transformed as if the Attribute Value field
   had been padded to 16 octets before the XOR, but only the actual
   octets present in the Subformat are modified, and the length of the
   AVP is not altered.

   If the Subformat is longer than 16 octets, a second one-way MD5 hash
   is calculated over a stream of octets consisting of the shared secret
   followed by the result of the first XOR.  That hash is XORed with the
   second 16 octet (or less) segment of the Subformat and placed in the
   corresponding octets of the Value field of the Hidden AVP.

   If necessary, this operation is repeated, with the shared secret used
   along with each XOR result to generate the next hash to XOR the next
   segment of the value with.

   The hiding method was adapted from RFC 2138 [RFC2138] which was taken
   from the "Mixing in the Plaintext" section in the book "Network
   Security" by Kaufman, Perlman and Speciner [KPS].  A detailed
   explanation of the method follows:

   Call the shared secret S, the Random Vector RV, and the Attribute
   Value AV. Break the value field into 16-octet chunks p1, p2, etc.
   with the last one padded at the end with random data to a 16-octet
   boundary.  Call the ciphertext blocks c(1), c(2), etc.  We will also
   define intermediate values b1, b2, etc.

          b1 = MD5(AV + S + RV)   c(1) = p1 xor b1
          b2 = MD5(S  + c(1))     c(2) = p2 xor b2
                      .                       .
                      .                       .
                      .                       .
          bi = MD5(S  + c(i-1))   c(i) = pi xor bi

   The String will contain c(1)+c(2)+...+c(i) where + denotes
   concatenation.

   On receipt, the random vector is taken from the last Random Vector
   AVP encountered in the message prior to the AVP to be unhidden.  The
   above process is then reversed to yield the original value.





Townsley, et al.            Standards Track                    [Page 16]

RFC 2661                          L2TP                       August 1999


4.4 AVP Summary

   The following sections contain a list of all L2TP AVPs defined in
   this document.

   Following the name of the AVP is a list indicating the message types
   that utilize each AVP. After each AVP title follows a short
   description of the purpose of the AVP, a detail (including a graphic)
   of the format for the Attribute Value, and any additional information
   needed for proper use of the avp.

4.4.1 AVPs Applicable To All Control Messages

   Message Type (All Messages)

      The Message Type AVP, Attribute Type 0, identifies the control
      message herein and defines the context in which the exact meaning
      of the following AVPs will be determined.

      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Message Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type is a 2 octet unsigned integer.

      The Message Type AVP MUST be the first AVP in a message,
      immediately following the control message header (defined in
      section 3.1). See Section 3.2 for the list of defined control
      message types and their identifiers.

      The Mandatory (M) bit within the Message Type AVP has special
      meaning. Rather than an indication as to whether the AVP itself
      should be ignored if not recognized, it is an indication as to
      whether the control message itself should be ignored. Thus, if the
      M-bit is set within the Message Type AVP and the Message Type is
      unknown to the implementation, the tunnel MUST be cleared.  If the
      M-bit is not set, then the implementation may ignore an unknown
      message type. The M-bit MUST be set to 1 for all message types
      defined in this document. This AVP may not be hidden (the H-bit
      MUST be 0).  The Length of this AVP is 8.







Townsley, et al.            Standards Track                    [Page 17]

RFC 2661                          L2TP                       August 1999


   Random Vector (All Messages)

      The Random Vector AVP, Attribute Type 36, is used to enable the
      hiding of the Attribute Value of arbitrary AVPs.

      The Attribute Value field for this AVP has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Random Octet String ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Random Octet String may be of arbitrary length, although a
      random vector of at least 16 octets is recommended.  The string
      contains the random vector for use in computing the MD5 hash to
      retrieve or hide the Attribute Value of a hidden AVP (see Section
      4.2).

      More than one Random Vector AVP may appear in a message, in which
      case a hidden AVP uses the Random Vector AVP most closely
      preceding it.  This AVP MUST precede the first AVP with the H bit
      set.

      The M-bit for this AVP MUST be set to 1.  This AVP MUST NOT be
      hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the