rfc1968.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Data

      The Data field is zero or more octets and contains uninterpreted
      data for use by the sender.  The data may consist of any binary
      value and may be of any length from zero to the peer's established
      MRU minus four.

4. ECP Configuration Options

   ECP Configuration Options allow negotiation of encryption algorithms
   and their parameters.  ECP uses the same Configuration Option format
   defined for LCP [1], with a separate set of Options.

   Configuration Options, in this protocol, indicate algorithms that the
   receiver is willing or able to use to decrypt data sent by the
   sender.  Systems may offer to accept several algorithms, and
   negotiate a single one that will be used.

   Up-to-date values of the ECP Option Type field are specified in the
   most recent "Assigned Numbers" RFC [4].  Current values are assigned
   as follows:





Meyer                       Standards Track                     [Page 6]

RFC 1968                     PPP Encryption                    June 1996


         ECP Option      Encryption type

         0               OUI
         1               DESE


   All compliant ECP implementations SHOULD implement ECP option 1 - the
   PPP DES Encryption Protocol (DESE) [6].

   Vendors who want to use proprietary encryption MAY use the OUI
   mechanism to negotiate these without recourse to requesting an
   assigned option number from the Internet Assigned Numbers Authority.
   All other encryption options are registered by IANA.  At the time of
   writing only DESE (option 1) is registered.  Other registered options
   may be found by referring to future versions of the Assigned Numbers
   RFC.

4.1 Proprietary Encryption OUI

   Description

      This Configuration Option provides a way to negotiate the use of a
      proprietary encryption protocol.

      Vendor's encryption protocols are distinguished from each other by
      means of an Organisationally Unique Identifier (OUI), namely the
      first three octets of a Vendor's Ethernet address assigned by IEEE
      802.

      Since the first matching encryption will be used, it is
      recommended that any known OUI encryption options be transmitted
      first, before the common options are used.

      Before accepting this option, the implementation must verify that
      the OUI identifies a proprietary algorithm that the implementation
      can decrypt, and that any vendor specific negotiation values are
      fully understood.

      A summary of the Proprietary Encryption OUI Configuration Option
      format is shown below.  The fields are transmitted from left to
      right.










Meyer                       Standards Track                     [Page 7]

RFC 1968                     PPP Encryption                    June 1996


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |       OUI ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            OUI       |    Subtype    |  Values...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Type

       0

   Length

      >= 6

   IEEE OUI

      The IEEE OUI is the most significant three octets of an Ethernet
      Physical Address, assigned to the vendor by IEEE 802.  This
      identifies the option as being proprietary to the indicated
      vendor.  The bits within the octet are in canonical order, and the
      most significant octet is transmitted first.

   Subtype

      This field is specific to each OUI, and indicates an encryption
      type for that OUI.  There is no standardisation for this field.
      Each OUI implements its own values.

   Values

      This field is zero or more octets, and contains additional data as
      determined by the vendor's encryption protocol.

4.2 Publicly Available Encryption Types

   Description

      These Configuration Options provide a way to negotiate the use of
      a publicly defined encryption algorithm.

      These protocols should be made available to interested parties,
      but may have certain licencing or export restrictions associated
      with them.  For additional information, refer to the encryption
      protocol documents that define each of the encryption types.




Meyer                       Standards Track                     [Page 8]

RFC 1968                     PPP Encryption                    June 1996


      A summary of the Encryption Type Configuration Option format is
      shown below.  The fields are transmitted from left to right.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |  Values...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


    Type

       1 to 254, indicating the encryption protocol option
       being negotiated.  DESE [6] is option type 1.  Refer to the
       latest Assigned Numbers RFC for other encryption protocols.

    Length

       >= 2

   Values

      This field is zero or more octets, and contains additional data as
      determined by the encryption protocol.

4.3 Negotiating an Encryption Algorithm

   ECP uses LCP option negotiation techniques to negotiate encryption
   algorithms.  In contrast with most other LCP or NCP negotiation of
   multiple options, ECP negotiation is expected to converge on a single
   mutually agreeable option (encryption algorithm) - or none.
   Encryption SHOULD be negotiated in both directions, but the
   algorithms MAY be different.

   An implementation willing to decrypt using a particular encryption
   algorithm (or one of a set of algorithms) offers the algorithm(s) as
   an option (or options) in an ECP Configure-Request - call this end
   the Decrypter; call the peer the Encrypter.

   A Decrypter supporting more than one encryption algorithm may send a
   Configure-Request containing either:

   o  an ordered list of options, with the most-preferred encryption
      algorithm coming first.

   o  Or may just offer its preferred (not already Rejected) option.





Meyer                       Standards Track                     [Page 9]

RFC 1968                     PPP Encryption                    June 1996


   An Encrypter wishing to accept the first option (of several) MAY
   Configure-Ack ALL Options to indicate complete acceptance of the
   first-listed, preferred, algorithm.

   Otherwise, if the Encrypter does not recognise - or is unwilling to
   support - an option it MUST send a Configure-Reject for that option.
   Where more than one option is offered, the Encrypter SHOULD
   Configure-Reject all but a single preferred option.

   If the Encrypter Configure-Rejects all offered ECP options - and the
   Decrypter has no further (non-rejected) options it can offer in a
   Configure-Request - the Encrypter SHOULD take the link down.

   If the Encrypter recognises an option, but it is not acceptable due
   to values in the request (or optional parameters not in the request),
   it MUST send a Configure-Nak with the option modified appropriately.
   The Configure-Nak MUST contain only those options that will be
   acceptable.  The Decrypter SHOULD send a new Configure-Request with
   only the single preferred option, adjusted as specified in the
   Configure-Nak.

5. Security Considerations

   Negotiation of encryption using PPP is designed to provide protection
   against eavesdropping on that link.  The strength of the protection
   is dependent on the encryption algorithm used and the care with which
   any 'secret' used by the encryption algorithm is protected.

   It must be recognised that complete security can only be obtained
   through end-to-end security between hosts.

References

   [1]  Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", STD
        51, RFC 1661, Daydreamer, July 1994.

   [2]  Sklower, K., Lloyd, B., McGregor, G. and and D. Carr, "The PPP
        Multilink Protocol (MP)", RFC 1717, University of California,
        Berkeley, November 1994.

   [3]  Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
        1994.

   [4]  Reynolds, J., and Postel, J.; "ASSIGNED NUMBERS", STD 2,
        RFC 1700, USC/Information Sciences Institute, October 1994.

   [5]  Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
        1962, Novell, June 1996.



Meyer                       Standards Track                    [Page 10]

RFC 1968                     PPP Encryption                    June 1996


   [6]  Sklower, K., and G. Meyer, "The PPP DES Encryption Protocol
        (DESE)", RFC 1969, University of California, Berkeley, June
        1996.

Acknowledgements

   The style and approach of this proposal owes much to the work on the
   Compression CP [5].

Chair's Address

   The working group can be contacted via the current chair:

   Karl Fox
   Ascend Communications
   3518 Riverside Drive, Suite 101
   Columbus, Ohio 43221

   EMail: [e-mail]

Author's Address

   Gerry Meyer
   Spider Systems
   Stanwell Street
   Edinburgh EH6 5NG
   Scotland, UK

   Phone: (UK) 131 554 9424
   Fax:   (UK) 131 554 0649
   EMail: [e-mail]




















Meyer                       Standards Track                    [Page 11]