Protocols, Protocols, and More Protocols!

Because the functions provided by a VPN include tunneling, data integrity, and authentication, it makes sense that a VPN is not created using a single protocol. Instead, several protocols can be used to create a VPN, each performing a particular function. In this section the following protocols are briefly examined:

• Internet Protocol Security (IPSec)
• Point-to-Point Tunneling Protocol (PPTP)
• Layer Two Tunneling Protocol (L2TP)

For the most part, only IPSec should be a major factor in VPNs in the coming years. PPTP was used by Windows NT 4.0 as part of its VPN package, and L2TP has replaced it in Windows 2000 and Windows XP VPNs. L2TP is basically just the PPTP protocol combined with the L2F protocol developed by Cisco. However, most VPN vendors are using the IPSec protocols instead, which are described in greater detail than PPTP and L2TP. The IPSec protocols incorporate some of the security mechanisms that were originally designed to be included in IPv6 but have been adapted for use in the existing IPv4 network.

Note

Before you adopt a particular VPN solution, you should determine if the connection will be used by PDAs, Pocket PCs, or smartphones. Many of these devices do not include integrated VPN support, but in some cases updates to the operating system or third-party software does provide this functionality as an additional feature. IPSec is the most common VPN protocol supported by hand-held devices.

IPSec Protocols

As noted previously, IPSec is the emerging standard being adopted by more and more VPN vendors. IPSec was derived from concepts that were originally designed to provide for secure communications in the next generation of the IP protocol, IPv6, which is gradually being developed.

Although Microsoft chooses to use L2TP and IPSec in combination as its VPN solution for Windows 2000 and Windows XP, many hardware and software vendors are sticking with a simple IPSec solution.

The good news is that if you decide on an all-IPSec solution, you can be virtually assured that equipment (or software) from one vendor to another will work together. If you have an all-Windows server environment, this might be of no concern. For those who operate multiprotocol networks, IPSec might be the best choice. As noted previously, IPSec is also the most widely supported VPN protocol on handheld devices.

IPSec is a standard defined in several Request for Comments (RFC) documents. IPSec is transparent to the end user and can traverse the Internet using standard IPv4 routers and other equipment without requiring any modification because it operates at the Network layer. IPSec is also flexible, allowing for the negotiation and use of many different encryption and authentication techniques.

The three main components of IPSec are the following:

• Internet Key Exchange (IKE)—This is the protocol defined in RFC 2048, "Internet Security Association and Key Management Protocol (ISAKMP)," which defines a method for the secure exchange of the initial encryption keys between the two endpoints of the VPN link.
• Authentication Header (AH)—This protocol, defined in RFC 1826, "The Authentication Header," provides for inserting a standard IPv4 header into an additional header that can be used to ensure the integrity of the header information and payload as the packet makes its way through the Internet. AH does not encrypt the actual IP payload data, but instead provides a mechanism to determine whether the payload or header has been tampered with.
• Encapsulating Security Payload (ESP)—This protocol performs the actual encryption of the data carried in the IP packet so that it cannot be understood by anyone who might intercept your data stream.

IPFullTrust Macro Code Walkthrough

To enable full trust, both the Manifest.xsf and Template.xml files must be modified. The IPFullTrust macro has a Manifest class and a Template class defined with methods and properties to make these modifications. Because Manifest.xsf and Template.xml are both XML files, the two classes inherit from the XmlDocument class in the System.Xml namespace of the .NET Framework Class Library. This facilitates modifications to the files.

The Manifest class contains the method, RemovePublishUrl. Because this class inherits from the XmlDocument class, this method simply needs to call RemoveAttribute, as follows:

Me.DocumentElement.RemoveAttribute("publishUrl")

The following lines of code in the AddRequireFullTrust method of the Manifest class add the requireFullTrust attribute:

fullTrustAttrib = Me.CreateAttribute("requireFullTrust") fullTrustAttrib.Value = "yes" Me.DocumentElement.Attributes.Append(fullTrustAttrib) 

The solutionName property of the Manifest class sets a valid URN, if one is not already set, as follows:

Try Me.DocumentElement.Attributes("name").Value = Value Catch nrex As System.NullReferenceException 'no name attribute found Me.DocumentElement.Attributes.Append(Me.CreateAttribute("name")) Me.DocumentElement.Attributes("name").Value = Value End Try 

The Template class defines the method, RemoveHrefAttribute. The URL for the form must be removed from Template.xml for a form to be fully trusted. This method parses out the URL from the InfoPath processing instruction and deletes it.

The IPFullTrust macro uses the Solution and Project objects of the Visual Studio .NET automation model to find any InfoPath projects in the current solution, in much the same way as the SignCode macro does:

For Each proj In DTE.Solution.Projects 'iterate through all projects If proj.Kind = IPProjectKind Then 

Once the code finds the InfoPath project, it passes the manifest file name to the constructor of the Manifest class. The class constructor does some basic checking to be sure read/write access to the file is available. If those checks pass, the code can call the object methods and set properties to make the required file modifications:

manifestProjItem = proj.ProjectItems.Item(ManifestFilename) projectManifest = New Manifest(manifestProjItem.FileNames(1)) projectManifest.RemovePublishUrl() projectManifest.AddRequireFullTrust() If Not validUrn(projectManifest.solutionName) Then ' create a valid urn if one is not present. projectManifest.solutionName = "urn:" + proj.Name + ":" + "-myXSD-" + DateTime.Now().ToString("s").Replace(":", "-") End If 

The code then moves on to the Template.xml file. Again, the Template class contains the functionality required to make the necessary changes to the file. The constructor for the Template class also makes the same checks to be sure read/write access is available. Just like the Manifest class, the Template class can call methods and set properties to make the required modifications:

'modify the template file templateProjItem = proj.ProjectItems.Item(TemplateFilename) projectTemplate = New Template(templateProjItem.FileNames(1)) projectTemplate.templateName = projectManifest.solutionName projectTemplate.RemoveHrefAttribute() 

Once the file modifications have been made, the project must be registered on the system. This is the final step in making an InfoPath form fully trusted. InfoPath exposes this functionality. Using COM automation, the RegisterSolution function of the IPFullTrust macro code calls the RegisterSolution method of the InfoPath object model to register the solution:

IPApp = CreateObject("InfoPath.Application") IPApp.RegisterSolution(solutionPath, "overwrite") IPApp.Quit() IPApp = Nothing 

This step completes the process, and your InfoPath project is now fully trusted.