rfc2888.txt

中、英文RFC文档大全打包下载完全版 .

                    |   DMZ - Network
   ------------------------------------------------------------
            |            |                     |
           +--+         +--+              +----------+
           |__|         |__|              | Firewall |
               /____\       /____\             +----------+
               DMZ-Name     DMZ-Web   ...         |
               Server       Server etc.           | LAN
                                             |
                  ------------------------------------
                      |                          |
                 +----------+         +------------------+
                 |   LNS    |         | Security Gateway |
                 |  Server  |         |      (SGW)       |
                 +----------+         +------------------+
                                               |
                                     ------------------
                                    (                  )
                                   (  Internal Network  )
                                  (   (Private to the    )
                                   (   enterprise)      )
                                    (_________________ )

     Figure 2: Security Model based on Firewall and Security Gateway

   In order to allow employee dial-in over the Internet, an LNS may be
   placed behind a firewall, and the firewall may be configured to allow
   UDP access to the LNS from the Internet. Note, it may not be possible
   to know all the IP addresses of the LACs located on the Internet at
   configuration time. Hence, the need to allow UDP access from any node
   on the Internet. The LNS may be configured to process only the L2TP
   packets and drop any UDP packets that are not L2TP.





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


   Such a configuration allows remote access over the Internet. However,
   the above setup is prone to a variety of security attacks over the
   Internet. It is easy for someone on the Internet to steal a remote
   access session and gain  access to precious resources of the
   enterprise. Hence it is important that all packets are preserved with
   IPsec to a security Gateway (SGW) behind the LNS, so the Security
   Gateway will not allow IP packets into corporate network unless it
   can authenticate the same.

   The trust model of secure remote access assumes that the enterprise
   and the end user are trusted domains. Everything in between is not
   trusted. Any examination of the end-to-end packets by the nodes
   enroute would violate this trust model. From this perspective, even
   the LAC node enroute must not be trusted with the end-to-end IP
   packets. Hence, location and operation of LAC is not relevant for the
   discussion on security. On the other hand, location and operation of
   LNS and the Security Gateway (SGW) are precisely the basis for
   discussion.

   Having security processing done on an independent Security gateway
   has the following shortcomings.

   1. Given the trust model for remote access, the SGW must be
      configured with a set of security profiles, access control lists
      and IKE authentication parameters for each user. This mandates an
      independent provisioning of security parameters on a per-user
      basis. This may not be able to take advantage of the user-centric
      provisioning on RADIUS, used by the LNS node.

   2. Unlike the LNS, SGW may not be in the routing path of remote
      access packets. I.e., there is no guarantee that the egress IP
      packets will go through the chain of SGW and LNS before they are
      delivered to remote user. As a result, packets may be subject to
      IPSec in one direction, but not in the other. This can be a
      significant threat to the remote access trust model.

   3. Lastly, the SGW node does not have a way to know when a remote
      user node(s) simply died or the LAC-LNS tunnel failed. Being
      unable to delete the SAs for users that no longer exist could
      drain the resources of the SGW. Further, the LNS cannot even
      communicate the user going away to the SGW because, the SGW
      maintains its peer nodes based on IKE user ID, which could be
      different the user IDs employed by the LNS node.








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


5. Secure Remote Access

   Combining the functions of IPsec Security Gateway and LNS into a
   single system promises to offer a viable solution for secure remote
   access. By doing this, remote access clients will use a single node
   as both (a) PPP termination point providing NAS service, and (b) the
   Security gateway node into the enterprise. We will refer this node as
   "Secure Remote Access Server" (SRAS).

   The SRAS can benefit greatly from the confluence of PPP session and
   IPsec tunnel end points. PPP session monitoring capability of L2TP
   directly translates to being able to monitor IPsec tunnels. Radius
   based user authorization ability could be used to configure the
   security characteristics for IPsec tunnel. This includes setting
   access control filters and security preferences specific to each
   user. This may also be extended to configuring IKE authentication and
   other negotiation parameters, when automated key exchange is
   solicited. Security attributes that may be defined in Radius are
   discussed in detail in section 7. Needless to say, the centralized
   provisioning capability and scalability of Radius helps in the
   configuration of IPsec.

   As for remote access, the benefit is one of IPsec security as
   befitting the trust model solicited by enterprises for the end-to-end
   IP packets traversing the Internet. You may use simply AH where there
   is no fear of external eaves-dropping, but you simply need to
   authenticate packet data, including the source of packet. You may use
   ESP (including ESP-authentication), where there is no trust of the
   network and you do not want to permit eaves-dropping on corporate
   activities.

   Operation of SRAS requires that the firewall be configured to permit
   UDP traffic into the SRAS node. The SRAS node in turn will process
   just the L2TP packets and drop the rest. Further, the SRAS will
   require all IP packets embedded within PPP to be one of AH and ESP
   packets, directed to itself. In addition, the SRAS will also permit
   IKE UDP packets (with source and destination ports sets to 500)
   directed to itself in order to perform IKE negotiation and generate
   IPsec keys dynamically. All other IP packets embedded within PPP will
   be dropped. This enforces the security policy for the enterprise by
   permitting only the secure remote access packets into the enterprise.
   When a PPP session is dropped, the IPsec and ISAKMP SAs associated
   with the remote access user are dropped from the SRAS. All the
   shortcomings listed in the previous section with LNS and SGW on two
   systems disappear withe Secure Remote Access Server. Figure 3 below
   is a typical description of an enterprise supporting remote access
   users using SRAS system.




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


                                                   ------------
              Remote Access  +-------------+      (            )
        +--+______   Link    | Local Access|     (              )
        |__|     /___________| Concentrator|----(    Internet    )
       /____\                |    (LAC)    |     (              )
       RA-Host               +-------------+      (____________)

                                  WAN  |
                            .........|\|....
                                     |
                           +-----------------+
                           |Enterprise Router|
                           +-----------------+
                               |
                               |   DMZ - Network
             ------------------------------------------
            |            |                     |
           +--+         +--+              +----------+
           |__|         |__|              | Firewall |
               /____\       /____\             +----------+
               DMZ-Name     DMZ-Web   ...         |
               Server       Server etc.           | LAN
                                             |
                  ------------------------------------
                                     |
                                +---------------+
                                | Secure Remote |
                                | Access Server |
                                |    (SRAS)     |
                                +---------------+
                                         |
                               ---------------------
                              (                     )
                 +--+       (    Internal Network    )
                 |__|------(     (Private to the      )
                /____\      (     enterprise)        )
                Ent-Host     (______________________)

     Figure 3: Secure Remote Access Server operation in an Enterprise

   The following is an illustration of secure remote access data flow as
   end-to-end IP packets traverse the Internet and the SRAS. The example
   shows IP packet tunneling and IPsec transformation as packets are
   exchanged between a remote Access host (RA-Host) and a host within
   the enterprise (say, Ent-Host).






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


   Note, the IP packets originating from or directed to RA-Host are
   shown within PPP encapsulation, whereas, all other packets are shown
   simply as IP packets.  It is done this way to highlight the PPP
   packets encapsulated within L2TP tunnel. The PPP headers below are
   identified by their logical source and destination in parenthesis.
   Note, however, the source and recipient information of the PPP data
   is not a part of PPP header. This is described thus, just for
   clarity. In the case of an L2TP tunnel, the L2TP header carries the
   PPP session ID, which indirectly identifies the PPP end points to the
   LAC and the LNS. Lastly, the IPsec Headers section below include the
   tunneling overhead and the AH/ESP headers that are attached to the
   tunnel.







































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


   RA-Host to Ent-Host Packet traversal:
   ------------------------------------

   RA-Host              LAC                   SRAS              Ent-Host
   =====================================================================

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

                   +----------------------+
                   | IP Header            |
                   | (LAC->SRAS)          |
                   +----------------------+
                   | UDP Header           |
                   +----------------------+
                   | L2TP Header          |
                   | (incl. PPP Sess-ID)  |
                   +----------------------+
                   | PPP Header           |
                   | (RA-Host ->SRAS)     |
                   +----------------------+
                   | Tunnel-Mode IPsec    |
                   | Hdr(s)(RA-Host->SRAS)|
                   +----------------------+
                   | End-to-end IP packet |
                   | transformed as needed|
                   | (RA-Host->Ent-Host)  |
                   +----------------------+
                      ---------------------->

                                      +----------------------+
                                      | End-to-end IP packet |
                                      | (RA-Host->Ent-Host)  |
                                      +----------------------+
                                         ---------------------->






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


   Ent-Host to RA-Host Packet traversal:
   ------------------------------------

   Ent-Host             SRAS                  LAC               RA-Host
   =====================================================================

   +----------------------+
   | End-to-end IP packet |
   | (Ent-Host->Ra-Host)  |
   +----------------------+
      ---------------------->

                   +----------------------+
                   | IP Header            |
                   | (SRAS->LAC)          |
                   +----------------------+
                   | UDP Header           |
                   +----------------------+
                   | L2TP Header          |
                   | (incl. PPP Sess-ID)  |
                   +----------------------+
                   | 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)  |
                   +----------------------+
                      ---------------------->

                                     +----------------------+