Archaeological and Combinatorial Evolution of Board Games: From the Royal Game of Ur to Roman Tabula and Sasanian Nard

Abstract and Historical Continuum

The history of abstract board games is an uninterrupted chronicle of human cognitive evolution, spanning over five millennia of material culture, epigraphic evidence, and mathematical formalization. Far from being trivial pastimes, linear track and race games served as philosophical models of destiny, cosmological diagrams of the celestial spheres, and rigorous arenas for tactical optimization. From the lapis-lazuli inlays of Early Dynastic Sumer to the dice regulations of imperial Rome and the dualistic cosmology of Sasanian Persia, this monograph traces the structural, material, and mathematical journey that culminated in classical backgammon.

The Royal Game of Ur: Archaeological Material from Tomb PG 789

In the mid-1920s, British archaeologist Sir Leonard Woolley, conducting excavations at the Royal Cemetery of Ur in southern Mesopotamia, uncovered five gaming boards in royal tombs. The most pristine specimen, discovered in tomb PG 789 (dated to circa 2600–2500 BCE), featured a hollow wooden box veneered with engraved shell plaques, red limestone, and lapis lazuli set in bitumen. Accompanying the board were seven black shale discs, seven white shell discs, and four tetrahedral bone dice.

The board's topology consists of a 20-square layout divided into three distinct functional zones: a 3×4 primary block, a narrow 1×2 bridge or isthmus, and a 2×3 terminal sanctuary. Despite the board's discovery, the operational rules remained an enigma for over half a century until Dr. Irving Finkel of the British Museum translated a fragmentary Babylonian cuneiform tablet, BM 33333b. Written in 177 BCE by the scribe Itti-Marduk-balātu, the inscription preserved an ancient gaming tradition outlining movement rules, rosette bonuses, and gambling wagers.

Stochastic Mechanics: Tetrahedral Dice and Binomial Distributions

Movement in the Royal Game of Ur is governed by casting four tetrahedral dice. Each four-sided die features two tipped vertices and two untipped vertices. Assuming physical symmetry, the probability of any given die landing with a tipped vertex face-up is \(p = 0.5\). The total movement advance \(X\) follows the binomial distribution:

P(X = k) = C(4, k) * (0.5)^k * (0.5)^(4-k) = C(4, k) / 16

This yields a discrete probability distribution across the possible outcomes:

• P(X = 0) = 1/16 (6.25%): In Babylonian tradition, rolling zero conferred 4 movement steps or an immediate re-roll.
• P(X = 1) = 4/16 (25.00%): An advance of 1 square.
• P(X = 2) = 6/16 (37.50%): An advance of 2 squares (the modal expectation).
• P(X = 3) = 4/16 (25.00%): An advance of 3 squares.
• P(X = 4) = 1/16 (6.25%): An advance of 4 squares.

The bell-shaped probability mass concentrates around 2 points of movement, forcing checkers to interact intensively across the shared 8-square isthmus where opposing tracks converge. Rosettes positioned on key squares granted immunity from capture and awarded an extra turn, introducing a sophisticated tactical choice between safe, consolidated holding points and rapid tempo leaps toward the terminal zone.

Egyptian Senet: The Underworld Cartography of KV62

Contemporaneous with the Sumerian track games, ancient Egypt cultivated Senet ("the game of passing"). The earliest physical attestations date from Predynastic Naqada III burials (circa 3100 BCE), with monumental physical sets recovered from the intact tomb of Tutankhamun (KV62, New Kingdom, circa 1323 BCE). The board comprises a 3×10 grid of 30 squares arranged in a boustrophedon (ox-turning) serpentine movement track.

During the New Kingdom, Senet underwent a profound theological evolution, transitioning from an elite courtly pastime to a symbolic simulation of the soul's journey through the Duat (the netherworld). Players cast four flat split-reed casting sticks (producing scores of 1, 2, 3, 4, or 5). Key squares carried mythological significance:

• Square 15 (House of Rebirth): The central sanctuary where captured pieces were returned to restart their journey.
• Square 26 (House of Beauty): A mandatory stopping point honoring the embalming rites.
• Square 27 (House of Water): Representing the primordial abyss of chaos (Nun); landing here drowned the piece, sending it back to Square 15.
• Square 30 (Realm of Horus/Ra): The terminal square where pieces bore off into eternity.

Roman Tabula: Agathias and Emperor Zeno's Tactical Catastrophe

The direct geometric ancestor of backgammon was codified in the classical Roman world. Progressing from the earlier Ludus Duodecim Scriptorum (Game of Twelve Markings, played on a 3×12 grid), Roman players streamlined the board into the modern 2×12 layout of 24 points, naming the game Tabula (meaning "board" or "table").

Tabula was played with 15 pieces per side and three six-sided cubic dice (\(3d6\)). The crucial operational rule preserved in Latin and Greek literature was the vulnerability of the lone, isolated piece (known as a vagus or wanderer, the direct precursor of the backgammon "blot"). When hit by an opponent's piece, the blot was expelled from the board and forced to re-enter at the opponent's starting sector.

The most famous match in ancient gaming literature is preserved in an epigram by the Byzantine jurist and poet Agathias Scholasticus (circa 530–582 CE), recording an actual game played in 480 CE by Eastern Roman Emperor Zeno. Zeno possessed an aggressive, forward-leaning position with multiple advanced checkers, but had left single blots on points 2, 7, 8, 9, 10, and 11. Casting three dice, Zeno rolled 2, 5, and 6.

Under Roman Tabula regulations, a player was legally compelled to utilize all three dice values if any legal combination existed, regardless of tactical detriment. Because the destination points for the dice were occupied by opposing doublets or required breaking secure points, Zeno was forced to dismantle his defensive primes, creating seven exposed blots simultaneously and triggering an immediate collapse of his position. This text confirms that the rules of point ownership, compulsory dice expenditure, and blot hitting were completely established by the late fifth century.

Sasanian Nard: Bozorgmehr and Cosmological Dualism

During the reign of Sasanian King of Kings Khosrow I Anushirvan (531–579 CE), the game reached Persia under the name Nard (or Nardashir). The Middle Persian Pahlavi treatise Wizārišn ī Čatrang ud Nihišn ī Nēw-Ardašēr (The Explanation of Chess and the Invention of Nard), echoed centuries later in Ferdowsi's epic Shahnameh, documents the arrival of chess from India and the response of the Persian court.

When the Indian embassy presented chess as an enigma of pure intellectual calculation, the grand vizier Bozorgmehr not only deduced the rules of chess without instruction, but designed Nard as a philosophical counter-demonstration. Bozorgmehr structured Nard to mirror the Zoroastrian cosmology of Bundahishn, balancing deterministic calculation (human wisdom) against the stochastic rolls of the dice (fate and divine will):

• The Board: Represents the terrestrial world created by Spenta Mainyu.
• The 24 Points: Represent the 24 hours of the solar day (12 hours of sunlight and 12 hours of night).
• The 12 Points per Quadrant: Represent the 12 signs of the zodiac and the 12 months of the year.
• The 30 Pieces: Represent the 30 days of the lunar month (15 white for the waxing moon, 15 black for the waning moon).
• The Movement: Checkers moving in opposing directions across the board symbolize the eternal cyclical struggle between order and disorder.

Conclusion

From the inlaid bitumen of Sumerian Ur to the royal courts of Byzantium, Ctesiphon, and the modern digital era, the unbroken architectural lineage of linear race games reflects humanity's enduring fascination with chance and tactical control. The modern 24-point backgammon board is not a modern contrivance, but the mathematical distillation of five thousand years of cultural, archaeological, and combinatorial refinement.

Computational Solvers, 32-Bit Bitboard Topologies, and Retrograde Analysis in Classical Draughts

Abstract and Theoretical Complexity

In the taxonomy of combinatorial games, 8×8 draughts (checkers) occupies a uniquely rigorous position: it represents the largest mathematically solved board game in computational history. While classical chess boasts an estimated state space cardinality of \(10^{43}\) to \(10^{50}\) configurations and a Shannon game-tree bound of \(10^{120}\), American checkers possesses a state space of approximately \(5 imes 10^{20}\) legal configurations with an unpruned game-tree complexity of \(10^{40}\). In 2007, following an eighteen-year research initiative led by Professor Jonathan Schaeffer at the University of Alberta, checkers was formally announced as weakly solved. Perfect play by both white and black guarantees an immutable theoretical draw.

The resolution of a combinatorial system of this magnitude was made possible through three foundational architectural pillars: compact 32-bit bitboard state representations executing SIMD-style parallel move generation, the aggressive tree-collapsing dynamics of mandatory capture rules, and the construction of exhaustive retrograde endgame tablebases indexing 39 trillion distinct board positions. This paper examines the algorithmic mechanics and system architecture underlying contemporary draughts solving engines.

32-Bit Bitboard Representations and SIMD Parallelism

The geometry of the standard 64-square board exhibits a critical topological property: play occurs exclusively on the 32 dark squares. Rather than allocating multidimensional arrays or object-oriented pointer graphs—which introduce severe cache-line thrashing and heap fragmentation—modern engines map the entire active topology onto 32-bit unsigned processor registers (uint32_t). Each individual bit in the register maps isomorphically to a single playable square.

A complete board state is encapsulated within four primitive bitboards:

• black_men: Mask indicating occupied squares for standard black pieces.
• black_kings: Mask indicating occupied squares for crowned black kings.
• white_men: Mask indicating occupied squares for standard white pieces.
• white_kings: Mask indicating occupied squares for crowned white kings.

Empty squares are resolved across the entire board in a single CPU cycle via bitwise NOR: empty = ~(black_men | black_kings | white_men | white_kings). Diagonal step movements and jump vectors are computed using fixed bit-shift offsets combined with boundary edge masks to prevent wraparound across file boundaries. Under standard indexing:

// Parallel forward step generation for black pieces using SWAR
uint32_t step_left  = (black_pieces & MASK_NOT_COL_A) << 4;
uint32_t step_right = (black_pieces & MASK_NOT_COL_H) << 5;
uint32_t legal_steps_left  = step_left & empty_squares;
uint32_t legal_steps_right = step_right & empty_squares;

By executing bitwise operations natively within processor registers (Single Instruction, Multiple Data Within A Register, or SWAR), move generation benchmarks routinely surpass 40 million evaluated states per second per core, without touching main memory.

Mandatory Capture Dynamics and Branching Factor Collapse

Unlike chess or go, where players retain wide strategic discretion over peaceful maneuvering versus tactical exchanges, draughts enforces a strict mandatory capture rule. If a player possesses an available jump over an opposing piece, all non-capturing positional moves are legally prohibited.

This structural rule induces a dramatic compression in game-tree complexity. In tranquil, non-tactical positions, the effective branching factor \(b\) of 8×8 checkers ranges between 6 and 8 plausible legal transitions per ply. However, the instant tactical contact occurs and a capture becomes available, the mandatory capture rule prunes the legal search space down to an average of \(1.2 \le b \le 2.0\) branches. In multi-jump combinations, the branching factor often collapses to \(b = 1.0\)—a deterministic forced sequence.

In modern web and desktop competitive implementations, such as the authoritative server architecture deployed by Checkers Crown, mandatory capture logic is enforced at the protocol level. The client-side 2D Canvas engine computes capture chains in real time, preventing illegal non-jump selections while synchronizing validated state transitions with the server backend.

Alpha-Beta Pruning, PVS, and Transposition Networks

To traverse deep game trees, high-performance engines employ the Principal Variation Search (PVS) algorithm, an enhanced variant of alpha-beta pruning that speculates that the first generated move (ordered via move heuristics) is the optimal path. The primary move is searched with a full window \([lpha, eta]\), while all subsequent candidate moves are searched with a minimal null-window \([lpha, lpha + 1]\):

int pvs(GameState state, int depth, int alpha, int beta) {
    if (depth == 0 || state.is_terminal()) {
        return quiescence_search(state, alpha, beta);
    }
    
    // Probe transposition table for exact or bound matches
    TTEntry* entry = probe_tt(state.zobrist_key);
    if (entry && entry->depth >= depth) {
        if (entry->flag == EXACT) return entry->score;
        if (entry->flag == LOWERBOUND) alpha = max(alpha, entry->score);
        if (entry->flag == UPPERBOUND) beta = min(beta, entry->score);
        if (alpha >= beta) return entry->score;
    }
    
    bool first_move = true;
    for (const auto& move : state.generate_ordered_moves()) {
        GameState child = state.apply_move(move);
        int score;
        
        if (first_move) {
            score = -pvs(child, depth - 1, -beta, -alpha);
            first_move = false;
        } else {
            // Null-window search to refute sub-optimal moves quickly
            score = -pvs(child, depth - 1, -alpha - 1, -alpha);
            if (score > alpha && score < beta) {
                // Null-window failed high: re-search with full window
                score = -pvs(child, depth - 1, -beta, -alpha);
            }
        }
        
        if (score >= beta) {
            store_tt(state.zobrist_key, depth, score, LOWERBOUND, move);
            return beta; // Beta cut-off
        }
        if (score > alpha) {
            alpha = score;
        }
    }
    
    store_tt(state.zobrist_key, depth, alpha, EXACT, best_move);
    return alpha;
}

Positions are mapped into hash tables using 64-bit Zobrist hashing, where each piece-square permutation is assigned a pseudo-random integer. The Zobrist key is incrementally updated in \(\mathcal{O}(1)\) time using bitwise XOR, allowing rapid transposition detection across convergent move orders.

Retrograde Analysis and 39-Trillion Position Endgame Tablebases

The definitive weakly solved proof achieved by Chinook was enabled by exhaustive retrograde analysis. Traditional minimax search operates forward from the root down to a heuristic evaluation horizon. In contrast, retrograde analysis works backward from known terminal configurations:

1. Base Initialization: Catalog all 1-piece and 2-piece terminal configurations where one side has been wiped out or immobilized, assigning game-theoretic values (Win, Loss, Draw) and Distance-to-Conversion (DTC) metrics.
2. Inductive Propagation: Iteratively step backward through unvisited predecessor states. If a predecessor state possesses at least one legal move leading to a known Loss for the opponent, that predecessor is classified as a Win. If all legal transitions from a predecessor lead to known Wins for the opponent, the predecessor is classified as a Loss.
3. Equilibrium Convergence: Positions that cannot be forced into either win or loss categories through optimal resistance are proven to be game-theoretic Draws.

By scaling this retrograde pipeline across distributed clusters, Schaeffer's team cataloged every legal board configuration containing up to 10 pieces on the board—surpassing 39 trillion positions (\(3.9 imes 10^{13}\)). During live play, whenever the forward search tree reaches any configuration containing \(\le 10\) pieces, the engine terminates search immediately and retrieves the mathematically perfect game outcome in \(\mathcal{O}(1)\) time.

Conclusion

The weak solution of 8×8 checkers demonstrated that massive combinatorial search spaces can be systematically mastered through the combination of hardware-tailored representations (32-bit bitboards), domain-specific pruning dynamics (mandatory jump rules), and dynamic programming over terminal graphs (retrograde tablebases). Rather than extinguishing intellectual interest, computational solving provides an exact mathematical foundation for evaluating positional aesthetics, tactical combinations, and human decision quality.

Minimax vs Expectiminimax: Handling Chance Nodes in Strategic Game Trees

5 Reasons an AI Workout App Beats a Generic Gym Plan

 Choosing between a one-size-fits-all routine and a smart, adaptive plan can make or break your progress in the gym. Modern AI fitness tools build a plan around your goals, equipment and experience, then adjust as you get stronger. They also make logging sets and reps fast, track personal records, and keep you consistent with streaks and clear progress charts. If you train in the gym and want a plan that actually evolves with you, try WorkoutInGym

VPN Protocols

Protocols

There are a number of VPN protocols in use that secure the transport of data traffic over a public network infrastructure. Each protocol varies slightly in the way that data is kept secure.

IP security (IPSec) is used to secure communications over the Internet. IPSec traffic can use either transport mode or tunneling to encrypt data traffic in a VPN. The difference between the two modes is that transport mode encrypts only the message within the data packet (also known as the payload) while tunneling encrypts the entire data packet. IPSec is often referred to as a "security overlay" because of its use as a security layer for other protocols.

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) use cryptography to secure communications over the Internet. Both protocols use a "handshake" method of authentication that involves a negotiation of network parameters between the client and server machines. To successfully initiate a connection, an authentication process involving certificates is used. Certificates are cryptographic keys that are stored on both the server and client.

Point-To-Point Tunneling Protocol (PPTP) is another tunneling protocol used to connect a remote client to a private server over the Internet. PPTP is one of the most widely used VPN protocols because of it's straightforward configuration and maintenance and also because it is included with the Windows operating system.

Layer 2 Tunneling Protocol (L2TP) is a protocol used to tunnel data communications traffic between two sites over the Internet. L2TP is often used in tandem with IPSec (which acts as a security layer) to secure the transfer of L2TP data packets over the Internet. Unlike PPTP, a VPN implementation using L2TP/IPSec requires a shared key or the use of certificates.

VPN technology employs sophisticated encryption to ensure security and prevent any unintentional interception of data between private sites. All traffic over a VPN is encrypted using algorithms to secure data integrity and privacy. VPN architecture is governed by a strict set of rules and standards to ensure a private communication channel between sites. Corporate network administrators are responsible for deciding the scope of a VPN, implementing and deploying a VPN, and ongoing monitoring of network traffic across the network firewall. A VPN requires administrators to be continually be aware of the overall architecture and scope of the VPN to ensure communications are kept private.

What is VPN?

A Virtual Private Network (VPN) is a network technology that creates a secure network connection over a public network such as the Internet or a private network owned by a service provider. Large corporations, educational institutions, and government agencies use VPN technology to enable remote users to securely connect to a private network.

A VPN can connect multiple sites over a large distance just like a Wide Area Network (WAN). VPNs are often used to extend intranets worldwide to disseminate information and news to a wide user base. Educational institutions use VPNs to connect campuses that can be distributed across the country or around the world.

In order to gain access to the private network, a user must be authenticated using a unique identification and a password. An authentication token is often used to gain access to a private network through a personal identification number (PIN) that a user must enter. The PIN is a unique authentication code that changes according to a specific frequency, usually every 30 seconds or so.

L2TPv3

Layer 2 Tunneling Protocol Version 3 is an IETF standard related to L2TP that can be used as an alternative protocol to Multiprotocol Label Switching (MPLS) for encapsulation of multiprotocol Layer 2 communications traffic over IP networks. Like L2TP, L2TPv3 provides a ‘pseudo-wire’ service, but scaled to fit carrier requirements. buy-vpn
L2TPv3 can be regarded as being to MPLS what IP is to ATM: a simplified version of the same concept, with much of the goodness achieved with a fraction of the effort, at the cost of losing some technical features considered less important in the market. In the case of L2TPv3, the features lost are teletraffic engineering features considered important in MPLS. The protocol overhead of L2TPv3 is also significantly bigger than MPLS. However, there is no reason why these features could not be re-engineered in or on top of L2TPv3 in later products.

Transport Layer Security

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the Internet. TLS and SSL encrypt the segments of network connections at the Application Layer for theTransport Layer, using asymmetric cryptography for key exchange, symmetric encryption for confidentiality, and message authentication codes for message integrity.

Several versions of the protocols are in widespread use in applications such as web browsing, electronic mail, Internet faxing, instant messaging and voice-over-IP (VoIP).

TLS is an IETF standards track protocol, last updated in RFC 5246, and is based on the earlier SSL specifications developed by Netscape Communications.

Description

The TLS protocol allows client-server applications to communicate across a network in a way designed to prevent eavesdropping and tampering.

Since most protocols can be used either with or without TLS (or SSL) it is necessary to indicate to the server whether the client is making a TLS connection or not. There are two main ways of achieving this; one option is to use a different port number for TLS connections (for example port 443 for HTTPS). The other is to use the regular port number and have the client request that the server switch the connection to TLS using a protocol specific mechanism (for example STARTTLS for mail and news protocols).

Once the client and server have decided to use TLS they negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security.

    The client sends the server the client's SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.
    The server sends the client the server's SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client's certificate.
    The client uses the information sent by the server to authenticate the server (see Server Authentication for details). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to step 4.
    Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher being used) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.
    If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.
    If the server has requested client authentication, the server attempts to authenticate the client (see Client Authentication for details). If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.
    Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).
    The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.
    The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.

The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.

This is the normal operation condition of the secure channel. At any time, due to internal or external stimulus (either automation or user intervention), either side may renegotiate the connection, in which case, the process repeats itself.

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.

If any one of the above steps fails, the TLS handshake fails and the connection is not created.

Security

TLS has a variety of security measures:

    Protection against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite.
    Numbering subsequent Application records with a sequence number and using this sequence number in the message authentication codes (MACs).
    Using a message digest enhanced with a key (so only a key-holder can check the MAC). The HMAC construction used by most TLS cipher suites is specified in RFC 2104 (SSL 3.0 used a different hash-based MAC).
    The message that ends the handshake ("Finished") sends a hash of all the exchanged handshake messages seen by both parties.
    The pseudorandom function splits the input data in half and processes each one with a different hashing algorithm (MD5 and SHA-1), then XORs them together to create the MAC. This provides protection even if one of these algorithms is found to be vulnerable. TLS only.
    SSL 3.0 improved upon SSL 2.0 by adding SHA-1 based ciphers and support for certificate authentication.

From a security standpoint, SSL 3.0 should be considered less desirable than TLS 1.0. The SSL 3.0 cipher suites have a weaker key derivation process; half of the master key that is established is fully dependent on the MD5 hash function, which is not resistant to collisions and is, therefore, not considered secure. Under TLS 1.0, the master key that is established depends on both MD5 and SHA-1 so its derivation process is not currently considered weak. It is for this reason that SSL 3.0 implementations cannot be validated under FIPS 140-2.[16]

A vulnerability of the renegotiation procedure was discovered in August 2009 that can lead to plaintext injection attacks against SSL 3.0 and all current versions of TLS. For example, it allows an attacker who can hijack an https connection to splice their own requests into the beginning of the conversation the client has with the web server. The attacker can't actually decrypt the client-server communication, so it is different from a typical man-in-the-middle attack. A short-term fix is for web servers to stop allowing renegotiation, which typically will not require other changes unless client certificate authentication is used. To fix the vulnerability, a renegotiation indication extension was proposed for TLS. It will require the client and server to include and verify information about previous handshakes in any renegotiation handshakes.[17] This extension has become a proposed standard and has been assigned the number RFC 5746. The RFC has been implemented in recent OpenSSL[18] and other libraries.[19][20]

There are some attacks against the implementation rather than the protocol itself:[21]

    In the earlier implementations, some CAs[22] did not explicitly set basicConstraints CA=FALSE for leaf nodes. As a result, these leaf nodes could sign rogue certificates. In addition, some early software (including IE6 and Konqueror) did not check this field altogether. This can be exploited for man-in-the-middle attack on all potential SSL connections.
    Some implementations (including older versions of Microsoft Cryptographic API, Network Security Services and GnuTLS) stop reading any characters that follow the null character in the name field of the certificate, which can be exploited to fool the client into reading the certificate as if it were one that came from the authentic site, e. g. paypal. com\0.badguy.com would be mistaken as the site of paypal.com rather than badguy.com.
    Browsers implemented SSL/TLS protocol version fallback mechanisms for compatibility reasons. The protection offered by the SSL/TLS protocols against a downgrade to a previous version by an active MITM attack can be rendered useless by such mechanisms.[23]

SSL 2.0 is flawed in a variety of ways:[citation needed]

    Identical cryptographic keys are used for message authentication and encryption.
    SSL 2.0 has a weak MAC construction that uses the MD5 hash function with a secret prefix, making it vulnerable to length extension attacks.
    SSL 2.0 does not have any protection for the handshake, meaning a man-in-the-middle downgrade attack can go undetected.
    SSL 2.0 uses the TCP connection close to indicate the end of data. This means that truncation attacks are possible: the attacker simply forges a TCP FIN, leaving the recipient unaware of an illegitimate end of data message (SSL 3.0 fixes this problem by having an explicit closure alert).
    SSL 2.0 assumes a single service and a fixed domain certificate, which clashes with the standard feature of virtual hosting in Web servers. This means that most websites are practically impaired from using SSL.

SSL 2.0 is disabled by default, beginning with Internet Explorer 7,[24] Mozilla Firefox 2,[25] Opera and Safari. After it sends a TLS ClientHello, if Mozilla Firefox finds that the server is unable to complete the handshake, it will attempt to fall back to using SSL 3.0 with an SSL 3.0 ClientHello in SSL 2.0 format to maximize the likelihood of successfully handshaking with older servers.[26] Support for SSL 2.0 (and weak 40-bit and 56-bit ciphers) has been removed completely from Opera as of version 9.5.[27]

Modifications to the original protocols, like False Start (adopted and enabled by Google Chrome[28]) or Snap Start, have been reported to introduce limited TLS protocol version rollback attacks[29] or to allow modifications to the cipher suite list sent by the client to the server (an attacker may be able to influence the cipher suite selection in an attempt to downgrade the cipher suite strength, to use either a weaker symmetric encryption algorithm or a weaker key exchange[30]).

HTTP Secure - HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is a widely used communications protocol for secure communication over a computer network, with especially wide deployment on the Internet. Technically, it is not a protocol in itself; rather, it is the result of simply layering the Hypertext Transfer Protocol (HTTP) on top of the SSL/TLS protocol, thus adding the security capabilities of SSL/TLS to standard HTTP communications.

In its popular deployment on the internet, HTTPS provides authentication of the web site and associated web server that one is communicating with, which protects against Man-in-the-middle attacks. Additionally, it provides bidirectional encryption of communications between a client and server, which protects against eavesdropping and tampering with and/or forging the contents of the communication.[1] In practice, this provides a reasonable guarantee that one is communicating with precisely the web site that one intended to communicate with (as opposed to an impostor), as well as ensuring that the contents of communications between the user and site cannot be read or forged by any third party.

Because HTTPS piggybacks HTTP entirely on top of TLS, the entirety of the underlying HTTP protocol can be encrypted. This includes the request URL (which particular web page was requested), query parameters, headers, and cookies (which often contain identity information about the user). However, because host (web site) addresses and port numbers are necessarily part of the underlying TCP/IP protocols, HTTPS cannot protect their disclosure. In practice this means that even on a correctly configured web server eavesdroppers can still infer the IP address and port number of the web server (sometimes even the domain name e.g. www.example.org, but not the rest of the URL) that one is communicating with as well as the amount (data transferred) and duration (length of session) of the communication, though not the content of the communication.[citation needed]

Historically, HTTPS connections were primarily used for payment transactions on the World Wide Web, e-mail and for sensitive transactions in corporate information systems. In the late 2000s and early 2010s, HTTPS began to see widespread use for protecting page authenticity on all types of websites, securing accounts and keeping user communications, identity and web browsing private.

HTTPS is especially important over unencrypted networks such as WiFi as anyone on the same local network can do packet sniffing and discover sensitive information. Additionally, many free to use and even paid for WLAN networks do packet injection for serving their own ads on webpages or just for pranks, however this can be exploited maliciously e.g. by injecting malware and spying on users.[2] Another example where HTTPS is important is connections over Tor (anonymity network), as malicious Tor nodes can damage or alter the contents passing through them in an insecure fashion and inject malware into the connection. This is one reason why the Electronic Frontier Foundation and Torproject started the development of HTTPS Everywhere, which is included in the Tor Browser Bundle.

A site must be completely hosted over HTTPS, without having some of its contents loaded over HTTP, or the user will be vulnerable to some attacks and surveillance. E.g. Having scripts etc. loaded insecurely on a HTTPS page makes the user vulnerable to attacks. Also having only a certain page that contains sensitive information (such as a log-in page) of a website loaded over HTTPS, while having the rest of the website loaded over plain HTTP will expose the user to attacks. E.g. if the user first accesses the front page of the website with HTTP where he only after that clicks an HTTPS link to the log-in page, the session has already been compromised. On a site that has sensitive information somewhere on it, every time that site is accessed with HTTP instead of HTTPS, the user and the session will get exposed. Similarly, cookies on a site served through HTTPS have to have the secure attribute enabled.[3]

A common misconception is that HTTPS is performance heavy and cannot be deployed on existing equipment. This isn't true; deploying HTTPS requires no additional equipment or special hardware.[1][3] Deploying HTTPS also allows the use of SPDY, which is designed to reduce page load times and latency.

It is recommended to use HTTP Strict Transport Security with HTTPS to protect users from man-in-the-middle attacks.[3][4]

As of 2012-06-22 only 12.3% of the Internet's 186821 most popular web sites have a secure implementation of HTTPS. This leaves 87.7% (163776) open to some attacks.[5] This survey is powered by Qualys' SSL Server Test, in which anyone can audit the HTTPS implementation of a specified web server.

HTTPS should not be confused with the little-used Secure HTTP (S-HTTP) specified in RFC 2660.

Difference from HTTP

HTTPS URLs begin with "https://" and use port 443 by default, whereas HTTP URLs begin with "http://" and use port 80 by default.

HTTP is insecure and is subject to man-in-the-middle and eavesdropping attacks, which can let attackers gain access to website accounts and sensitive information. HTTPS is designed to withstand such attacks and is considered secure against such attacks (with the exception of older deprecated versions of SSL).

Point-to-Point Tunneling Protocol PPTP

The Point-to-Point Tunneling Protocol (PPTP) is a method for implementing virtual private networks. PPTP uses a control channel over TCP and a GRE tunnel operating to encapsulate PPP packets.

The PPTP specification does not describe encryption or authentication features and relies on the PPP protocol being tunneled to implement security functionality. However the most common PPTP implementation, shipping with the Microsoft Windows product families, implements various levels of authentication and encryption natively as standard features of the Windows PPTP stack. The intended use of this protocol is to provide similar levels of security and remote access as typical VPN products.

Specification

A specification for PPTP was published as RFC 2637[1] and was developed by a vendor consortium formed by Microsoft, Ascend Communications (today part of Alcatel-Lucent), 3Com, and others. PPTP has not been proposed nor ratified as a standard by the IETF.

A PPTP tunnel is instantiated by communication to the peer on TCP port 1723. This TCP connection is then used to initiate and manage a second GRE tunnel to the same peer.

The PPTP GRE packet format is non standard, including an additional acknowledgement field replacing the typical routing field in the GRE header. However, like in a normal GRE connection, those modified GRE packets are directly encapsulated into IP packets, and seen as IP protocol number 47.

The GRE tunnel is used to carry encapsulated PPP packets, allowing the tunnelling of any protocols that can be carried within PPP, including IP, NetBEUI and IPX.

In the Microsoft implementation, the tunneled PPP traffic can be authenticated with PAP, CHAP, MS-CHAP v1/v2 or EAP-TLS. The PPP payload is encrypted using Microsoft Point-to-Point Encryption (MPPE) when using MS-CHAPv1/v2 or EAP-TLS. MPPE is described by RFC 3078

Implementations

PPTP was the first VPN protocol that was supported by Microsoft Dial-up Networking. All releases of Microsoft Windows since Windows 95 OSR2 are bundled with a PPTP client, although they are limited to only 2 concurrent outbound connections. Microsoft Windows Mobile 2003 and higher also support the PPTP protocol. The Routing and Remote Access Service for Microsoft Windows contains a PPTP server. The Microsoft implementation uses single DES in the MS-CHAP authentication protocol which many find unsuitable for data protection needs.

Windows Vista and later support the use of PEAP with PPTP. The authentication mechanisms supported are PEAPv0/EAP-MSCHAPv2 (passwords) and PEAP-TLS (smartcards and certificates). Windows Vista removed support for using the MSCHAP-v1 protocol to authenticate remote access connections.

Linux server-side support for PPTP is provided by the PoPToP daemon. and kernel modules for PPP and MPPE. The first PPTP implementation was developed by Matthew Ramsay in 1999. and initially distributed under the GNU GPL by Moreton Bay. However, Linux distributions initially lacked full PPTP support because MPPE was believed to be patent encumbered. Full MPPE support was added to the Linux kernel in the 2.6.14 release on October 28, 2005. SuSE Linux 10 was the first Linux distribution to provide a complete working PPTP client. There is also ACCEL-PPP - PPTP/L2TP/PPPoE server for Linux. which supports PPTP in kernel-mode.

OS X and iOS are bundled with a PPTP client. Cisco and Efficient Networks sell PPTP clients for older Mac OS releases. Palm PDA devices with Wi-Fi are bundled with the Mergic PPTP client.[citation needed]

Many different Mobile phones with Android as operating system support PPTP as well

Security

PPTP has been the subject of many security analyses and serious security vulnerabilities have been found in the protocol. The known vulnerabilities relate to the underlying PPP authentication protocols used, the design of the MPPE protocol as well as the integration between MPPE and PPP authentication for session key establishment.

A summary of these vulnerabilities is below:

    MSCHAP-v1 is fundamentally insecure. Tools exist to trivially extract the NT Password hashes from a captured MSCHAP-v1 exchange.
    When using MSCHAP-v1, MPPE uses the same RC4 session key for encryption in both directions of the communication flow. This can be cryptanalysed with standard methods by XORing the streams from each direction together.
    MSCHAP-v2 is vulnerable to dictionary attack on the captured challenge response packets. Tools exist to perform this process rapidly.
    In 2012 it was shown that brute-force attack on MSCHAP-v2 is equivalent to single DES key brute-force attack. Online service was presented, which is capable to restore MSCHAP-v2 passphrase's MD4 in 23 hours.
    MPPE uses RC4 stream cipher for encryption. There is no method for authentication of the ciphertext stream and therefore the ciphertext is vulnerable to a bit-flipping attack. An attacker could modify the stream in transit and adjust single bits to change the output stream without possibility of detection. These bit flips may be detected by the protocols themselves through checksums or other means.

EAP-TLS is seen as the superior authentication choice for PPTP;  however, it requires implementation of a Public Key Infrastructure for both client and server certificates. As such it is not a viable authentication option for many remote access installations.

Secure Socket Tunneling Protocol SSTP

Secure Socket Tunneling Protocol (SSTP) is a form of VPN tunnel that provides a mechanism to transport PPP or L2TP traffic through an SSL 3.0 channel. SSL provides transport-level security with key-negotiation, encryption and traffic integrity checking. The use of SSL over TCP port 443 allows SSTP to pass through virtually all firewalls and proxy servers.

SSTP servers must be authenticated during the SSL phase. SSTP clients can optionally be authenticated during the SSL phase, and must be authenticated in the PPP phase. The use of PPP allows support for common authentication methods, such as EAP-TLS and MS-CHAP.

SSTP is available for Linux, Mac OS, BSD and Windows.

For Windows, SSTP is only available since version Windows Vista SP1, in RouterOS, and in SEIL since its firmware version 3.50. It is fully integrated with the RRAS architecture in these operating systems, allowing its use with Winlogon or smart card authentication, remote access policies and the Windows VPN client.

SSTP is only for remote client access, it does not support site-to-site VPN tunnels.

SSTP suffers from the same performance limitations as any other IP-over-TCP tunnel. In general, performance will be acceptable only as long as there is sufficient excess bandwidth on the un-tunneled network link to guarantee that the tunneled TCP timers do not expire. If this becomes untrue, performance falls off dramatically. This is known as the "TCP meltdown problem

L2TP/IPsec

Because of the lack of confidentiality inherent in the L2TP protocol, it is often implemented along with IPsec. This is referred to as L2TP/IPsec, and is standardized in IETF RFC 3193. The process of setting up an L2TP/IPsec VPN is as follows:

        Negotiation of IPsec security association (SA), typically through Internet key exchange (IKE). This is carried out over UDP port 500, and commonly uses either a shared password (so-called "pre-shared keys"), public keys, or X.509 certificates on both ends, although other keying methods exist.
        Establishment of Encapsulating Security Payload (ESP) communication in transport mode. The IP protocol number for ESP is 50 (compare TCP's 6 and UDP's 17). At this point, a secure channel has been established, but no tunneling is taking place.
        Negotiation and establishment of L2TP tunnel between the SA endpoints. The actual negotiation of parameters takes place over the SA's secure channel, within the IPsec encryption. L2TP uses UDP port 1701.

When the process is complete, L2TP packets between the endpoints are encapsulated by IPsec. Since the L2TP packet itself is wrapped and hidden within the IPsec packet, no information about the internal private network can be garnered from the encrypted packet. Also, it is not necessary to open UDP port 1701 on firewalls between the endpoints, since the inner packets are not acted upon until after IPsec data has been decrypted and stripped, which only takes place at the endpoints.

A potential point of confusion in L2TP/IPsec is the use of the terms tunnel and secure channel. The term tunnel refers to a channel which allows untouched packets of one network to be transported over another network. In the case of L2TP/PPP, it allows L2TP/PPP packets to be transported over IP. A secure channel refers to a connection within which the confidentiality of all data is guaranteed. In L2TP/IPsec, first IPsec provides a secure channel, then L2TP provides a tunnel.

L2TP packet exchange

At the time of setup of L2TP connection, many control packets are exchanged between server and client to establish tunnel and session for each direction. One peer requests the other peer to assign a specific tunnel and session id through these control packets. Then using this tunnel and session id, data packets are exchanged with the compressed PPP frames as payload.

The list of L2TP Control messages exchanged between LAC and LNS, for handshaking before establishing a tunnel and session in voluntary tunneling method are

Layer 2 Tunneling Protocol

In computer networking, Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual private networks (VPNs) or as part of the delivery of services by ISPs. It does not provide any encryption or confidentiality by itself; it relies on an encryption protocol that it passes within the tunnel to provide privacy.

History

Published in 1999 as proposed standard RFC 2661, L2TP has its origins primarily in two older tunneling protocols for Point-to-Point communication: Cisco's Layer 2 Forwarding Protocol (L2F) and USRobotics Point-to-Point Tunneling Protocol (PPTP). A new version of this protocol, L2TPv3, was published as proposed standard RFC 3931 in 2005. L2TPv3 provides additional security features, improved encapsulation, and the ability to carry data links other than simply PPP over an IP network (e.g., Frame Relay, Ethernet, ATM, etc.).

Description

The entire L2TP packet, including payload and L2TP header, is sent within a User Datagram Protocol (UDP) datagram. It is common to carry Point-to-Point Protocol (PPP) sessions within an L2TP tunnel. L2TP does not provide confidentiality or strong authentication by itself. IPsec is often used to secure L2TP packets by providing confidentiality, authentication and integrity. The combination of these two protocols is generally known as L2TP/IPsec (discussed below).

The two endpoints of an L2TP tunnel are called the LAC (L2TP Access Concentrator) and the LNS (L2TP Network Server). The LAC is the initiator of the tunnel while the LNS is the server, which waits for new tunnels. Once a tunnel is established, the network traffic between the peers is bidirectional. To be useful for networking, higher-level protocols are then run through the L2TP tunnel. To facilitate this, an L2TP session (or 'call') is established within the tunnel for each higher-level protocol such as PPP. Either the LAC or LNS may initiate sessions. The traffic for each session is isolated by L2TP, so it is possible to set up multiple virtual networks across a single tunnel. MTU should be considered when implementing L2TP.

The packets exchanged within an L2TP tunnel are categorized as either control packets or data packets. L2TP provides reliability features for the control packets, but no reliability for data packets. Reliability, if desired, must be provided by the nested protocols running within each session of the L2TP tunnel.

L2TP packet structure

An L2TP packet consists of :
Bits 0–15                          Bits 16–31
Flags and Version Info     Length (opt)
Tunnel ID                        Session ID
Ns (opt)                           Nr (opt)
Offset Size (opt)             Offset Pad (opt)......
Payload data

Field meanings:

Flags and version
    control flags indicating data/control packet and presence of length, sequence, and offset fields.
Length (optional)
    Total length of the message in bytes, present only when length flag is set.
Tunnel ID
    Indicates the identifier for the control connection.
Session ID
    Indicates the identifier for a session within a tunnel.
Ns (optional)
    sequence number for this data or control message, beginning at zero and incrementing by one (modulo 216) for each message sent. Present only when sequence flag set.
Nr (optional)
    sequence number for expected message to be received. Nr is set to the Ns of the last in-order message received plus one (modulo 216). In data messages, Nr is reserved and, if present (as indicated by the S bit), MUST be ignored upon receipt..
Offset Size (optional)
    Specifies where payload data is located past the L2TP header. If the offset field is present, the L2TP header ends after the last byte of the offset padding. This field exists if the offset flag is set.
Offset Pad (optional)
    Variable length, as specified by the offset size. Contents of this field are undefined.
Payload data
    Variable length (Max payload size = Max size of UDP packet − size of L2TP header)

UT-VPN

University of Tsukuba Virtual Private Network, UT-VPN is a free and open source software application that implements virtual private network (VPN) techniques for creating secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. It uses SSL/TLS security for encryption and is capable of traversing network address translators (NATs) and firewalls. It was written by Daiyuu Nobori and SoftEther Corporation, and is published under the GNU General Public License (GPL) by University of Tsukuba.

UT-VPN has compatible as PacketiX VPN product of SoftEther Corporation. UT-VPN developed based on PacketiX VPN, but some functions was deleted. For example, the RADIUS client is supported by PacketiX VPN Server, but it is not supported by UT-VPN Server.

Encryption

UT-VPN uses the OpenSSL library to provide encryption to packets.

Authentication

UT-VPN offers username/password-based authentication.

Networking

UT-VPN is software to consist of UT-VPN Server and UT-VPN Client. UT-VPN functions as L2-VPN (over SSL/TLS).

UT-VPN Client

'Virtual NIC' (virtual network interface card) is installed in OS how UT-VPN Client was installed in. Virtual NIC is recognized as physical NIC by OS. UT-VPN does encapsulation to TCP (or SSL/TLS) packets from L2 frames by Virtual NIC.

UT-VPN Client connects with UT-VPN Server. If authorization with UT-VPN Server succeeded, UT-VPN Client establishes connection with Virtual HUB.

UT-VPN Server

UT-VPN Server have some 'Virtual HUB', and they function as virtual L2 switch. Virtual HUB does handle frames which received from UT-VPN Client. If necessary, UT-VPN Server forwards encapuslated L2 frames to UT-VPN Client. Virtual HUB on UT-VPN Server has function cascading connection for Virtual HUB on other UT-VPN Server. Site-to-site connection can come true with cascading connection.

L2 Bridge

UT-VPN Server has bridging function between arbitrary NIC which OS has and virtual HUB.

L3 Switch

UT-VPN Server has Virtual L3 switch function. Virtual L3 switch does L3-switching between virtual HUB on the UT-VPN Server.

Split tunneling

Split tunneling

 is a computer networking concept which allows a VPN user to access a public network (e.g., the Internet) and a local LAN or WAN at the same time, using the same physical network connection. This connection service is usually facilitated through a program such as a VPN client software application.

For example, suppose a user utilizes a remote access VPN software client connecting to a corporate network using a hotel wireless network. The user with split tunneling enabled is able to connect to file servers, database servers, mail servers and other servers on the corporate network through the VPN connection. When the user connects to Internet resources (Web sites, FTP sites, etc.), the connection request goes directly out the gateway provided by the hotel network.

Advantages

One advantage of using split tunneling is that it alleviates bottlenecks and conserves bandwidth as Internet traffic does not have to pass through the VPN server.
Another advantage is in the case where a user works at a supplier or partner site and needs access to network resources on both networks throughout the day. Split-tunneling prevents the user from having to continually connect and disconnect.

Disadvantages

A disadvantage is that when split tunneling is enabled, users bypass gateway level security that might be in place within the company infrastructure. For example, if web or content filtering is in place, this is something usually controlled at a gateway level, not the client PC.

ISPs that implement DNS hijacking break name resolution of private addresses with a split tunnel.

Open VPN

OpenVPN

is an open source software application that implements virtual private network (VPN) techniques for creating secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. It uses a custom security protocol[2] that utilizes SSL/TLS for key exchange. It is capable of traversing network address translators (NATs) and firewalls. It was written by James Yonan and is published under the GNU General Public License (GPL).[3]

OpenVPN allows peers to authenticate each other using a pre-shared secret key, certificates, or username/password. When used in a multiclient-server configuration, it allows the server to release an authentication certificate for every client, using signature and Certificate authority. It uses the OpenSSL encryption library extensively, as well as the SSLv3/TLSv1 protocol, and contains many security and control features.

Encryption :

OpenVPN uses the OpenSSL library to provide encryption of both the data and control channels. It lets OpenSSL do all the encryption and authentication work, allowing OpenVPN to use all the ciphers available in the OpenSSL package. It can also use the HMAC packet authentication feature to add an additional layer of security to the connection (referred to as an "HMAC Firewall" by the creator). It can also use hardware acceleration to get better encryption performance.[4][5] Support for PolarSSL is coming in version 2.3

Authentication

OpenVPN has several ways to authenticate peers to each another. OpenVPN offers pre-shared keys, certificate-based, and username/password-based authentication. Preshared secret key is the easiest, with certificate based being the most robust and feature-rich. In version 2.0 username/password authentications can be enabled, both with or without certificates. However to make use of username/password authentications, OpenVPN depends on third-party modules. See the Extensibility paragraph for more info.

Networking

OpenVPN can run over User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) transports, multiplexing created SSL tunnels on a single TCP/UDP port[6] (RFC 3948 for UDP).[7] It has the ability to work through most proxy servers (including HTTP) and is good at working through Network address translation (NAT) and getting out through firewalls. The server configuration has the ability to "push" certain network configuration options to the clients. These include IP addresses, routing commands, and a few connection options. OpenVPN offers two types of interfaces for networking via the Universal TUN/TAP driver. It can create either a layer-3 based IP tunnel (TUN), or a layer-2 based Ethernet TAP that can carry any type of Ethernet traffic. OpenVPN can optionally use the LZO compression library to compress the data stream. Port 1194 is the official IANA assigned port number for OpenVPN. Newer versions of the program now default to that port. A feature in the 2.0 version allows for one process to manage several simultaneous tunnels, as opposed to the original "one tunnel per process" restriction on the 1.x series.

OpenVPN's use of common network protocols (TCP and UDP) makes it a desirable alternative to IPsec in situations where an ISP may block specific VPN protocols in order to force users to subscribe to a higher-priced, "business grade," service tier.

VPNs in mobile environments

Mobile VPNs are used in a setting where an endpoint of the VPN is not fixed to a single IP address, but instead roams across various networks such as data networks from cellular carriers or between multiple Wi-Fi access points.[20] Mobile VPNs have been widely used in public safety, where they give law enforcement officers access to mission-critical applications, such as computer-assisted dispatch and criminal databases, while they travel between different subnets of a mobile network.[21] They are also used in field service management and by healthcare organizations,[22] among other industries.

Increasingly, mobile VPNs are being adopted by mobile professionals and white-collar workers who need reliable connections.[22] They are used for roaming seamlessly across networks and in and out of wireless-coverage areas without losing application sessions or dropping the secure VPN session. A conventional VPN cannot survive such events because the network tunnel is disrupted, causing applications to disconnect, time out,[20] or fail, or even cause the computing device itself to crash.[22]

Instead of logically tying the endpoint of the network tunnel to the physical IP address, each tunnel is bound to a permanently associated IP address at the device. The mobile VPN software handles the necessary network authentication and maintains the network sessions in a manner transparent to the application and the user.[20] The Host Identity Protocol (HIP), under study by the Internet Engineering Task Force, is designed to support mobility of hosts by separating the role of IP addresses for host identification from their locator functionality in an IP network. With HIP a mobile host maintains its logical connections established via the host identity identifier while associating with different IP addresses when roaming between access networks.

Trusted delivery networks

Trusted VPNs do not use cryptographic tunneling, and instead rely on the security of a single provider's network to protect the traffic.

    Multi-Protocol Label Switching (MPLS) is often used to overlay VPNs, often with quality-of-service control over a trusted delivery network.

    Layer 2 Tunneling Protocol (L2TP)[17] which is a standards-based replacement, and a compromise taking the good features from each, for two proprietary VPN protocols: Cisco's Layer 2 Forwarding (L2F)[18] (obsolete as of 2009) and Microsoft's Point-to-Point Tunneling Protocol (PPTP).[19]

From the security standpoint, VPNs either trust the underlying delivery network, or must enforce security with mechanisms in the VPN itself. Unless the trusted delivery network runs among physically secure sites only, both trusted and secure models need an authentication mechanism for users to gain access to the VPN.

VPN Routing

Routing

Tunneling protocols can operate in a point-to-point network topology that would theoretically not be considered a VPN, because a VPN by definition is expected to support arbitrary and changing sets of network nodes. But since most router implementations support a software-defined tunnel interface, customer-provisioned VPNs often are simply defined tunnels running conventional routing protocols.
PPVPN building-blocks

Depending on whether the PPVPN (Provider Provisioned VPN) runs in layer 2 or layer 3, the building blocks described below may be L2 only, L3 only, or combine them both. Multiprotocol label switching (MPLS) functionality blurs the L2-L3 identity.

RFC 4026 generalized the following terms to cover L2 and L3 VPNs, but they were introduced in RFC 2547.[11] More information on the devices below can also be found in [12].

Customer (C) devices

A device that is within a customer's network and not directly connected to the service provider's network. C devices are not aware of the VPN.

Customer Edge device (CE)

A device at the edge of the customer's network which provides access to the PPVPN. Sometimes it's just a demarcation point between provider and customer responsibility. Other providers allow customers to configure it.

Provider edge device (PE)

A PE is a device, or set of devices, at the edge of the provider network which connects to customer networks through CE devices and present the provider's view of the customer site. PEs are aware of the VPNs that connect through them, and maintain VPN state.

Provider device (P)

A P device operates inside the provider's core network and does not directly interface to any customer endpoint. It might, for example, provide routing for many provider-operated tunnels that belong to different customers' PPVPNs. While the P device is a key part of implementing PPVPNs, it is not itself VPN-aware and does not maintain VPN state. Its principal role is allowing the service provider to scale its PPVPN offerings, for example, by acting as an aggregation point for multiple PEs. P-to-P connections, in such a role, often are high-capacity optical links between major locations of providers.
User-visible PPVPN services

This section deals with the types of VPN considered in the IETF; some historical names were replaced by these terms.
OSI Layer 1 services
Virtual private wire and private line services (VPWS and VPLS)

In both of these services, the service provider does not offer a full routed or bridged network, but provides components to build customer-administered networks. VPWS are point-to-point while VPLS can be point-to-multipoint. They can be Layer 1 emulated circuits with no data link .

The customer determines the overall customer VPN service, which also can involve routing, bridging, or host network elements. An unfortunate acronym confusion can occur between Virtual Private Line Service and Virtual Private LAN Service; the context should make it clear whether "VPLS" means the layer 1 virtual private line or the layer 2
OSI Layer 2 services

Virtual LAN

A Layer 2 technique that allows for the coexistence of multiple LAN broadcast domains, interconnected via trunks using the IEEE 802.1Q trunking protocol. Other trunking protocols have been used but have become obsolete, including Inter-Switch Link (ISL), IEEE 802.10 (originally a security protocol but a subset was introduced for trunking), and ATM LAN Emulation (LANE).

Virtual private LAN service (VPLS)

Developed by IEEE, VLANs allow multiple tagged LANs to share common trunking. VLANs frequently comprise only customer-owned facilities. Whereas VPLS as described in the above section (OSI Layer 1 services) supports emulation of both point-to-point and point-to-multipoint topologies, the method discussed here extends Layer 2 technologies such as 802.1d and 802.1q LAN trunking to run over transports such as Metro Ethernet.

As used in this context, a VPLS is a Layer 2 PPVPN, rather than a private line, emulating the full functionality of a traditional local area network (LAN). From a user standpoint, a VPLS makes it possible to interconnect several LAN segments over a packet-switched, or optical, provider core; a core transparent to the user, making the remote LAN segments behave as one single LAN.[13]

In a VPLS, the provider network emulates a learning bridge, which optionally may include VLAN service.

Pseudo wire (PW)

PW is similar to VPWS, but it can provide different L2 protocols at both ends. Typically, its interface is a WAN protocol such as Asynchronous Transfer Mode or Frame Relay. In contrast, when aiming to provide the appearance of a LAN contiguous between two or more locations, the Virtual Private LAN service or IPLS would be appropriate.

IP-only LAN-like service (IPLS)

A subset of VPLS, the CE devices must have L3 capabilities; the IPLS presents packets rather than frames. It may support IPv4 or IPv6.
OSI Layer 3 PPVPN architectures

This section discusses the main architectures for PPVPNs, one where the PE disambiguates duplicate addresses in a single routing instance, and the other, virtual router, in which the PE contains a virtual router instance per VPN. The former approach, and its variants, have gained the most attention.

One of the challenges of PPVPNs involves different customers using the same address space, especially the IPv4 private address space.[14] The provider must be able to disambiguate overlapping addresses in the multiple customers' PPVPNs.

BGP/MPLS PPVPN

In the method defined by RFC 2547, BGP extensions advertise routes in the IPv4 VPN address family, which are of the form of 12-byte strings, beginning with an 8-byte Route Distinguisher (RD) and ending with a 4-byte IPv4 address. RDs disambiguate otherwise duplicate addresses in the same PE.

PEs understand the topology of each VPN, which are interconnected with MPLS tunnels, either directly or via P routers. In MPLS terminology, the P routers are Label Switch Routers without awareness of VPNs.

Virtual router PPVPN

The Virtual Router architecture,[15][16] as opposed to BGP/MPLS techniques, requires no modification to existing routing protocols such as BGP. By the provisioning of logically independent routing domains, the customer operating a VPN is completely responsible for the address space. In the various MPLS tunnels, the different PPVPNs are disambiguated by their label, but do not need routing distinguishers.
Plaintext tunnels
Main article: Tunneling protocol

Some virtual networks may not use encryption to protect the data contents. While VPNs often provide security, an unencrypted overlay network does not neatly fit within the secure or trusted categorization. For example a tunnel set up between two hosts that used Generic Routing Encapsulation (GRE) would in fact be a virtual private network, but neither secure nor trusted.

Besides the GRE example above, native plaintext tunneling protocols include Layer 2 Tunneling Protocol (L2TP) when it is set up without IPsec and Point-to-Point Tunneling Protocol (PPTP) or Microsoft Point-to-Point Encryption (MPPE).
Trusted delivery networks

Trusted VPNs do not use cryptographic tunneling, and instead rely on the security of a single provider's network to protect the traffic.

    Multi-Protocol Label Switching (MPLS) is often used to overlay VPNs, often with quality-of-service control over a trusted delivery network.

    Layer 2 Tunneling Protocol (L2TP)[17] which is a standards-based replacement, and a compromise taking the good features from each, for two proprietary VPN protocols: Cisco's Layer 2 Forwarding (L2F)[18] (obsolete as of 2009) and Microsoft's Point-to-Point Tunneling Protocol (PPTP).[19]

From the security standpoint, VPNs either trust the underlying delivery network, or must enforce security with mechanisms in the VPN itself. Unless the trusted delivery network runs among physically secure sites only, both trusted and secure models need an authentication mechanism for users to gain access to the VPN.