📄 rfc2888.txt
字号:
| 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) |
+----------------------+
---------------------->
+----------------------+
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -