This sort of thing, as useful as it is, also presents certain kinds of risks. Most of these will provide the presenter, or the host, the ability to shift control from one user to another. This opens up a commanding control channel through which the person given this ability is now able to manipulate the virtual mouse, the virtual screen, the virtual keyboard, to do the presentation, but it also allows an open channel for malware to travel, or to retain control by planting an agent on the distant system from which the meeting is being run.

One of our favorites is, of course, instant messaging. No faster way to get to another person than by sending them a text message. Over time, many statistics have been published to tell the story that instant messaging is done far more, orders of magnitude more often, than actual voice calls these days. Typically, these are presented to the public in three forms. We have peer-to-peer networks, we have brokered communications, or we have server networks. Now, all three of these support basic chat type services on a one-to-one basis, and frequently enable us to do many-to-many. 

One form is, of course, Internet Relay Chat. Now, this is a client/server-based network, and historically this has been a favorite channel for hackers to use for their own communications, sending the traffic wrapped in a Tor (The Onion Router) encrypted network. 

As a native protocol, IRC is unencrypted and as you can imagine all of these different things present risks through its use. We have our VPNs that come in many forms and this is the most common kind of secured network connection; being something of a general name for them. This is, of course, the encrypted tunnel that exists between two hosts. The tunnel itself can be seen because the packets that travel through the VPN are wrapped in an encrypting wrapper, but they themselves are visible. The payload within each packet, however, is, of course, concealed by the encryption wrapper.

Now, remote users are often required to employ VPNs to access their organization's network securely and ensure the traffic that travels between them is kept from unauthorized access. Depending upon the VPN's implementation, they may have most of the same resources available to them as if they were in, physically, in the office. 

One very common one that is built into virtually every Windows desktop, be it on a laptop or a fixed station within Macintosh and others in Linux, is Point-to-Point Tunneling Protocol. This runs a tunneling protocol and encapsulates others. It relies on GRE to build the tunnel between the endpoints. But PPTP natively does not provide any authentication. It allows for the addition of IPSec for that purpose and is compatible with the IPSec suite. It is based on Point-to-Point Protocol, so when authentication is present, it's done through PAP (Password Authentication Protocol), CHAP (the Challenge Handshake Authentication Protocol), and EAP (the Extensible Authentication Protocol).

We have Layer 2 Tunneling Protocol, which is made up of a combination of Layer 2 Forwarding - L2F - and PPTP. This is, as PPTP is, it's a tunneled protocol that runs over others, and it, too, relies on GRE to build the tunnel between the endpoints, but it runs at a lower level. We have, of course, a preferred suite of protocols known as IPSec. This allows us to set up various kinds of various strongly encrypted communications with internet protocol. Within IPSec are the mechanisms for authentication and encryption. 

Now, the implementation of IPv6 requires that IPSec functionality also be installed, whether or not the IPSec is actively being used. But IPv6, as I mentioned earlier, was designed and built to integrate smoothly with IPSec from the beginning. Many organizations have made the switch from IPv4 to IPSec because of its enhanced features, both for security purposes and simple performance. 

Now, IPSec is a very complete kind of protocol suite. Its encryption and other protection methods use security associations, a security parameter index, an authentication header, and the encapsulation security payload to provide the various security services we need and to communicate both ends so that they can set up compatible tunnels.

Now, some of the attributes are going to have to be established at one end and then shared with the other. Through the security association, it establishes the shared security attributes between these two entities to support the secure communications. The security association on the one end, shared with the other end, will set up compatible cryptographic algorithms and modes, the traffic encryption key, and parameters for the network data to be passed over the connection so that both ends are working compatibly together.

In conjunction with the Security Association, is the Security Parameter Index. This is an identification tag added to the header while using IPSec for tunneling the IP traffic. It helps the kernel decern between two traffic streams where different encryption rules and algorithms may be in use.

Now, the Authentication Header is a fundamental part of the IPSec suite. This is the integrity check value. It employs a hash and a secret key embedded in the Authentication Header algorithm. It guarantees, thus, the data's origin by authenticating the packets. It can also add a sequence number to protect the IPSec's packet's contents against replay attacks. In IPv4, AH prevents option-insertion attacks. In IPv6, it goes further: Authentication Header protects against both header insertion attacks and option insertion attacks.

Now, in IPv4, AH protects the IP payload and all the header fields of the datagram except for the mutable fields which, of course, change as it travels. In IPv6, Authentication Header protects most of the IPv6 base header, AH itself, non-mutable extension headers after the AH and the IP payload. As with IPv4, IPv6 headers exclude protection of the mutable fields so that they change freely as needed as they're routed through the network.

Now, as mentioned, the AH is the authentication integrity feature that is on the packet. It doesn't provide the encryption to protect against unauthorized disclosure of content. To get that feature, we have to add Encapsulating Security Payload (ESP) and that means that it will modify the header by inserting these fields: that ESP is on, that it is in ESP payload, there has to be an ESP trailer along with it, and it reinforces the Authentication function.

Now, when it comes to the protection of data in transit, we have multiple types that can be used, some of which can be used with others. We have the the Link Encryption based on symmetric encryption. This encrypts the entire original packet between hops and that's an important distinction: between hops. When it reaches one of the hops, the packet itself is decrypted so that routing decisions can be made at the hop and then it is re-encrypted and sent on its way. This is typically done by the service providers for their own needs and reasons.

We have Tunnel Encryption which is also based on symmetric encryption. This is a point-to-point encryption of the entire packet. It encrypts at the external interface at the origin and is decrypted at the external interface at the destination before it enters the target network. Examples of this are our classic VPN, IPSec, SSH, and SSL. Then we have Transport Encryption which can be based on either symmetric or asymmetric encryption, depending. This is end-to-end of content only, such as we get with secure email. It is done at the desktops by senders and then, of course, undone by the receiver's point. As such, the Link Encryption and Tunnel Encryption provide wrappers for the entire original packet, which means, in each case, headers and trailers must be added as part of the wrapper while the original packet in its entirety, including headers and trailers and content, are all forming the payload of the wrapping packet. And Transport Encryption, we leave the original headers and trailers in the clear to provide routing from source to destination and encrypt only the content.

To make any of these happen, we have to have a way of getting encryption active and compatible at both ends. We have to have Internet Key Exchange that handles this process. One device will generate a symmetric key. Through IKE, it uses the Diffie-Hellman public key algorithm to do the negotiation and key exchange. The assurance of the public key is, of course, supplied by the digital certificate that accompanies the algorithm. It can be used in either AH or ESP mode, and certificates should be used to make sure each end is authentic to the other end.

In cases where even more security is required, High Assurance Internet Protocol Encryptor can be used. This uses Preplaced Keys or Firefly vectors to create VPNs. That way, any traffic passing along the network, before the VPN is actually set up, will be utterly useful because these keys are packaged before the devices are sent out. In the PPKs, the keys are never visible. The Firefly vectors will call them up and activate the tunnel so that the tunnel is created without the keys ever passing over the open network.

All of these network types have to have management. An SNMP is a common tool that is used for doing this, unless you're working with a proprietary tool from somebody like Cisco or Palo Alto. We have SNMP currently in version three which is the most secure of the three currently available versions. It's designed as a straight forward and relatively simple tool to manage our common IP networks. The structure uses a management server and a client as a point from which we will manage the network infrastructure and its operation.

Now remote-access services will make use of a variety of protocols. These, of course, should be ideally encrypted for the traffic to go across the unknown or untrusted network between the source and destination. Some of the protocols in use might be Telnet or rlogin, RCP or RSH. Now, each one of these has its pluses and minuses, but for them to be used passing sensitive traffic such as commands or data, manipulating applications, and so forth across the open connections, they should be encased within a VPN type of tunnel to ensure there are no open connections, but they are in fact protected by symmetric encrypt. In these remote access scenarios, we have to have Virtual Network Terminal Services so that the remote access to server resources can be done and mapped directly to a desktop that is compatible with the end user's environment.

The world is much more involved with telecommuting than at any other time in the past, but if we're going to institute a program of telecommuting or remote worker or work from home or whatever name you know it by, there are some questions we need to ask because we need to characterize and quantify the risk that is associated with this. Is the user trained to use the secure connectivity software and methods such as a VPN? The point of this question is, if the user is able to use this properly then we should be able to trust that the protocols and the services they implement and activate when they attach remotely to our host-based resources. Then there should be reduced risk or no risk because it's being operated correctly.

This can raise the specter of what training is necessary and how can this possibly go wrong? And then to explore ways to make sure that it doesn't. Does the user know which information is sensitive or valuable and why someone might wish to steal or modify it? This question is based around the notion that the user needs to understand what they're working with so that they have an understanding and truly have an appreciation for what could go wrong if the information was to fall into unauthorized hands.

This can reinforce the policy that we typically have where a user cannot walk away and leave a work station logged on. Whether they're in a client station, a remote office of the same company, or their hotel room. Another question is, is the user's physical location appropriately secure for the type of work and the type of information they are using? It reinforces the answers to the previous question. Just because it's a hotel room doesn't mean that someone won't be able to get in and see what you have on your screen if you're not there doing it, watching it, securing it yourself. Just because it's your hotel room and it's only the cleaning crew that might be there, it is still something that you need to follow through in the policy, and that is: lock it before you walk away, log it off, lock it to your table or your desk in your hotel room with a cable lock. And so those of us who are asking these questions need to be aware of those conditions and recommend or actually provide cable locks as part of the remote user's kit. Because this raises the specter of, who else has access to the area?

If you're out of your hotel room, whether you're at your client's location or down at the pool, you don't know who else might go in. It might be the cleaning crew, but it might be someone else. And it's not a question of being paranoid, it is a question of following the established policy and playing it safe. Doing what is right to protect the information.

Now, we have a number of different ways, with a number of different features associated with them, for giving us the different kinds of access. We have DSL, Digital Subscriber Line services that can range from 256 kbits/s to 20 Mbits/s. We have ADSL, we have SDSL, and about another half dozen types. These are part of a family of naked protocols meaning that they're, none of them, encrypted. And so we have to add encryption to protect that. This is a common protocol that is used to deliver high-speed internet to houses. We have cable modem; another very popular, very commonly used protocol to deliver this to homes. It is also a naked protocol. This uses a form of video type of compression to deliver signal, but, as a naked protocol, it means that this traffic could be sniffed by your neighbors because this is traveling over a shared medium. So we need to always be aware of what kind of traffic we're sending. Again, not to be paranoid but to follow policy and make sure we play it safe, and simply do it and not have to worry.

Now, on all of these various types, we have a couple of different types of carrier sense. We have Carrier Sense Multiple Access that comes in two forms: Collision Avoidance, typically at OSI Layer 2 protocol, known as Token Ring, and Carrier Sense Multiple Access with Collision Detection, also an OSI Layer 2 protocol. It uses carrier sensing to defer transmissions when it appears that the coast is clear, so to speak, whereas Carrier Sense Multiple Access Collision Avoidance uses a token so that, as the traffic is being sent, those that have the token typically have the right of way to send their traffic, and others wait.