Forum

Figure 13.8

I think the diagram on pg. 460 has the encrypted and clear text Ip addresses flipped because I have always knew that the tunnel interface address are the addresses that are left in clear text versus what is documented in figure 13.8. The text on the previous page actually states this. Am I wrong somewhere or am I not understanding something here?

You are correct. Tunnel endpoints must be in clear text. For example, in IPSec tunnel mode, we add a "new" header to the front of the packet containing endpoint information. Often, we are routing through a network that contains many routers, all of which need to examine the Layer 3 IP addressing information, prior to onpassing to the "next best router".

There is often confusion about the terms "tunnel" and VPN. Many different manufacturers etc will give different definitions. Usually a VPN involves tunneling securely over an inherently unsecure ( public ) network ( e.g. the Internet ).

In the days of dial-up PPP ( still present in many countries ), often little or no security was involved in the link between the user's modem and the NAS. This was due to the fact that tapping into the phone lines was regarded as being very difficult ( can still be done though ).

With IPSec in AH and tunnel mode ( rarely used ), no encryption is used at the IPSec "layer", although there may indeed be encryption at higher layers.

GRE ( Generic Routing Encapsulation ) was one of the first VPN protocols. It sort of died a death for a while and has now made a re-appearance in some places, due to it's ability to carry routing protocols etc.

PPP gave us PPTP, mainly from Microsoft, which can be thought of as an "application layer-ish" type sat on top of a transport protocol. At the same time, we had L2F from Cisco. The best of both "standards" were brought together by the IETF to give us L2TP.

IPSec is often used in conjunction with L2TP.

Like PPTP, L2TP has control channel establishment phases etc.

If we had our own leased lines ( rare nowadays ), and ran IPSec using ESP tunnel mode, would that be a VPN ? Some might call it one, but usually we have tunneling through a "public" network involved with a VPN. Terminology varies from one manufacturer/provider to another. Very often, some will slap the title "VPN capable" to just about anything !!

Also note the private IP address at the client. Tunneling can indeed assign private IP addresses from a NAS for example, and we can have tunnels within tunnels, but if we are going to route over the public Internet, a public IP address must be used.

The term "bundle" is often used in relation to SAs ( Security Associations ) and tunnels within tunnels

Dave

Thanks for the clarification on the subject. Reading these posts from people in these blogs are very helpful to further understand some of the subject in the books. This is the best free resource that I have ever had to prepare for an exam. I am working on my second take for the CWNA. The first test really fooled me. I did not study enough on the first time around but I am confident I will pass on the second attempt.

Thanks again!

You will often see the term "Diffie-Hellman Key Exchange" used in relation to VPNs. This incredible system allows the creation of secret keys across a public network. It is wrongly named, as the actual keys themselves are never sent across the network. Material that is used to create the actual keys themselves is exchanged, however. The public part is sent across the network, by both parties, and then the private component is used in conjunction with the public component to create an actual key.

However, like many terms in networking, "Key Exchange" has become "accepted", and so we all tend to use it.

Dave

I have studied Cisco text and various the authors gave me the impression that these keys were actually being sent across the wire when using DH. This must be a very complicated algorithm to be able to authenticate a peer with the material that is used to make the actual keys.

It is and it isn't. If you see the actual math used, it's not nearly as complex as many others, but like many things, the "simplicity" took a long time to actual "construct" or "think up". It is a very clever method.

We see a similar thing with 802.1X/4 way handshakes etc, where "key making" material is passed between parties, but the actual keys themselves are not.

Terminology can often cause confusion. For example, with EAPOL-Key frames. Usually an encrypted form of a key is sent ( e.g. the encrypted GTK key ). Although it would be perfectly acceptable for two proprietary STAs to exchange a "raw" key in the Key field, nobody would want to do that, as the golden rule is that you never send a "raw" or unencrypted key over an unsecure network.

The IKE ( Internet Key Exchange ) uses similar methods, using the best "bits and pieces" from the ISAKMP, Oakley, SKEME etc protocols.

It usually operates with Diffie-Hellman, although many other options are available.

Agreement of transforms and transform sets between end stations allows those points to agree on encryption, authentication methods etc.

In most documentation, you will see the Diffie-Hellman method referred to as a "Key Exchange Method". It isn't. It's a Key Agreement Method. However, like many things, we have to "go with the flow" and we nearly always end up referring to it as a Key Exchange Method, due to popular use.

Dave