rfc3193.txt

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

   One Microsoft Way
   Redmond, WA 98052

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


   Glen Zorn
   Cisco Systems, Inc.
   500 108th Avenue N.E., Suite 500
   Bellevue, Washington 98004

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


   Skip Booth
   Cisco Systems
   7025 Kit Creek Road
   RTP, NC 27709

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





Patel, et al.               Standards Track                    [Page 23]

RFC 3193               Securing L2TP using IPsec           November 2001


Appendix A: Example IPsec Filter sets for L2TP Tunnel Establishment

   This section provides examples of IPsec filter sets for L2TP tunnel
   establishment.  While example filter sets are for IPv4, similar
   examples could just as easily be constructed for IPv6.

A.1 Initiator and Responder use fixed addresses and ports

   This is the most simple of the cases since nothing changes during
   L2TP tunnel establishment.  Since the initiator does not know whether
   the responder will change its port number, it still must be prepared
   for this case.  In this example, the initiator will use an IPv4
   address of 1.1.1.1 and the responder will use an IPv4 address of
   2.2.2.1.

   The filters for this scenario are:

A.1.1 Protect the SCCRQ

   Initiator Filters:
      Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701,     dst 1701

      Inbound-1:  From 2.2.2.1, to 1.1.1.1, UDP, src 1701,     dst 1701
      Inbound-2:  From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701

   Responder Filters:
      Outbound-1: None, dynamically injected when IKE Phase 2 completes

      Inbound-1:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701

   After IKE Phase 2 completes the filters at the initiator and
   responder will be:

   Initiator Filters:
      Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701,     dst 1701

      Inbound-1:  From 2.2.2.1, to 1.1.1.1, UDP, src 1701,     dst 1701
      Inbound-2:  From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701

   Responder Filters:
      Outbound-1: From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 1701

      Inbound-1:  From 1.1.1.1,  to 2.2.2.1, UDP, src 1701,     dst 1701
      Inbound-2:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701







Patel, et al.               Standards Track                    [Page 24]

RFC 3193               Securing L2TP using IPsec           November 2001


A.2 Gateway to Gateway Scenario where Initiator and Responder use
    dynamic ports

   In this scenario either side is allowed to initiate the tunnel.
   Since dynamic ports will be used, an extra phase 2 negotiation must
   occur to protect the SCCRP sent from the responder to the initiator.
   Other than the additional phase 2 setup, the only other difference is
   that L2TP on the responder must inject an additional filter into the
   IPsec database once the new port number is chosen.

   This example also shows the additional filter needed by the initiator
   which allows either side to start the tunnel.  In either the dial-out
   or the gateway to gateway scenario this additional filter is
   required.

   For this example, assume the dynamic port given to the initiator is
   5000 and his IP address is 1.1.1.1.  The responder will use an IP
   address of 2.2.2.1 and a port number of 6000.

   The filters for this scenario are:

A.2.1 Initial Filters to allow either side to respond to negotiations

   In this case both peers must be able to accept phase 2 negotiations
   to from L2TP peers.  My-IPAddr is defined as whatever IP address the
   device is willing to accept L2TP negotiations on.

   Responder Filters present at both peers:
     Inbound-1: From Any-Addr, to My-IPAddr, UDP, src Any-Port, dst 1701

   Note: The source IP in the inbound-1 filter above for gateway to
   gateway tunnels can be IP specific, such as 1.1.1.1, not necessarily
   Any-Addr.

A.2.2 Protect the SCCRQ, one peer is now the initiator

   Initiator Filters:
      Outbound-1: From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 1701

      Inbound-1:  From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 5000
      Inbound-2:  From 2.2.2.1,  to 1.1.1.1, UDP, src Any-Port, dst 5000
      Inbound-3:  From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701

   Responder Filters:
      Outbound-1: None, dynamically injected when IKE Phase 2 completes

      Inbound-1:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701




Patel, et al.               Standards Track                    [Page 25]

RFC 3193               Securing L2TP using IPsec           November 2001


   After IKE Phase 2 completes the filters at the initiator and
   responder will be:

   Initiator Filters:
      Outbound-1: From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 1701

      Inbound-1:  From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 5000
      Inbound-2:  From 2.2.2.1,  to 1.1.1.1, UDP, src Any-Port, dst 5000

      Inbound-3:  From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701

   Responder Filters:
      Outbound-1: From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 5000

      Inbound-1:  From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 1701
      Inbound-2:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701

A.2.3 Protect the SCCRP after port change

   At this point the responder knows which port number it is going to
   use.  New filters should be injected by L2TP to reflect this new port
   assignment.

   The new filter set at the responder is:

   Responder Filters:
      Outbound-1: From 2.2.2.1,  to 1.1.1.1, UDP, src 6000,     dst 5000
      Outbound-2: From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 5000

      Inbound-1:  From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 6000
      Inbound-2:  From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 1701
      Inbound-3:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701

   The second phase 2 will start once L2TP sends the SCCRP.  Once the
   phase 2 negotiations complete, the new filter set at the initiator
   and the responder will be:

   Initiator Filters:
      Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000,     dst 6000
      Outbound-2: From 1.1.1.1, to 2.2.2.1, UDP, src 5000,     dst 1701

      Inbound-1:  From 2.2.2.1, to 1.1.1.1, UDP, src 6000,     dst 5000
      Inbound-2:  From 2.2.2.1, to 1.1.1.1, UDP, src 1701,     dst 5000
      Inbound-3:  From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701







Patel, et al.               Standards Track                    [Page 26]

RFC 3193               Securing L2TP using IPsec           November 2001


   Responder Filters:
      Outbound-1: From 2.2.2.1,  to 1.1.1.1, UDP, src 6000,     dst 5000
      Outbound-2: From 2.2.2.1,  to 1.1.1.1, UDP, src 1701,     dst 5000

      Inbound-1:  From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 6000
      Inbound-2:  From 1.1.1.1,  to 2.2.2.1, UDP, src 5000,     dst 1701
      Inbound-3:  From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701

   Once the L2TP tunnel has been successfully established, the original
   phase 2 may be deleted.  This allows the Inbound-2 and Outbound-2
   filter statements to be removed as well.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


















Patel, et al.               Standards Track                    [Page 27]

RFC 3193               Securing L2TP using IPsec           November 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.



















Patel, et al.               Standards Track                    [Page 28]