rfc3193.txt

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

   has performed a teardown of any L2TP tunnel state associated with the
   peer.  The L2TP tunnel state and any associated filters can now be
   safely removed.

3.2.  Fragmentation Issues

   Since the default MRU for PPP connections is 1500 bytes,
   fragmentation can become a concern when prepending L2TP and IPsec
   headers to a PPP frame.  One mechanism which can be used to reduce
   this problem is to provide PPP with the MTU value of the
   ingress/egress interface of the L2TP/IPsec tunnel minus the overhead
   of the extra headers.  This should occur after the L2TP tunnel has
   been setup and but before LCP negotiations begin.  If the MTU value
   of the ingress/egress interface for the tunnel is less than PPP's
   default MTU, it may replace the value being used.  This value may
   also be used as the initial value proposed for the MRU in the LCP
   config req.





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


   If an ICMP PMTU is received by IPsec, this value should be stored in
   the SA as proposed in [6].  IPsec should also provide notification of
   this event to L2TP so that the new MTU value can be reflected into
   the PPP interface.  Any new PTMU discoveries seen at the PPP
   interface should be checked against this new value and processed
   accordingly.

3.3.  Per-packet security checks

   When a packet arrives from a tunnel which requires security, L2TP
   MUST:

   [1] Check to ensure that the packet was decrypted and/or
       authenticated by IPsec.  Since IPsec already verifies that the
       packet arrived in the correct SA, L2TP can be assured that the
       packet was indeed sent by a trusted peer and that it did not
       arrive in the clear.

   [2] Verify that the IP addresses and UDP port values in the packet
       match the socket information which was used to setup the L2TP
       tunnel.  This step prevents malicious peers from spoofing packets
       into other tunnels.

4.  IPsec Filtering details when protecting L2TP

   Since IKE/IPsec is agnostic about the nuances of the application it
   is protecting, typically no integration is necessary between the
   application and the IPsec protocol.  However, protocols which allow
   the port number to float during the protocol negotiations (such as
   L2TP), can cause problems within the current IKE framework.  The L2TP
   specification [1] states that implementations MAY use a dynamically
   assigned UDP source port.  This port change is reflected in the SCCRP
   sent from the responder to the initiator.

   Although the current L2TP specification allows the responder to use a
   new IP address when sending the SCCRP, implementations requiring
   protection of L2TP via IPsec SHOULD NOT do this.  To allow for this
   behavior when using L2TP and IPsec, when the responder chooses a new
   IP address it MUST send a StopCCN to the initiator, with the Result
   and Error Code AVP present.  The Result Code MUST be set to 2
   (General Error) and the Error Code SHOULD be set to 7 (Try Another).
   If the Error Code is set to 7, then the optional error message MUST
   be present and the contents MUST contain the IP address (ASCII
   encoded) that the Responder desires to use for subsequent
   communications.  Only the ASCII encoded IP address should be present
   in the error message.  The IP address is encoded in dotted decimal
   format for IPv4 or in RFC 2373 [17] format for IPv6.  The initiator
   MUST parse the result and error code information and send a new SCCRQ



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


   to the new IP address contained in the error message.  This approach
   reduces complexity since now the initiator always knows precisely the
   IP address of its peer.  This also allows a controlled mechanism for
   L2TP to tie IPsec filters and policy to the same peer.

   The filtering details required to accommodate this behavior as well
   as other mechanisms needed to protect L2TP with IPsec are discussed
   in the following sections.

4.1.  IKE Phase 1 Negotiations

   Per IKE [7], when using pre-shared key authentication, a key must be
   present for each peer to which secure communication is required.
   When using Main Mode (which provides identity protection), this key
   must correspond to the IP address for the peer.  When using
   Aggressive Mode (which does not provide identity protection), the
   pre-shared key must map to one of the valid id types defined in the
   IPsec DOI [5].

   If the initiator receives a StopCCN with the result and error code
   AVP set to "try another" and a valid IP address is present in the
   message, it MAY bind the original pre-shared key used by IKE to the
   new IP address contained in the error-message.

   One may may wish to consider the implications for scalability of
   using pre-shared keys as the authentication method for phase 1.  As
   the number of LAC and LNS endpoints grow, pre-shared keys become
   increasingly difficult to manage.  Whenever possible, authentication
   with certificates is preferred.

4.2.  IKE Phase 2 Negotiations

   During the IKE phase 2 negotiations, the peers agree on what traffic
   is to be protected by the IPsec protocols.  The quick mode IDs
   represent the traffic which the peers agree to protect and are
   comprised of address space, protocol, and port information.

   When securing L2TP with IPsec, the following cases must be
   considered:












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


   Cases:

   +--------------------------------------------------+
   | Initiator Port | Responder Addr | Responder Port |
   +--------------------------------------------------+
   |      1701      |     Fixed      |     1701       |
   +--------------------------------------------------+
   |      1701      |     Fixed      |    Dynamic     |
   +--------------------------------------------------+
   |      1701      |    Dynamic     |     1701       |
   +--------------------------------------------------+
   |      1701      |    Dynamic     |    Dynamic     |
   +--------------------------------------------------+
   |     Dynamic    |     Fixed      |     1701       |
   +--------------------------------------------------+
   |     Dynamic    |     Fixed      |    Dynamic     |
   +--------------------------------------------------+
   |     Dynamic    |    Dynamic     |     1701       |
   +--------------------------------------------------+
   |     Dynamic    |    Dynamic     |    Dynamic     |
   +--------------------------------------------------+

   By solving the most general case of the above permutations, all cases
   are covered.  The most general case is the last one in the list.
   This scenario is when the initiator chooses a new port number and the
   responder chooses a new address and port number.  The L2TP message
   flow which occurs to setup this sequence is as follows:

   -> IKE Phase 1 and Phase 2 to protect Initial SCCRQ

           SCCRQ ->         (Fixed IP address, Dynamic Initiator Port)
                 <- STOPCCN (Responder chooses new IP address)

   -> New IKE Phase 1 and Phase 2 to protect new SCCRQ

           SCCRQ ->         (SCCRQ to Responder's new IP address)

   <- New IKE Phase 2 to for port number change by the responder

                 <- SCCRP   (Responder chooses new port number)
           SCCCN ->         (L2TP Tunnel Establishment completes)

   Although the Initiator and Responder typically do not dynamically
   change ports, L2TP security must accommodate emerging applications
   such as load balancing and QoS.  This may require that the port and
   IP address float during L2TP tunnel establishment.





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


   To support the general case, mechanisms must be designed into L2TP
   and IPsec which allow L2TP to inject filters into the IPsec filter
   database.  This technique may be used by any application which floats
   ports and requires security via IPsec, and is described in the
   following sections.

   The responder is not required to support the ability to float its IP
   address and port.  However, the initiator MUST allow the responder to
   float its port and SHOULD allow the responder to choose a new IP
   address (see section 4.2.3, below).

   Appendix A provides examples of these cases using the process
   described below.

4.2.1.  Terminology definitions used for filtering statements

   I-Port      The UDP port number the Initiator chooses to
               originate/receive L2TP traffic on.  This can be a static
               port such as 1701 or an ephemeral one assigned by the
               socket.

   R-Port      The UDP port number the Responder chooses to
               originate/receive L2TP traffic on.  This can be the port
               number 1701 or an ephemeral one assigned by the socket.
               This is the port number the Responder uses after
               receiving the initial SCCRQ.

   R-IPAddr1   The IP address the Responder listens on for initial
               SCCRQ.  If the responder does not choose a new IP
               address, this address will be used for all subsequent
               L2TP traffic.

   R-IPAddr2   The IP address the Responder chooses upon receiving the
               SCCRQ.  This address is used to send the SCCRP and all
               subsequent L2TP tunnel traffic is sent and received on
               this address.

   R-IPAddr    The IP address which the responder uses for sending and
               receiving L2TP packets.  This is either the initial value
               of R-IPAddr1 or a new value of R-IPAddr2.

   I-IPAddr    The IP address the Initiator uses to communicate with for
               the L2TP tunnel.

   Any-Addr    The presence of Any-Address defines that IKE should
               accept any single address proposed in the local address
               of the quick mode IDs sent by the peer during IKE phase 2
               negotiations.  This single address may be formatted as an



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


               IP Single address, an IP Netmask address with the Netmask
               set to 255.255.255.255, and IP address Range with the
               range being 1, or a hostname which can be resolved to one
               address.  Refer to [5] for more information on the format
               for quick mode IDs.

   Any-Port    The presence of Any-Port defines that IKE should accept a
               value of 0 or a specific port value for the port value in
               the port value in the quick mode IDs negotiated during
               IKE phase 2.

   The filters defined in the following sections are listed from highest
   priority to lowest priority.

4.2.2.  Initial filters needed to protect the SCCRQ

   The initial filter set on the initiator and responder is necessary to
   protect the SCCRQ sent by the initiator to open the L2TP tunnel.
   Both the initiator and the responder must either be pre-configured
   for these filters or L2TP must have a method to inject this
   information into the IPsec filtering database.  In either case, this
   filter MUST be present before the L2TP tunnel setup messages start to
   flow.

      Responder Filters:
         Outbound-1: None.  They should be be dynamically created by IKE
         upon successful completion of phase 2.

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

      Initiator Filters:
         Outbound-1: From I-IPAddr,  to R-IPAddr1, UDP, src I-Port,
         dst 1701

         Inbound-1:  From R-IPAddr1, to I-IPAddr,  UDP, src 1701,
         dst I-Port
         Inbound-2:  From R-IPAddr1, to I-IPAddr,  UDP, src Any-Port,
         dst I-Port

   When the initiator uses dynamic ports, L2TP must inject the filters
   into the IPsec filter database, once its source port number is known.
   If the initiator uses a fixed port of 1701, these filters MAY be
   statically defined.

   The Any-Port definition in the initiator's inbound-2 filter statement
   is needed to handle the potential port change which may occur as the
   result of the responder changing its port number.



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


   If a phase 2 SA bundle is not already present to protect the SCCRQ,
   the sending of a SCCRQ by the initiator SHOULD cause IKE to setup the
   necessary SAs to protect this packet.  Alternatively, L2TP may also
   request IKE to setup the SA bundle.  If the SA cannot be setup for
   some reason, the packet MUST be dropped.

   The port numbers in the Quick Mode IDs sent by the initiator MUST
   contain the specific port numbers used to identify the UDP socket.