OSI model

OSI model
From Wikipedia,
Joris de Leeuw GTAgames Nederland

OSI Model
7 Application layer
6 Presentation layer
5 Session layer
4 Transport layer
3 Network layer
2 Data link layer
1 Physical layer

The Open Systems Interconnection Basic Reference Model (OSI Reference Model or OSI Model for short) is a layered, abstract description for communications and computer network protocol design, developed as part of the Open Systems Interconnection (OSI) initiative. It is also called the OSI seven layer model. The layers, described below, are, from top to bottom, Application, Presentation, Session, Transport, Network, Data Link, and Physical. A layer is a collection of related functions that provides services to the layer above it and receives service from the layer below it. For example, a layer that provides error-free communications across a network provides the path needed by applications above it, while it calls the next lower layer to send and receive packets that make up the contents of the path.

Even though newer IETF and IEEE protocols, and indeed OSI protocol work subsequent to the publication of the original architectural standards that have largely superseded it, the OSI model is an excellent place to begin the study of network architecture. Not understanding that the pure seven-layer model is more historic than current, many beginners make the mistake of trying to fit every protocol they study into one of the seven basic layers. This is not always easy to do as many of the protocols in use on the Internet today were designed as part of the TCP/IP model, and may not fit cleanly into the OSI model.


History
In 1977, work on a layered model of network architecture, which was to become the OSI model, started in the American National Standards Institute (ANSI) working group on Distributed Systems (DISY).[1] With the DISY work and worldwide input, the International Organization for Standardization (ISO) began to develop its OSI networking suite.[2] According to (Bachman), the term "OSI" came into use on 12 October 1979. OSI has two major components: an abstract model of networking (the Basic Reference Model, or seven-layer model) and a set of concrete protocols. The standard documents that describe OSI are for sale and not currently available online.

Parts of OSI have influenced Internet protocol development, but none more than the abstract model itself, documented in ISO 7498 and its various addenda. In this model, a networking system is divided into layers. Within each layer, one or more entities implement its functionality. Each entity interacts directly only with the layer immediately beneath it, and provides facilities for use by the layer above it.

In particular, Internet protocols are deliberately not as rigorously architected as the OSI model, but a common version of the TCP/IP model splits it into four layers. The Internet Application Layer includes the OSI Application Layer, Presentation Layer, and most of the Session Layer. Its End-to-End Layer includes the graceful close function of the OSI Session Layer as well as the Transport Layer. Its Internetwork Layer is equivalent to the OSI Network Layer, while its Interface layer includes the OSI Data Link and Physical Layers. These comparisons are based on the original seven-layer protocol model as defined in ISO 7498, rather than refinements in such things as the Internal Organization of the Network Layer document.

Protocols enable an entity in one host to interact with a corresponding entity at the same layer in a remote host. Service definitions abstractly describe the functionality provided to an (N)-layer by an (N-1) layer, where N is one of the seven layers inside the local host.

Create VPN Client for WindowsXP

WindowsXP VPN Client

Easy to create a WindowsXP VPN Client


1.Click to Start / Control Panel / Network Connections
2.Double Click the Create a new Connection
3.Next and Select Connect to the network at my workplace



4.Click on the Next button
5.Click on Virtual Private Network connection



6.Click on the Next button
7.Give the Connection a Name




8.Click on the Next button
9.If prompted, select whether or not you need to dial to the Internet before establishing a VPN connection.



10.Enter in the IP address of the server you want to connect to. This needs to be the external WAN IP address :Public IP Address that is being used by the VPN Server. Not the LAN IP address of the VPN server.




11.Check whether you want to have an icon placed on the desktop and click on the Finish button.

Create VPN Server for WindowsXP

Easy to create a WindowsXP VPN Server

1. Click to Start / control panel / Network Connections
2. Start the Create a New Connection



3. Click on the Next button
4. Select Set up advanced connection



5. Click on the Next button.
6. Click on Accept incoming connections



7. Click on the Next button
8. At the LPT1 page, skip it and just click on the Next button.



9. Click on Allow virtual private connection



10. Click on the Next button
11. Add user accounts that you want to be able to connect to your WindowsXP computer.



12. Click on the Next button.
13. Highlight Internet Protocol (TCP/IP) and click on Properties



14. Determine how you want the remote computers to get their IP address



***If the VPN server is behind a router, Port Mapping or port forward will need to be done on the router. Standard port usage is 1723 for PPTP and 1701 for l2tp. You might also need to configure your router for PPTP Passthrough. Port usage for IPSec is 500, 50-51. These ports will have to be forwarded to the VPN server's IP ***

http://VPNFarm.blogspot.com

OSI and TCP/IP Layering Differences

From Wikipedia
Jakub Dziwior

OSI and TCP/IP Layering Differences

The three top layers in the OSI model - the application layer, the presentation layer and the session layer - usually are lumped into one layer in the TCP/IP model. While some pure OSI protocol applications, such as X.400, also lumped them together, there is no requirement that a TCP/IP protocol stack needs to be monolithic above the transport layer. For example, the Network File System (NFS) application protocol runs over the eXternal Data Representation (XDR) presentation protocol, which, in turn, runs over a protocol with session layer functionality, Remote Procedure Call (RPC). RPC provides reliable record transmission, so it can run safely over the best-effort User Datagram Protocol (UDP) transport.

The session layer roughly corresponds to the Telnet virtual terminal functionality, which is part of text based protocols such as HTTP and SMTP TCP/IP model application layer protocols. It also corresponds to TCP and UDP port numbering, which is considered as part of the transport layer in the TCP/IP model. The presentation layer has similarities to the MIME standard, which also is used in HTTP and SMTP.





Since the IETF protocol development effort is not concerned with strict layering, some of its protocols may not appear to fit cleanly into the OSI model. These conflicts, however, are more frequent when one only looks at the original OSI model, ISO 7498, without looking at the annexes to this model (e.g., ISO 7498/4 Management Framework), or the ISO 8648 Internal Organization of the Network Layer (IONL). When the IONL and Management Framework documents are considered, the ICMP and IGMP are neatly defined as layer management protocols for the network layer. In like manner, the IONL provides a structure for "subnetwork dependent convergence facilities" such as ARP and RARP.

IETF protocols can be applied recursively, as demonstrated by tunneling protocols such as Generic Routing Encapsulation (GRE). While basic OSI documents do not consider tunneling, there is some concept of tunneling in yet another extension to the OSI architecture, specifically the transport layer gateways within the International Standardized Profile framework [8]. The associated OSI development effort, however, has been abandoned given the real-world adoption of TCP/IP protocols.

Layers in the TCP/IP model

From Wikipedia
Alan Isherwoo


Layers in the TCP/IP model

The layers near the top are logically closer to the user application (as opposed to the human user), while those near the bottom are logically closer to the physical transmission of the data. Viewing layers as providing or consuming a service is a method of abstraction to isolate upper layer protocols from the nitty gritty detail of transmitting bits over, say, Ethernet and collision detection, while the lower layers avoid having to know the details of each and every application and its protocol.
IP suite stack showing the physical network connection of two hosts via two routers and the corresponding layers used at each hop. The dotted line represents a virtual connection
Sample encapsulation of data within a UDP datagram within an IP packet

This abstraction also allows upper layers to provide services that the lower layers cannot, or choose not to, provide. Again, the original OSI Reference Model was extended to include connectionless services (OSIRM CL).[5] For example, IP is not designed to be reliable and is a best effort delivery protocol. This means that all transport layers must choose whether or not to provide reliability and to what degree. UDP provides data integrity (via a checksum) but does not guarantee delivery; TCP provides both data integrity and delivery guarantee (by retransmitting until the receiver receives the packet).

This model lacks the formalism of the OSI Reference Model and associated documents, but the IETF does not use a formal model and does not consider this a limitation, as in the comment by David D. Clark, "We don't believe in kings, presidents, or voting. We believe in rough consensus and running code." Criticisms of this model, which have been made with respect to the OSI Reference Model, often do not consider ISO's later extensions to that model.

For multiaccess links with their own addressing systems (e.g. Ethernet) an address mapping protocol is needed. Such protocols can be considered to be below IP but above the existing link system. While the IETF does not use the terminology, this is a subnetwork dependent convergence facility according to an extension to the OSI model, the Internal Organization of the Network Layer (IONL) [6].
ICMP & IGMP operate on top of IP but do not transport data like UDP or TCP. Again, this functionality exists as layer management extensions to the OSI model, in its Management Framework (OSIRM MF) [7]
The SSL/TLS library operates above the transport layer (utilizes TCP) but below application protocols. Again, there was no intention, on the part of the designers of these protocols, to comply with OSI architecture.
The link is treated like a black box here. This is fine for discussing IP (since the whole point of IP is it will run over virtually anything). The IETF explicitly does not intend to discuss transmission systems, which is a less academic but practical alternative to the OSI Reference Model.

Key Architectural Principles

From Wikipedia
Alan Isherwoo
Key Architectural Principles

An early architectural document, RFC 1122, emphasizes architectural principles over layering.

End-to-End Principle: This principle has evolved over time. Its original expression put the maintenance of state and overall intelligence at the edges, and assumed the Internet that connected the edges retained no state and concentrated on speed and simplicity. Real-world needs for firewalls, network address translators, web content caches and the like have forced changes in this Principle. [3]
Robustness Principle: "Be liberal in what you accept, and conservative in what you send. Software on other hosts may contain deficiencies that make it unwise to exploit legal but obscure protocol features".
Even when layer is examined, the assorted architectural documents -- there is no single architectural model such as ISO 7498, the OSI Reference Model -- have fewer, less rigidly defined layers than the commonly referenced OSI model, and thus provides an easier fit for real-world protocols. In point of fact, one frequently referenced document does not contain a stack of layers. The lack of emphasis on layering is a strong difference between the IETF and OSI approaches. It only refers to the existence of the "internetworking layer" and generally to "upper layers"; this document was intended as a 1996 "snapshot" of the architecture: "The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture."

No document officially specifies the model, another reason to deemphasize the emphasis on layering. Different names are given to the layers by different documents, and different numbers of layers are shown by different documents.

There are versions of this model with four layers and with five [citation needed] layers. RFC 1122 on Host Requirements makes general reference to layering, but refers to many other architectural principles not emphasizing layering. It loosely defines a four-layer version, with the layers having names, not numbers, as

Process Layer or Application Layer: this is where the "higher level" protocols such as SMTP, FTP, SSH, HTTP, etc. operate.
Host-To-Host (Transport) Layer: this is where flow-control and connection protocols exist, such as TCP. This layer deals with opening and maintaining connections, ensuring that packets are in fact received.
Internet or Internetworking Layer: this layer defines IP addresses, with many routing schemes for navigating packets from one IP address to another.
Network Access Layer: this layer describes both the protocols (i.e., the OSI Data Link Layer) used to mediate access to shared media, and the physical protocols and technologies necessary for communications from individual hosts to a medium.
The Internet protocol suite (and corresponding protocol stack), and its layering model, were in use before the OSI model was established. Since then, the TCP/IP model has been compared with the OSI model numerous times in books and classrooms. In a popular textbook, which is a secondary source,[4] but not primary IETF specifications, the model has evolved into a five-layer version that splits the network access layer into a Physical layer and a Network Access layer, corresponding to the physical layer and data link layer of the OSI model. The Internet or Internetworking layer corresponds to the OSI Network layer

TCP/IP model

From Wikipedia
Anon


The TCP/IP model or Internet reference model, sometimes called the DoD model (DoD, Department of Defense) ARPANET reference model, is a layered abstract description for communications and computer network protocol design. It was created in the 1970s by DARPA for use in developing the Internet's protocols, and the structure of the Internet is still closely reflected by the TCP/IP model.

The original TCP/IP reference model consists of 4 layers, but has according to some authors evolved into a 5-layer model, where the lowest layer (the network access layer) is split into a physical layer and a datalink layer. However, no IETF standards-track document has accepted a five-layer model, probably since physical layer and data link layer protocols are not standardized by IETF. IETF documents deprecate strict layering of all sorts. Given the lack of acceptance of the five-layer model by the body with technical responsibility for the protocol suite, it is not unreasonable to regard five-layer presentations as teaching aids, making it possible to talk about non-IETF protocols at the physical layer.

This model was developed before the OSI Reference Model, and the Internet Engineering Task Force (IETF), which is responsible for the model and protocols developed under it, has never felt obligated to be compliant with OSI. While the basic OSI model is widely used in teaching, OSI, as presented as a seven-layer model, does not reflect real-world protocol architecture (RFC 1122) as used in the dominant Internet environment.

An updated IETF architectural document even contains a section entitled: "Layering Considered Harmful". Emphasizing layering as the key driver of architecture is not a feature of the TCP/IP model, but rather of OSI. Much confusion comes from attempts to force OSI-like layering onto an architecture that minimizes their use.

Point-to-point tunneling protocol : PPTP

From Wikimedia
Kiminori Noma

Point-to-point tunneling protocol
PPTP specification
A specification for PPTP was published as RFC 2637. PPTP has not been proposed or ratified as a standard by the IETF.

PPTP works by sending a regular PPP session to the peer with the Generic Routing Encapsulation (GRE) protocol. A second session on TCP port 1723 is used to initiate and manage the GRE session. PPTP is difficult to forward past a network firewall because it requires two network sessions.

PPTP connections are authenticated with Microsoft MSCHAP-v2 or EAP-TLS. VPN traffic is optionally protected by MPPE encryption, which is described by RFC 3078.

MSCHAP-v2 can be compromised if users choose weak passwords. The certificate-based EAP-TLS provides a superior security option for PPTP.


PPTP implementations
Cisco first implemented PPTP and later licensed the technology to Microsoft.

PPTP is popular because it is easy to configure and it 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. The Routing And Remote Access Service for Microsoft Windows contains a PPTP server.

Until recently, Linux distributions lacked full PPTP support because MPPE was believed to be patent encumbered. Full MPPE support was added to the Linux 2.6.13 branch that is maintained by Andrew Morton. SuSE Linux 10 was the first Linux distribution to provide a complete working PPTP client. Official support for PPTP was added to the official kernel release in version 2.6.14 on October 28, 2005.

Mac OS X (including the version loaded on the iPhone) is 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.

Microsoft Windows Mobile 2003 and higher also support the PPTP protocol.


PPTP security concerns
"Security concerns have dogged PPTP since its inception. It is the author’s opinion that PPTP is inherently insecure because there are too many unauthenticated control packets that are readily spoofed."[2]


PPTP upgrade path
The upgrade path for PPTP on Microsoft platforms will be to either L2TP/IPsec or IPsec. The adoption of improved VPN technologies has been slow because PPTP is convenient and easy to configure, whereas L2TP/IPsec requires a shared key or machine certificates. It is possible however on Cisco devices to configure the VPN server (on a PIX firewall or similar) to authenticate via a RADIUS server. This means it is possible to deploy a PPTP style dialup solution but using IPSec, without having to use a shared key or certificates as users can use their own usernames and passwords.

IPsec

From Wikimedia change the world :
Cameron Knight

IPsec (IP security) is a suite of protocols for securing Internet Protocol (IP) communications by authenticating and/or encrypting each IP packet in a data stream. IPsec also includes protocols for cryptographic key establishment.

Summary
IPsec protocols operate at the network layer, layer 3 of the OSI model. Other Internet security protocols in widespread use, such as SSL, TLS and SSH, operate from the transport layer up (OSI layers 4 - 7). This makes IPsec more flexible, as it can be used for protecting layer 4 protocols, including both TCP and UDP, the most commonly used transport layer protocols. IPsec has an advantage over SSL and other methods that operate at higher layers. For an application to use IPsec no code change in the applications is required whereas to use SSL and other higher level protocols, applications must undergo code changes.

Security architecture
IPsec is implemented by a set of cryptographic protocols for (1) securing packet flows, (2) mutual authentication and (3) establishing cryptographic parameters.

The IP security architecture uses the concept of a security association as the basis for building security functions into IP. A security association is simply the bundle of algorithms and parameters (such as keys) that is being used to encrypt and authenticate a particular flow in one direction. Therefore, in normal bi-directional traffic, the flows are secured by a pair of security associations. The actual choice of encryption and authentication algorithms (from a defined list) is left to the IPsec administrator.

In order to decide what protection is to be provided for an outgoing packet, IPsec uses the security parameter index (SPI), an index to the security association database (SADB), along with the destination address in a packet header, which together uniquely identify a security association for that packet. A similar procedure is performed for an incoming packet, where IPsec gathers decryption and verification keys from the security association database.

For multicast, a security association is provided for the group, and is duplicated across all authorized receivers of the group. There may be more than one security association for a group, using different SPIs, thereby allowing multiple levels and sets of security within a group. Indeed, each sender can have multiple security associations, allowing authentication, since a receiver can only know that someone knowing the keys sent the data. Note that the relevant standard does not describe how the association is chosen and duplicated across the group; it is assumed that a responsible party will have made the choice.


Current status as a standard
IPsec is a mandatory part of IPv6, and is optional for use with IPv4. While the standard is designed to be indifferent to IP versions, current widespread deployment and experience concerns IPv4 implementations.

IPsec protocols were originally defined by RFCs 1825–1829, published in 1995. In 1998, these documents were obsoleted by RFCs 2401–2412, which are not compatible with 1825–1829, although they are conceptually identical. In December 2005, third-generation documents, RFCs 4301–4309, were produced. They are largely a superset of 2401–2412, but provide a second Internet Key Exchange standard. These third-generation documents standardized the abbreviation of IPsec to uppercase “IP” and lowercase “sec”.

It is unusual to see any product that offers RFC1825–1829 support. “ESP” generally refers to 2406, while ESPbis refers to 4303.


Design intent
IPsec was intended to provide either transport mode (end-to-end) security of packet traffic in which the end-point computers do the security processing, or tunnel mode (portal-to-portal) communications security in which security of packet traffic is provided to several machines (even to whole LANs) by a single node.

IPsec can be used to create Virtual Private Networks (VPN) in either mode, and this is the dominant use. Note, however, that the security implications are quite different between the two operational modes.

End-to-end communication security on an Internet-wide scale has been slower to develop than many had expected. Part of the reason is that no universal, or universally trusted, Public Key Infrastructure (PKI) has emerged (DNSSEC was originally envisioned for this); another part is that many users understand neither their needs nor the available options well enough to promote inclusion in vendors' products.

Since the Internet Protocol does not inherently provide any security capabilities, IPsec was introduced to provide security services such as the following:

Encrypting traffic (so it cannot be read by parties other than those for whom it is intended)
Integrity validation (ensuring traffic has not been modified along its path)
Authenticating the peers (ensuring that traffic is from a trusted party)
Anti-replay (protecting against replay of the secure session).

Modes
There are two modes of IPsec operation: transport mode and tunnel mode.


Transport mode
In transport mode, only the payload (the data you transfer) of the IP packet is encrypted and/or authenticated. The routing is intact, since the IP header is neither modified nor encrypted; however, when the authentication header is used, the IP addresses cannot be translated, as this will invalidate the hash value. The transport and application layers are always secured by hash, so they cannot be modified in any way (for example by translating the port numbers). Transport mode is used for host-to-host communications.

A means to encapsulate IPsec messages for NAT traversal has been defined by RFC documents describing the NAT-T mechanism.


Tunnel mode
In tunnel mode, the entire IP packet (data plus the message headers) is encrypted and/or authenticated. It must then be encapsulated into a new IP packet for routing to work. Tunnel mode is used for network-to-network communications (secure tunnels between routers) or host-to-network and host-to-host communications over the Internet.


Technical details
Two protocols have been developed to provide packet-level security for both IPv4 and IPv6:

The IP Authentication Header provides integrity and authentication and non-repudiation, if the appropriate choice of cryptographic algorithms is made.
The IP Encapsulating Security Payload provides confidentiality, along with optional (but strongly recommended) authentication and integrity protection.
Cryptographic algorithms defined for use with IPsec include HMAC-SHA1 for integrity protection, and TripleDES-CBC and AES-CBC for confidentiality. Refer to RFC 4305 for details.


Authentication header (AH)
The AH is intended to guarantee connectionless integrity and data origin authentication of IP datagrams. Further, it can optionally protect against replay attacks by using the sliding window technique and discarding old packets. AH protects the IP payload and all header fields of an IP datagram except for mutable fields, i.e. those that might be altered in transit. In IPv4, mutable (and therefore unauthenticated) IP header fields include TOS, Flags, Fragment Offset, TTL and Header Checksum. AH operates directly on top of IP, using IP protocol number 51. An AH packet diagram:

Field meanings:

Next header
Identifies the protocol of the transferred data.
Payload length
Size of AH packet.
RESERVED
Reserved for future use (all zero until then).
Security parameters index (SPI)
Identifies the security parameters, which, in combination with the IP address, then identify the security association implemented with this packet.
Sequence number
A monotonically increasing number, used to prevent replay attacks.
Authentication data
Contains the integrity check value (ICV) necessary to authenticate the packet; it may contain padding.

Encapsulating Security Payload (ESP)
The ESP protocol provides origin authenticity, integrity, and confidentiality protection of a packet. ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is strongly discouraged because it is insecure.[1] [2] [3]. Unlike AH , the IP packet header is not protected by ESP. (Although in tunnel mode ESP, protection is afforded to the whole inner IP packet, including the inner header; the outer header remains unprotected.) ESP operates directly on top of IP, using IP protocol number 50.

An ESP packet diagram:

Field meanings:

Security parameters index (SPI)
Identifies the security parameters in combination with IP address.
Sequence number
A monotonically increasing number, used to prevent replay attacks.
Payload data
The data to be transferred.
Padding
Used with some block ciphers to pad the data to the full length of a block.
Pad length
Size of padding in bytes.
Next header
Identifies the protocol of the transferred data.
Authentication data
Contains the data used to authenticate the packet.

Implementations
IPsec support is usually implemented in the kernel with key management and ISAKMP/IKE negotiation carried out from user-space. Existing IPsec implementations tend to include both of these functionalities. However, as there is a standard interface for key management, it is possible to control one kernel IPsec stack using key management tools from a different implementation.

Because of this, there is confusion as to the origins of the IPsec implementation that is in the Linux kernel. The FreeS/WAN project made the first complete and open source implementation of IPsec for Linux. It consists of a kernel IPsec stack (KLIPS), as well as a key management daemon (pluto) and many shell scripts. The FreeS/WAN project was disbanded in March 2004. Openswan and strongSwan are continuations of FreeS/WAN. The KAME project also implemented complete IPsec support for NetBSD, FreeBSD. Its key management daemon is called racoon. OpenBSD made its own ISAKMP/IKE daemon, simply named isakmpd (which was also ported to other systems, including Linux).

However, none of these kernel IPsec stacks were integrated into the Linux kernel. Alexey Kuznetsov and David S. Miller wrote a kernel IPsec implementation from scratch for the Linux kernel around the end of 2002. This stack was subsequently released as part of Linux 2.6, and is referred to variously as "native" or "NETKEY".

Therefore, contrary to popular belief, the Linux IPsec stack did not originate from the KAME project. As it supports the standard PF_KEY protocol (RFC 2367) and the native XFRM interface for key management, the Linux IPsec stack can be used in conjunction with either pluto from Openswan/strongSwan, isakmpd from OpenBSD project, racoon from the KAME project or without any ISAKMP/IKE daemon (using manual keying).

The new architectures of network processors, including multi-core processors with integrated encryption engines, change the way the IPsec stacks are designed. A dedicated Fast Path is used in order to offload the processing of the IPsec processing (SA, SP lookups, encryption, etc.). These Fast Path stacks must be co-integrated on dedicated cores with Linux or RTOS running on other cores. These OS are the control plane that runs ISAKMP/IKE of the Fast Path IPsec stack.

There are a number of implementations of IPsec and ISAKMP/IKE protocols. These include:

6WINDGate, Network processor MPU Fast Path IPsec stack
NRL [1] IPsec, one of the original sources of IPsec code [2]
OpenBSD, with its own code derived from NRL IPsec
the KAME stack, that is included in Mac OS X, NetBSD and FreeBSD
"IPsec" in Cisco IOS Software [3]
"IPsec" in Microsoft Windows, including Windows XP[4] [5], Windows 2000[6], and Windows 2003[7]
SafeNet QuickSec toolkits [8]
IPsec in Solaris [9]
IBM AIX operating system
IBM z/OS
IPsec and IKE in HP-UX (HP-UX IPSec)
"IPsec and IKE" in VxWorks [10]

Layer 2 Tunneling Protocol : L2TP

From Wikipedia,
Jordan Leonen

In computer networking, the Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual private networks (VPNs).

History and future
Published in 1999 as proposed standard RFC 2661, L2TP has its origins primarily in two older tunneling protocols for PPP: Cisco's Layer 2 Forwarding (L2F) and Microsoft's 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
L2TP acts like a data link layer (layer 2 of the OSI model) protocol for tunneling network traffic between two peers over an existing network (usually the Internet). L2TP is in fact a layer 5 protocol session layer, and uses the registered UDP port 1701. The entire L2TP packet, including payload and L2TP header, is sent within a 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 categorised 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. Cisco has the software patent related to L2F and L2TP [1]. It has been assigned U.S. Patent 5,918,019 in the United States.

Tunneling Models
An L2TP tunnel can extend across an entire PPP session or only across one segment of a two-segment session. This can be represented by four different tunneling models, namely [2] [3] [4]
voluntary tunnel compulsory tunnel — incoming call compulsory tunnel — remote dial and L2TP multi-hop connection In the voluntary tunnel model, a tunnel is created by the user, typically by the use of an L2TP enabled client which is called the LAC client. The user will send L2TP packets to the Internet Service Provider (ISP) which will forward them on to the LNS. The ISP does not need to support L2TP, it only forwards the L2TP packets between LAC and LNS. The LAC client acts as an L2TP tunnel initiator which effectively resides on the same system as the remote client. The tunnel extends across the entire PPP session from the L2TP client to the LNS.
In the compulsory tunnel model-incoming call, a tunnel is created between ISP LAC and the LNS home gateway. The company may provide the remote user with a Virtual Private Network (VPN) login account from which he can access the corporate server. As a result the user will send PPP packets to the ISP (LAC) which will encapsulate them in L2TP and tunnel them to the LNS. In the compulsory tunneling cases, the ISP must be L2TP capable. In this model the tunnel only extends across the segment of the PPP session between the ISP and the LNS.
In the compulsory tunnel model-remote dial the home gateway (LNS) initiates a tunnel to an ISP (LAC) (outgoing call) and instructs the ISP to place a local call to the PPP enabled client which is the remote user. This model is intended for cases where the remote PPP Answer Client has a permanently established phone number with an ISP. This model is expected to be used when a company with established presence on the Internet needs to establish a connection to a remote office that requires a dial-up link. In this model the tunnel only extends across the segment of the PPP session between the LNS and the ISP.
An L2TP Multi-hop connection is a way of redirecting L2TP traffic on behalf of client LACs and LNSs. A Multi-hop connection is established using an L2TP Multi-hop gateway. A tunnel is established from a client LAC to the L2TP Multi-hop gateway and then another tunnel is established between the L2TP Multi-hop gateway and a target LNS. L2TP traffic between client LAC and LNS is redirected to each other through the gateway.

L2TP Packet Structure
An L2TP packet consists of :
0 - 15 bit 16 - 31 bit 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, 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 2**16) 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 2**16). 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 Actual data within the offset padding is undefined. 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 Payload data Variable length (Max payload size = Max size of UDP packet - size of L2TP header)

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 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

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." Tunnel refers to a channel which allows untouched packets of one network to be transported over another network. In the case of L2TP/IPsec, 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 in ADSL networks
L2TP is often used as a tunneling mechanism to resell ADSL endpoint connectivity. An L2TP tunnel would sit between the user and the ISP the connection would be resold to, so the reselling ISP wouldn't appear as doing the transport

What Makes a Virtual Private Network Private?

What Makes a Virtual Private Network Private?
from webopedia


Using a public network, usually the Internet, to connect securely to a private network, such as a company's network is the basis of a VPN or virtual private network. Companies and organizations will use a VPN to communicate confidentially over a public network and can be used to send voice, video or data. It's an excellent option for remote workers and organizations with global offices and partners to share data in a private manner.

One of the most common types of VPNs is a virtual private dial-up network (VPDN). A VPDN is a user-to-LAN connection, where remote users need to connect to the company LAN. Here the company will have a service provider set-up a NAS (network access server) and provide the remote users with the software needed to reach the NAS from their desktop computer or laptop. For a VPDN, the secure and encrypted connection between the company's network and remote users is provided by the third-party service provider.

Another type of VPN is commonly called a site-to-site VPN. Here the company would invest in dedicated hardware to connect multiple sites to their LAN though a public network, usually the Internet. Site-to-site VPNs are either intranet or extranet-based.

intranet
A network based on TCP/IP protocols (an intranet) belonging to an organization, usually a corporation, accessible only by the organization's members, employees or others with authorization. Secure intranets are now the fastest-growing segment of the Internet because they are much less expensive to build and manage than private networks based on proprietary protocols.

extranet
An extranet refers to an intranet that is partially accessible to authorized outsiders. Whereas an intranet resides behind a firewall and is accessible only to people who are members of the same company or organization, an extranet provides various levels of accessibility to outsiders. You can access an extranet only if you have a valid username and password, and your identity determines which parts of the extranet you can view. Extranets are becoming a popular means for business partners to exchange information.

Other options for using a VPN include such things as using dedicated private leased lines. Due to the high cost of dedicated lines, however, VPNs have become an attractive cost-effective solution.
Securing a VPN
If you're using a public line to connect to a private network, then you might wonder what makes a virtual private network private? The answer is the manner in which the VPN is designed. A VPN is designed to provides a secure, encrypted tunnel in which to transmit the data between the remote user and the company network. The information transmitted between the two locations via the encrypted tunnel cannot be read by anyone else.

VPN security contains several elements to secure both the company's private network and the outside network, usually the Internet, through which the remote user connects through. The first step to security is usually a firewall. You will have a firewall site between the client (which is the remote users workstation) and the host server, which is the connection point to the private network. The remote user will establish an authenticated connection with the firewall.

Encryption
Encryption is also an important component of a secure VPN. Encryption works by having all data sent from one computer encrypted in such a way that only the computer it is sending to can decrypt the data. Types of encryption commonly used include public-key encryption which is a system that uses two keys — a public key known to everyone and a private or secret key known only to the recipient of the message. The other commonly used encryption system is a Symmetric-key encryption system in which the sender and receiver of a message share a single, common key that is used to encrypt and decrypt the message.

VPN Tunneling
With a VPN you'll need to establish a network connection that is based on the idea of tunneling. There are two main types of tunneling used in virtual private networks. Voluntary tunneling is where the client makes a connection to the service provider then the VPN client creates the tunnel to the VPN server once the connection has been made. In compulsory tunneling the service provider manages the VPN connection and brokers the connection between that client and a VPN server.

There are three main network protocols for use with VPN tunnels, which are generally incompatible with each other. They include the following:

IPSec
A set of protocols developed by the IETF to support secure exchange of packets at the IP layer. IPsec has been deployed widely to implement VPNs. IPsec supports two encryption modes: Transport and Tunnel. Transport mode encrypts only the data portion (payload) of each packet, but leaves the header untouched. The more secure Tunnel mode encrypts both the header and the payload. On the receiving side, an IPSec-compliant device decrypts each packet. For IPsec to work, the sending and receiving devices must share a public key. This is accomplished through a protocol known as Internet Security Association and Key Management Protocol/Oakley (ISAKMP/Oakley), which allows the receiver to obtain a public key and authenticate the sender using digital certificates.

PPTP
Short for Point-to-Point Tunneling Protocol, a new technology for creating VPNs, developed jointly by Microsoft, U.S. Robotics and several remote access vendor companies, known collectively as the PPTP Forum. A VPN is a private network of computers that uses the public Internet to connect some nodes. Because the Internet is essentially an open network, PPTP is used to ensure that messages transmitted from one VPN node to another are secure. With PPTP, users can dial in to their corporate network via the Internet.

L2TP
Short for Layer Two (2) Tunneling Protocol, an extension to the PPP protocol that enables ISPs to operate Virtual Private Networks (VPNs). L2TP merges the best features of two other tunneling protocols: PPTP from Microsoft and L2F from Cisco Systems. Like PPTP, L2TP requires that the ISP's routers support the protocol.

VPN Equipment
Depending on the type of VPN you decide to implement, either remote-access or site-to-site, you will need specific components to build your VPN. These standard components include a software client for each remote workstation, dedicated hardware, such as a firewall or a product like the Cisco VPN Concentrator, a VPN server, and a Network Access Server (NAS).

What is VPN?

Virtual private network
From Wikipedia,

A virtual private network (VPN) is a communications network tunneled through another network, and dedicated for a specific network. One common application is secure communications through the public Internet, but a VPN need not have explicit security features, such as authentication or content encryption. VPNs, for example, can be used to separate the traffic of different user communities over an underlying network with strong security features.


A VPN may have best-effort performance, or may have a defined Service Level Agreement (SLA) between the VPN customer and the VPN service provider. Generally, a VPN has a topology more complex than point-to-point. The distinguishing characteristic of VPNs are not security or performance, but that they overlay other network(s) to provide a certain functionality that is meaningful to a user community.


Business Case for Using VPN
Attractions of VPNs to enterprises include:

Shared facilities may be cheaper-- especially in capital expenditure (CAPEX)-- than traditional routed networks over dedicated facilities.
Can rapidly link enterprise offices, as well as small-and-home-office and mobile workers.
Allow customization of security and quality of service as needed for specific applications.
Can scale to meet sudden demands, especially when provider-provisioned on shared infrastructure.
Can reduce operational expenditure (OPEX) by outsourcing support and facilities.
Distributing VPNs to homes, telecommuters, and small offices may put access to sensitive information in facilities not as well protected as more traditional facilities. VPNs need to be designed and operated under well-thought-out security policies. Organizations using them must have clear security rules supported by top management. When access goes beyond traditional office facilities, where there may be no professional administrators, security must be maintained as transparently as possible to end users.

Some organizations with especially sensitive data, such as health care companies, even arrange for an employee's home to have two separate WAN connections: one for working on that employer's sensitive data and one for all other uses.[citation needed] More common is that bringing up the secure VPN cuts off Internet connectivity for any use except secure communications into the enterprise; Internet access is still possible but will go through enterprise access rather than that of the local user.

In situations in which a company or individual has legal obligations to keep information confidential, there may be legal problems, even criminal ones, as a result. Two examples are the HIPAA regulations in the U.S. with regard to health data, and the more general European Union data privacy regulations which apply to even marketing and billing information and extend to those who share that data elsewhere.


Categorizing VPNs by User Administrative Relationships
The Internet Engineering Task Force (IETF) categorized a variety of VPNs, some of which, such as Virtual LANs (VLAN) are the standardization responsibility of other organizations, such as the Institute of Electrical and Electronics Engineers (IEEE) Project 802, Workgroup 802.1 (architecture). Originally, network nodes within a single enterprise were interconnected with Wide Area Network (WAN) links from a telecommunications service provider. With the advent of LANs, enterprises could interconnect their nodes with links that they owned. While the original WANs used dedicated lines and layer 2 multiplexed services such as Frame Relay, IP-based layer 3 networks, such as the ARPANET, Internet, military IP networks (NIPRNET,SIPRNET,JWICS, etc.), became common interconnection media. VPNs began to be defined over IP networks [1]. The military networks may themselves be implemented as VPNs on common transmission equipment, but with separate encryption and perhaps routers.

It became useful first to distinguish among different kinds of IP VPN based on the administrative relationships, not the technology, interconnecting the nodes. Once the relationships were defined, different technologies could be used, depending on requirements such as security and quality of service.

When an enterprise interconnected a set of nodes, all under its administrative control, through an IP network, that was termed an Intranet [2]. When the interconnected nodes were under multiple administrative authorities, but were hidden from the public Internet, the resulting set of nodes was called an extranet. Both intranets and extranets could be managed by a user organization, or the service could be obtained as a contracted offering, usually customized, from an IP service provider. In the latter case, the user organization contracted for layer 3 services much as it had contracted for layer 1 services such as dedicated lines, or multiplexed layer 2 services such as frame relay.

The IETF distinguishes between provider-provisioned and customer-provisioned VPNs [3]. Much as conventional WAN services can be provided by an interconnected set of providers, provider-provisioned VPNs (PPVPNs) can be provided by a single service provider that presents a common point of contact to the user organization.


VPNs and Routing
Tunneling protocols can be used in a point-to-point topology that would generally not be considered a VPN, because a VPN is accepted to support arbitrary and changing sets of network nodes. Since most router implementations support software-defined tunnel interface, customer-provisioned VPNs are often simply a set of tunnels over which conventional routing protocols run. PPVPNs, however, need to support the coexistence of multiple VPNs, hidden from one another, but operated by the same service provider.


Building Blocks
Depending on whether the PPVPN is layer 2 or layer 3, the building blocks described below may be L2 only, L3 only, or combinations of the two. MPLS functionality blurs the L2-L3 identity.

While these terms were generalized to cover L2 and L3 VPNs in RFC 4026, they were introduced in [4].


Customer Edge Device (CE)
In general, a CE is a device, physically at the customer premises, that provides access to the PPVPN service. Some implementations treat it purely as a demarcation point between provider and customer responsibility, while others allow it to be a customer-configurable device.


Provider Edge Device (PE)
A PE is a device or set of devices, at the edge of the provider network, which provides the provider's view of the customer site. PEs are aware of the VPNs that connect through them, and do maintain VPN state.


Provider Device (P)
A P device is inside the provider's core network, and does not directly interface to any customer endpoint. It might, for example, be used to 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, as, 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 provider.


User-Visible PPVPN Services
This section deals with the types of VPN currently considered active in the IETF; some historical names were replaced by these terms.


Layer 1 Services

Virtual Private Wire and Private Line Services (VPWS and VPLS)
In both of these services, the provider does not offer a full routed or bridged network, but components from which the customer can 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 structure.

It is the customer that determines the overall customer VPN service, which can involve routing, bridging, or host network elements.

There is an unfortunate acronym collision between Virtual Private Line Service and Virtual Private LAN Service; the context should make it clear whether the layer 1 virtual private line or the layer 2 virtual private LAN is meant.


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 are 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 are composed only of customer-owned facilities. The former is a layer 1 technology that supports emulation of both point-to-point and point-to-multipoint topologies. The method discussed here is an extension of Layer 2 technologies such as 802.1d and 802.1q LAN trunking, extended to run over transports such as Metro Ethernet.

As used in this context rather than private line, a VPLS is a Layer 2 PPVPN that emulates the full functionality of a traditional Local Area Network (LAN). From the user standpoint, VPLS makes it possible to interconnect several LAN segments over a packet-switched or optical provider core, a core transparent to the customer, and makes the remote LAN segments behave as one single LAN.

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 ATM or Frame Relay. In contrast, when the goal is to provide the appearance of a LAN contiguous between two or more location, 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.


L3 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 is that different customers may use the same address space, especially the IPv4 private address space[5]. 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 are used to 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 [6], 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.

Virtual router architectures do not need to disambiguate addresses, because rather than a PE router having awareness of all the PPVPNs, the PE contains multiple virtual router instances, which belong to one and only one VPN.


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

Some ISPs now offer managed VPN service for business customers who want the security and convenience of a VPN but prefer not to undertake administering a VPN server themselves. Managed VPNs go beyond PPVPN scope, and are a contracted security solution that can reach into hosts. In addition to providing remote workers with secure access to their employer's internal network, other security and management services are sometimes included as part of the package. Examples include keeping anti-virus and anti-spyware programs updated on each client's computer.


Authentication before VPN Connection
A known trusted user, sometimes only when using trusted devices, can be provided with appropriate security privileges to access resources not available to general users. Servers may also need to authenticate themselves to join the VPN.

There are a wide variety of authentication mechanisms, which may be implemented in devices including firewalls, access gateways, and other devices. They may use passwords, biometrics, or cryptographic methods. Strong authentication involves using at least two authentication mechanisms. The authentication mechanism may require explicit user action, or may be embedded in the VPN client or the workstation.


Trusted Delivery Networks
Trusted VPNs (sometimes referred to APNs - Actual Private Networks)[citation needed] do not use cryptographic tunneling, and instead rely on the security of a single provider's network to protect the traffic. In a sense, these are an elaboration of traditional network and system administration work.

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)[7] 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) [8] (now obsolete) and Microsoft's Point-to-Point Tunneling Protocol (PPTP) [9].

Security mechanisms in the VPN
Secure VPNs use cryptographic tunneling protocols to provide the intended confidentiality (blocking snooping and thus Packet sniffing), sender authentication (blocking identity spoofing), and message integrity (blocking message alteration) to achieve privacy. When properly chosen, implemented, and used, such techniques can provide secure communications over unsecured networks.

Secure VPN protocols include the following:

IPsec (IP security) - commonly used over IPv4, and an obligatory part of IPv6.
SSL/TLS used either for tunneling the entire network stack, as in the OpenVPN project, or for securing what is, essentially, a web proxy. SSL is a framework more often associated with e-commerce, but it has been built-upon by a number of vendors to provide remote access VPN capabilities. A major practical advantage of an SSL-based VPN is that it can be accessed from the locations that restrict external access to SSL-based e-commerce websites only, thereby preventing VPN connectivity using IPsec protocols. SSL-based VPNs are vulnerable to trivial Denial of Service attacks mounted against their TCP connections because latter are inherently unauthenticated.
OpenVPN, an open standard VPN. It is a variation of SSL-based VPN that is capable of running over UDP. Clients and servers are available for all major operating systems.
L2TPv3 (Layer 2 Tunneling Protocol version 3), a new release.
VPN Quarantine The client machine at the end of a VPN could be a threat and a source of attack; this has no connection with VPN design and is usually left to system administration efforts. There are solutions that provide VPN Quarantine services which run end point checks on the remote client while the client is kept in a quarantine zone until healthy. Microsoft ISA Server 2004/2006 together with VPN-Q 2006 from Winfrasoft or an application called QSS (Quarantine Security Suite) provide this functionality.
MPVPN (Multi Path Virtual Private Network). MPVPN is a registered trademark owned by Ragula Systems Development Company. See Trademark Applications and Registrations Retrieval (TARR)

Security and Mobility
Mobile VPNs are VPNs designed for mobile and wireless users. They integrate standards-based authentication and encryption technologies to secure data transmissions to and from devices and to protect networks from unauthorized users. Designed for wireless environments, Mobile VPNs are designed as an access solution for users that are on the move and require secure access to information and applications over a variety of wired and wireless networks. Mobile VPNs allow users to roam seamlessly across IP-based networks and in and out of wireless coverage areas without losing application sessions or dropping the secure VPN session. For instance, highway patrol officers require access to mission-critical applications in order to perform their jobs as they travel across different subnets of a mobile network, much as a cellular radio has to hand off its link to repeaters at different cell towers.