The Internet Protocol Journal, Volume 12, No.3

End-to-End Security

by Michael H. Behringer, Cisco Systems

End-to-end security relies on protocols and mechanisms that are implemented exclusively on the endpoints of a connection. The most typical example is an HTTPS connection (based, for example, on Transport Layer Security (TLS) [1]) to a web server; IP Security (IPsec) [2] can also be used for end-to-end security, as was initially proposed as a default connection mechanism for IPv6.

There is a perception that end-to-end security is sufficient as a security solution, and that network-based security is obsolete in the presence of end-to-end security. This article outlines why in practice end-to-end security alone is not sufficient, and why network-based security is also required.

Defining "End"

The traditional definition of an endpoint is a client or server. In this definition end-to-end security starts on the client and ends on the server. Given the multitude of applications running in parallel on an operating system, and given increasing virtualization, this definition is usually no longer precise enough. The operating system can establish a security association on either the session or application level. It can also be terminated on a front end, on behalf of numerous servers, as is the case in many TLS [1] deployments.

Because the main goal of this article is to understand why the network has a role to play in security, the precise definition of an endpoint is not relevant here. Abstractly seen, an endpoint is an entity that communicates over a network with another entity. This definition, albeit vague, is sufficient for the discussion at hand.M.

End-to-End Security Is Fundamental

Security on the endpoints (client-server, or client-client for peer-to-peer) is an absolute require­ment for secure communications. Such a solution contains the following components:

  • Identity: This component encompases known and verifiable entity identities on both ends; note that an identity can be temporary for a connection. For example, a user often is identified by username and password, whereas a server may be identified through a server certificate.
  • Protocols (for example, TLS [1] and IPsec [2]): Protocols are used to dynamically negotiate session keys, and to provide the required security functions (for example, encryption and integrity verification) for a connection. Protocols use algorithms to implement these functions.
  • Algorithms (for example, Advanced Encryption Standard [AES] [3], Triple Digital Encryption Standard [3DES] [4], and Secure Hash Algorithm [SHA-1] [5]): These algorithms use the previously mentioned session keys to protect data in transit, for example through encryption or integrity checks.
  • Secure implementation: The endpoint (client or server) that runs one of these protocols mentioned previously must be free of bugs that could compromise security. Web browser security is relevant here. Also malware can compromise security, for example by logging key strokes on a PC.
  • Secure operation: Users and operators have to understand the security mechanisms, and how to deal with exceptions. For example, web browsers warn about invalid server certificates, but users can override the warning and still make the connection. This concern is a nontechnical one, but is of critical concern today.

For full end-to-end security, all of these components must be secure. In networks with end-to-end security, both ends can typically (depending on the protocols and algorithms used) rely on the fact that their communication is not visible to anyone else, and that no one else can modify the data in transit. End-to-end security is used successfully today, for example, in online banking applications. Correct and complete end-to-end security is required; without it, many applications such as online banking would not be possible.

However, a single security problem in any of the components can compromise the overall security for a connection. Today, most critical are implementation problems on endpoints, as well as human errors, specifically in handling exception cases.

Practical Shortcomings of End-to-End Security

Solutions that rely exclusively on end-to-end security have many potential problems, which fall into two broad categories: those that affect the end user and those that affect the network operator (the service provider, or the enterprise network operator, for example).

The End-User View

As reports on online crime and fraud demonstrate very clearly, even in the perceived presence of end-to-end security it is difficult to ensure that none of the components mentioned previously is "broken." Although protocols and algorithms in use tend to be secure and reliable, the main problems lie in the two main areas of endpoint security (secure implementation component) and lack of user education (secure operation component).

Endpoint security concerns include the presence of malware, as well as bugs in software. Even security professionals have difficulty determining whether a PC contains malware. Such malware can control the connection before it is secured, thereby achieving the ability to see the data, as well as potentially change it in real time. Although endpoint security software such as antivirus solutions as well as zero-day prevention solutions provides good security, they are not always installed, and antivirus software is often not up-to-date. Users also can temporarily disable the solutions. Therefore, the presence of malware remains a security concern. Bugs in software are also relevant, for example in the web browser or the operating system.

The lack of user education is the other important concern on the endpoint: Users must know how to identify a secured connection, for example by the little padlock in a web browser (although not even this security mechanism is completely secure). They must also know how to deal with exceptions such as expired or invalid certificates. Most average users do not entirely under­stand all these details, leading to breaches of security.

The Network Operator View

In the early days of IPv6 it was postulated that the protocol would come with IPsec end-to-end security built in and always "on," thereby eliminating all security problems. This assumption turned out to be wrong, because many problems remain on the network side—for example, general problems with end-to-end security—and they apply to all variants, such as IPsec, TLS, or Secure Sockets Layer (SSL).

Today, most enterprise network operators as well as service providers are skeptical about the ubiquitous use of end-to-end security solutions. The fundamental concern is that the endpoints generally cannot be trusted. The network operator, whether enterprise, university, or service provider, has an obligation to enforce certain policies on the endpoint, for example, to ensure that it does not spread worms, send spam mail, or attack servers. If, however, network operators cannot "see" the traffic of an endpoint because it is end-to-end secured, then they cannot comply with their obligations to control the endpoints. From a network operator's perspective it is therefore not generally desirable to use end-to-end security for all communications, but only for those that really need it.

Why Network-Based Security Is Essential

There are many examples where network-based security is essential, and where end-to-end security solutions not only do not help, but may actually present an additional problem. In all those cases it is essential to have strong network-based security solutions in place. Some examples explain this in more detail.

The Service Provider with DSL Customers

A service provider with DSL customers needs to control its users' traffic in various ways. However, the provider has no control over the endpoints, because those are the customers' property. Because they also cannot force their customers to use appropriate security software, there is always a certain percentage of infected PCs on any given service provider's network. Critical service provider concerns follow:

  • Control of PCs infected with malware: Such PCs (also referred to as "bots" or "zombies") can infect other PCs and participate in illegal activities, such as spam mail, click fraud [12], Denial-of-Service (DoS) attacks, etc. There is a strong, often legal requirement for providers to identify such infected PCs, to isolate them, and to alert their owners and help them to "disinfect" the PC. Network-based security mechanisms are required, essentially because security on the endpoint has failed.
  • Attacks from the users: Even in the absence of malware, a service provider's user can participate in illegal activities, such as DoS attacks, or intrusions on web servers or routers. Network-based methods are required to detect such attempts, beginning with simple forms such as IP spoofing [6], and to prevent or block them. One example is network-based solutions against DoS attacks[7,8].
  • Control of bandwidth: Many service providers need to enforce bandwidth limits on some applications or users because they violate service agreements. Also here, applications are necessary to control the PCs, and to limit their usage of the service to remain within contracted boundaries. Service providers today employ a large number of network-based security mechanisms, ranging from visibility solutions to enforcement of certain policies. Endpoint security does not solve these problems, because the PC is not under control of the service provider, and is typically untrusted.
  • Services: Service providers also try to differentiate themselves from their competition by offering managed services, for example managed security services [9]. Those services are also network-based, and they complement endpoint security solutions that their customers use.

The Service Provider with Customers Under Attack

Service providers may also be required to help their customers when they are under attack. DoS attacks illustrate why endpoint security may not be sufficient, and network-based security is required. Under a DoS attack, a web server, for example, may receive more traffic than it can handle. Such attacks can also overload network resources, such as subscriber lines or routers; therefore, endpoint security is not able to solve such attacks. Massive overprovisioning would be the only way to handle DoS attacks, but this approach is com­mercially not generally feasible. Network-based solutions based on flow analysis and selective discard of flows are required to help in such situations.

The Enterprise Network

At first glance it seems that enterprises should have full control over the PCs in the enterprise. In such a case, it would be possible to rely completely on end-to-end security. However, this assumption is unrealistic. Numerous current shortcomings make this approach impractical today:

  • Enterprise PCs can also get infected with malware, leading to the same problem as for service providers described previously: the need to monitor and control the behavior of a PC in the network. Solutions to control endpoints are themselves network-based; for example, network endpoint assessment [10] and user authentication (802.1x) [11].
  • Attacks from users, or against services within the enterprise, also exist in an enterprise environment, as explained previously for service providers. Solutions are network-based.
  • The enforcement of Quality of Service (QoS) is also a security concern: Users could wrongly classify all their traffic as "high-priority." In the absence of full application control on the PC (which is impractical today), the network needs to control flows from the PC, and potentially enforce a QoS policy. If all flows were encrypted end-to-end, this control would be "blind," probably leading to undesired results. Network security mechanisms are required to control the QoS policy.
  • Scale: In an enterprise with several offices that are connected over an untrusted network (for example, the Internet), it may be impractical today to roll out full end-to-end security across the entire enterprise. The currently used approach in most enterprises is to connect the offices with IPsec gateways, and leave traffic within an office in the clear. This scenario increases manageability and scalability of the network. Again, this solution is network-based security solution.
  • Although PCs can theoretically be equipped with IPsec (for example) for all communications, many end devices in an enterprise do not support the security mechanisms required. Printers, faxes, and scanners are examples. Full end-to-end security, however, would require all endpoints to support a common mechanism, such as IPsec or TLS. Until all such devices have this support, network-based mechanisms are required to secure communications with them.


End-to-end security protocols and solutions are an essential cornerstone in network security. We cannot live without them. However, it is unrealistic in today's networks to assume that end-to-end security solutions alone will suffice. The fundamental underlying problem is that typically the network operator, where a PC is attached, has a need and often an obligation to monitor the behavior of the endpoint, and to control malicious activities emerging from that PC. All solutions to control endpoints, however, are by definition network-based. Therefore, network-based security mechanisms are also an essential component of overall network security: Overall security requires both endpoint security and network-based security.


[1] T. Dierks, et al., "The Transport Layer Security (TLS) Protocol Version 1.2," RFC 5246, August 2008.

[2] S. Kent, et al., "Security Architecture for the Internet Protocol," RFC 4301, December 2005.

[3] Joan Daemen and Vincent Rijmen, The Design of Rijndael: AES–The Advanced Encryption Standard, Springer-Verlag, 2002. ISBN 3-540-42580-2.

[4] ANSI X9.52:1998, "Triple Data Encryption Algorithm Modes of Operation," July 1998.

[5] FIPS 180-2, "Secure Hash Standard (SHS)" February 2004.

[6] F. Ali, "IP Spoofing," The Internet Protocol Journal, Volume 10, No. 4, December 2007.

[7] W. Eddy, "Defenses Against TCP SYN Flooding Attacks," The Internet Protocol Journal, Volume 9, No. 4, December 2006.

[8] C. Patrikakis, et al., "Distributed Denial of Service Attacks," The Internet Protocol Journal, Volume 7, No. 4, December 2004.

[9] K. Trivedi and D. Holloway, "Secure Multivendor Networks," The Internet Protocol Journal, Volume 10, No. 3, September 2007.

[10] P. Sangster, et al., "Network Endpoint Assessment (NEA): Overview and Requirements," RFC 5209, June 2008.

[11] IEEE 802.1X "Port-Based Network Access Control,"

[12] According to Wikipedia: "Click fraud is a type of Internet crime that occurs in pay per click online advertising when a person, automated script or computer program imitates a legitimate user of a web browser clicking on an ad, for the purpose of generating a charge per click without having actual interest in the target of the ad's link. Click fraud is the subject of some controversy and increasing litigation due to the advertising networks being a key beneficiary of the fraud.

Use of a computer to commit this type of Internet fraud is a felony in many jurisdictions, for example, as covered by Penal Code 502 in California, USA, and the Computer Misuse Act 1990 in the United Kingdom. There have been arrests relating to click fraud with regard to malicious clicking in order to deplete a competitor's advertising budget."

MICHAEL H. BEHRINGER works at Cisco Systems as a distinguished engineer, where he focuses on core security problems, such as MPLS security, multicast security, and Denial-of-Service attack prevention. Michael holds a diploma in computer science from the Technical University of Munich. He is an active member of the IETF, and has published several papers, RFCs, and a book about MPLS VPN security. E-mail: