TCP/IP Tutorial and Technical Overview phần 10

22.14.1 Terminology Before describing the protocol, we provide a definition of some L2TP terminology Ê L2TP access concentrator (LAC) A device attached to one or more public switched telephone network (PSTN) or Integrated Services Digital Network (ISDN) lines capable of handling both the PPP operation and L2TP protocol. The LAC implements the media over which L2TP operates. L2TP passes the traffic to one or more L2TP servers (LNS). Ê L2TP network server (LNS) An LNS operates on any platform that can be a PPP endstation. The LNS handles the server side of the L2TP protocol. Because L2TP relies only on the single media over which L2TP tunnels arrive, the LNS can have only a single LAN or WAN interface, yet is still able to terminate calls arriving from any PPP interfaces supported by a LAC, such as async, synchronous, ISDN, V.120, and so on. Ê Network access servers (NAS) A device providing temporary, on demand network access to users. This access is point-to-point using PSTN or ISDN lines. Ê Session (Call) L2TP creates a session when an end-to-end PPP connection is attempted between a dial-in user and the LNS, or when an outbound call is initiated. The datagrams for the session are sent over the tunnel between the LAC and the LNS. The LNS and LAC maintain the state information for each user attached to a LAC. Ê Tunnel A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP datagrams between the LAC and the LNS. A single tunnel can multiplex many sessions. A control connection operating over the same tunnel controls the establishment, release, and maintenance of all sessions and of the tunnel itself. Ê Attribute value air (AVP) A uniform method of encoding message types and bodies. This method maximizes the extensibility while permitting interpretability of L2TP. 876 TCP/IP Tutorial and Technical Overview 22.14.2 Protocol overview Because the host and the gateway share the same PPP connection, they can take advantage of PPP`s ability to transport protocols other than just IP. For example, L2TP tunnels can support remote LAN access as well as remote IP access. Figure 22-53 outlines a basic L2TP configuration. LNS Internet ISP LAC Dial Connection L2TP Tunnel PPP Connection Figure 22-53 Layer 2 Tunnel Protocol (L2TP) scenario Referring to Figure 22-53, the following actions occur: 1. The remote user initiates a PPP connection. 2. The NAS accepts the call. 3. The NAS identifies the remote user using an authorization server. 4. If the authorization is OK, the NAS/LAC initiates an L2TP tunnel to the desired LNS at the entry to the enterprise. 5. The LNS authenticates the remote user through its authentication server and accepts the tunnel. 6. The LNS confirms acceptance of the call and the L2TP tunnel. 7. The NAS logs the acceptance. 8. The LNS exchanges PPP negotiation with the remote user. 9. End-to-end data is now tunneled between the remote user and the LNS. L2TP is actually another variation of an IP encapsulation protocol. As shown in Figure 22-54 on page 878, an L2TP tunnel is created by encapsulating an L2TP frame inside a UDP packet, which in turn is encapsulated inside an IP packet whose source and destination addresses define the tunnel`s endpoints. Because the outer encapsulating protocol is IP, clearly IPSec protocols can be applied to this composite IP packet, thus protecting the data that flows within the L2TP tunnel. AH, ESP, and ISAKMP/Oakley protocols can all be applied in a straightforward way. Chapter 22. TCP/IP security 877 LAC Dial L2TP Connection Code LNS L2TP Router Code Code PPP Data PPP Data IP UDP L2TP PPP Data PPP Connection Figure 22-54 L2TP packet changes during transit L2TP can operate over UDP/IP and support the following functions: Ê Tunneling of single user dial-in clients Ê Tunneling of small routers, for example, a router with a single static route to set up based on an authenticated user`s profile Ê Incoming calls to an LNS from a LAC Ê Multiple calls per tunnel Ê Proxy authentication for PAP and CHAP Ê Proxy LCP Ê LCP restart in the event that proxy LCP is not used at the LAC Ê Tunnel endpoint authentication Ê Hidden AVP for transmitting a proxy PAP password Ê Tunneling using a local realm (that is, user@realm) lookup table Ê Tunneling using the PPP user name lookup in the AAA subsystem (22.12, “Remote access authentication protocols” on page 872) 878 TCP/IP Tutorial and Technical Overview IP UDP L2TP PPP Data Data L2TP IP Code Code L2 Net IP L2TP IP Cloud Code Code L2 Net Data Figure 22-55 L2TP packet flow through any IP cloud 22.14.3 L2TP security issues Although L2TP provides cost-effective access, multiprotocol transport, and remote LAN access, it does not provide cryptographically robust security features. For example: Ê Authentication is provided only for the identity of tunnel endpoints, but not for each individual packet that flows inside the tunnel. This can expose the tunnel to man-in-the-middle and spoofing attacks. Ê Without per-packet integrity, it is possible to mount denial-of-service attacks by generating bogus control messages that can terminate either the L2TP tunnel or the underlying PPP connection. Ê L2TP itself provides no facility to encrypt user data traffic. This can lead to embarrassing exposures when data confidentiality is an issue. Ê While the payload of the PPP packets can be encrypted, the PPP protocol suite does not provide mechanisms for automatic key generation or for automatic key refresh. This can lead to someone listening in on the wire to finally break that key and gain access to the data being transmitted. Realizing these shortcomings, the PPP Extensions Working Group of the IETF considered how to remedy these shortfalls. Rather than duplicate work done elsewhere, it was decided to recommend using IPSec within L2TP. This is described in RFC 2888. In summary, Layer 2 Tunnel Protocols are an excellent way of providing cost-effective remote access. And when used in conjunction with IPSec, they are an excellent technique for providing secure remote access. However, without Chapter 22. TCP/IP security 879 complementary use of IPSec, an L2TP tunnel alone does not furnish adequate security. 22.15 Secure Electronic Transaction (SET) SET is the outcome of an agreement by MasterCard International and Visa International to cooperate on the creation of a single electronic credit card system. Prior to SET, each organization had proposed its own protocol and each had received support from a number of networking and computing companies. Now, most of the major players are behind the SET specification (for example, IBM, Microsoft, Netscape, and GTE). The following sections describes at a high level the components and processes that make up the specification. Refer to the MasterCard and Visa home pages for more information about SET. 22.15.1 SET roles The SET specification defines several roles involved in the payment process: The merchant The acquirer The issuer The cardholder This is any seller of goods, services, or information. This is the organization that provides the credit card service and keeps the money flowing. The most widely known acquirers are MasterCard and Visa. This is the organization that issued the card to the purchaser in the first place. Usually, this is a bank or some other financial institution, which would know the purchaser best. This is the Web surfer, who has been given a credit card by the issuer and now wants to exercise his or her purchasing power on the Web. The acquirer payment gateway This provides an interface between the merchant and the bankcard network used by the acquirer and the issuer. It is important to remember that the bankcard network already exists. The acquirer payment gateway provides a well-defined, secure interface to that established network from the Internet. Acquirer payment gateways will be operated on behalf of the acquirers, but they might be provided by third-party organizations, such as Internet service providers (ISPs). 880 TCP/IP Tutorial and Technical Overview ... - tailieumienphi.vn