rfc2888.txt

RFC 的详细文档！

                                     | PPP Header           |
                                     | (SRAS->RA-Host)      |
                                     +----------------------+
                                     | Tunnel-Mode IPsec    |
                                     | Hdr(s)(SRAS->RA-Host)|
                                     +----------------------+
                                     | End-to-end IP packet |
                                     | transformed as needed|
                                     | (Ent-Host->RA-Host)  |
                                     +----------------------+
                                        ---------------------->






Srisuresh                    Informational                     [Page 13]

RFC 2888             Secure Remote Access with L2TP          August 2000


6. Limitations to Secure Remote Access using L2TP

   The SRAS model described is not without its limitations. Below is a
   list of the limitations.

   1. Tunneling overhead: There is considerable tunneling overhead on
      the end-to-end IP packet. Arguably, there is overlap of
      information between tunneling headers. This overhead will undercut
      packet throughput.

      The overhead is particularly apparent at the LAC and SRAS nodes.
      Specifically, the SRAS has the additional computational overhead
      of IPsec processing on all IP packets exchanged with remote users.
      This can be a significant bottleneck in the ability of SRAS to
      scale for large numbers of remote users.

   2. Fragmentation and reassembly: Large IP packets may be required to
      undergo Fragmentation and reassembly at the LAC or the LNS as a
      result of multiple tunnel overhead tagged to the packet.
      Fragmentation and reassembly can havoc on packet throughput and
      latency. However, it is possible to avoid the overhead by reducing
      the MTU permitted within PPP frames.

   3. Multiple identity and authentication requirement: Remote Access
      users are required to authenticate themselves to the SRAS in order
      to be obtain access to the link. Further, when they require the
      use of IKE to automate IPsec key exchange, they will need to
      authenticate once again with the same or different ID and a
      distinct authentication approach. The authentication requirements
      of IKE phase 1 [Ref 8] and LCP [Ref 3] are different.

      However, it is possible to have a single authentication approach
      (i.e., a single ID and authentication mechanism) that can be
      shared between LCP and IKE phase 1.  The Extended Authentication
      Protocol(EAP) [Ref 4] may be used as the base to transport IKE
      authentication mechanism into PPP. Note, the configuration
      overhead is not a drag on the functionality perse.

   4. Weak security of Link level authentication: As LCP packets
      traverse the Internet, the Identity of the remote user and the
      password (if a password is used) is sent in the clear. This makes
      it a target for someone on the net to steal the information and
      masquerade as remote user. Note, however, this type of password
      stealing will not jeopardize the security of the enterprise per
      se, but could result in denial of service to remote users. An
      intruder can collect the password data and simply steal the link,
      but will not be able to run any IP applications subsequently, as
      the SRAS will fail non-IPsec packet data.



Srisuresh                    Informational                     [Page 14]

RFC 2888             Secure Remote Access with L2TP          August 2000


      A better approach would be to employ Extended Authentication
      Protocol (EAP) [Ref 4] and select an authentication technique that
      is not prone to stealing over the Internet. Alternately, the LAC
      and the SRAS may be independently configured to use IPsec to
      secure all LCP traffic exchanged between themselves.

7. Configuring RADIUS to support Secure Remote Access.

   A centralized RADIUS database is used by enterprises to maintain the
   authentication and authorization requirements of the dial-in Users.
   It is also believed that direct dial-in access (e.g., through the
   PSTN network is) safe and trusted and does not need any scrutiny
   outside of the link level authentication enforced in LCP. This belief
   is certainly not shared with the dial-in access through the Internet.

   So, while the same RADIUS database may be used for a user directly
   dialing-in or dialing in through the Internet, the security
   requirements may vary. The following RADIUS attributes may be used to
   mandate IPsec for the users dialing-in through the Internet.  The
   exact values for the attributes and its values may be obtained from
   IANA (refer Section 10).

7.1. Security mandate based on access method

   A new RADIUS attribute IPSEC_MANDATE (91) may be defined for each
   user. This attribute may be given one of the following values.

      NONE            (=0)     No IPsec mandated on the IP packets
                               embedded within PPP.

      LNS_AS_SRAS     (=1)     Mandates Tunnel mode IPsec on the IP
                               packets embedded within PPP, only so
                               long as the PPP session terminates
                               at an LNS. LNS would be the tunnel
                               mode IPsec end point.

      SRAS            (=2)     Mandates Tunnel mode IPsec on the IP
                               packets embedded within PPP,
                               irrespective of the NAS type the PPP
                               terminates in. I.e., the IPsec mandate
                               is not specific to LNS alone, and is
                               applicable to any NAS, terminating
                               PPP. NAS would be the tunnel mode
                               IPsec end point.







Srisuresh                    Informational                     [Page 15]

RFC 2888             Secure Remote Access with L2TP          August 2000


   When IPSEC_MANDATE attribute is set to one of LNS_AS_SRAS or SRAS,
   that would direct the NAS to drop any IP packets in PPP that are not
   associated with an AH or ESP protocol. As an exception, the NAS will
   continue to process IKE packets (UDP packets, with source and
   destination port set to 500) directed from remote users. Further, the
   security profile parameter, defined in the following section may add
   additional criteria for which security is not mandatory.

7.2. Security profile for the user

   A new SECURITY_PROFILE (92) parameter may be defined in RADIUS to
   describe security access requirements for the users. The profile
   could contain information such as the access control security
   filters, security preferences and the nature of Keys (manual or
   automatic generated via the IKE protocol) used for security purposes.

   The SECURITY-PROFILE attribute can be assigned a filename, as a
   string of characters. The contents of the file could be vendor
   specific. But, the contents should include (a) a prioritized list
   access control security policies, (b) Security Association security
   preferences associated with each security policy.

7.3. IKE negotiation profile for the user

   If the security profile of a user requires dynamic generation of
   security keys, the parameters necessary for IKE negotiation may be
   configured separately using a new IKE_NEGOTIATION_PROFILE (93)
   parameter in RADIUS. IKE-NEGOTIATION_PROFILE attribute may be
   assigned a filename, as a string of characters. The contents of the
   file could however be vendor specific. The contents would typically
   include (a) the IKE ID of the user and  SRAS, (b) preferred
   authentication approach and the associated parameters, such as a
   pre-shared-key or a pointer to X.509 digital Certificate, and, (c)
   ISAKMP security negotiation preferences for phase I.

8. Acknowledgements

   The author would like to express sincere thanks to Steve Willens for
   initially suggesting this idea. The author is also thankful to Steve
   for the many informal conversations which were instrumental in the
   author being able to appreciate the diverse needs of the Remote
   Access area.









Srisuresh                    Informational                     [Page 16]

RFC 2888             Secure Remote Access with L2TP          August 2000


9. Security Considerations

   This document is about providing secure remote access to enterprises
   via the Internet. However, the document does not address security
   issues for network layers other than IP. While the document focus is
   on security over the Internet, the security model provided is not
   limited to the Internet or the IP infrastructure alone. It may also
   be applied over other transport media such as Frame Relay and ATM
   clouds. If the transport media is a trusted private network
   infrastructure, the security measures described may not be as much of
   an issue. The solution suggested in the document is keeping in view
   the trust model between a remote user and enterprise.

10. IANA Considerations

   This document proposes a total of three new RADIUS attributes to be
   maintained by the IANA. These attributes IPSEC_MANDATE,
   SECURITY_PROFILE and IKE_NEGOTIATION_PROFILE may be assigned the
   values 91, 92 and 93 respectively so as not to conflict with the
   definitions for recognized radius types, as defined in
   http://www.isi.edu/in-notes/iana/assignments/radius-types.

   The following sub-section explains the criteria to be used by the
   IANA to assign additional numbers as values to the IPSEC-MANDATE
   attribute described in section 7.1.

10.1.  IPSEC-MANDATE attribute Value

   Values 0-2 of the IPSEC-MANDATE-Type Attribute are defined in Section
   7.1; the remaining values [3-255] are available for assignment by the
   IANA with IETF Consensus [Ref 11].

REFERENCES

   [1]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
        B. Palter, "Layer Two Tunneling Protocol L2TP", RFC 2661, August
        1999.

   [2]  Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
        Authentication Dial In User Service (RADIUS)", RFC 2138, April
        1997.

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

   [4]  Blunk, L. and Vollbrecht, J. "PPP Extensible Authentication
        Protocol (EAP)", RFC 2284, March 1998.




Srisuresh                    Informational                     [Page 17]

RFC 2888             Secure Remote Access with L2TP          August 2000


   [5]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [6]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
        (ESP)", RFC 2406, November 1998.

   [7]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
        November 1998.

   [8]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
        RFC 2409, November 1998.

   [9]  Piper, D., "The Internet IP Security Domain of Interpretation
        for ISAKMP", RFC 2407, November 1998.

   [10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        October 1994.
        See also http://www.iana.org/numbers.html

   [11] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [12] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC
        1968, June 1996.

   [13] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
        Version 2 (DESE-bis)", RFC 2419, September 1998.

Author's Address

   Pyda Srisuresh
   Campio Communications
   630 Alder Drive
   Milpitas, CA 95035
   U.S.A.

   Phone: [phone]
   EMail: [e-mail]













Srisuresh                    Informational                     [Page 18]

RFC 2888             Secure Remote Access with L2TP          August 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Srisuresh                    Informational                     [Page 19]