A rchive Date
[ 28-08-2004 ]
Category
[ Information Technologies ]
sub-Categoy
[ Microsoft ]
|
[http://zdnet.com.com/2100-1105-5321783.html
NAT conflict introduced by SP2
By George Ou
ZDNet News
August 24, 2004, 6:50 AM PT
Based on an SP2 design decision, Microsoft refers to the anomaly as an expected change to the default behavior of Windows XP, which, prior to the update, allowed for L2TP-based connectivity to NAT-based servers.
NAT stands for Network Address Translation (NAT) and is present in virtually all home networks where the various workstations share a single IP address through a DSL modem-based connection using a residential gateway. To external systems, such as Web servers, all systems on NAT-based network have the same IP address--the one that is shared. When a system which is external to a NAT-based network (such as a Web server on the Internet) responds to a request from the shared IP address, NAT is the technology that figures out which of the systems sharing that IP address made the request, and routes to-and-fro traffic appropriately. Though it’s not common, Microsoft acknowledges that there are businesses which put VPN servers on NAT-based networks (informally referred to as “NAT’d” servers). It is in this scenario certain Windows XP workstations will lose their VPN connectivity once SP2 is applied. First hand reports of the problem are also beginning to surface in certain Internet forums.
The problem will primarily affect telecommuters and road warriors who occasionally work from home and whose machines are configured to connect to a VPN with L2TP.
In part due to its relationship to the IPsec protocol, L2TP (otherwise known as Layer 2 Tunneling Protocol) is a more secure VPN protocol than is Microsoft’s Point-to-Point Tunneling Protocol (PPTP), which is commonly used for VPN connectivity. As its name suggests, L2TP can support Layer 2 (and higher) connections, which makes it appropriate for WAN connections that require the support of non-routable protocols. PPTP is a Microsoft-specific VPN technology that’s not supported by the default configuration of some enterprise firewalls, whereas L2TP is an IETF standard (as is IPsec) that is more widely supported.
One reason that L2TP is looked upon as being more secure has to do with how authentication is not a pre-requisite for encrypted communications. With L2TP, the authentication process itself is protected by an encrypted tunnel--whereas, the same process via PPTP is considered less secure. Many companies that want a standard, vendor-neutral VPN protocol and secure networks while allowing access from outside the firewalls, will only permit L2TP VPNs as opposed to less secure PPTP connections. The differences between L2TP and PPTP are more thoroughly fleshed out in a document on Microsoft’s Web site. In a telephone interview, Microsoft’s Windows Network program manager Chris Mitchell told ZDNet that, as a VPN protocol, Microsoft considers PPTP to be non-strategic.
NAT-based networks haven’t always played well with L2TP and IPsec-based VPNs. In response, Microsoft has issued updates to “to enhance the current functionality of the Layer Two Tunneling Protocol (L2TP) and Internet Protocol security (IPSec) on computers that are running Windows XP or Windows 2000,” according to one update page on Microsoft’s Web site. This feature is commonly referred to as the “NAT-T” or “NAT Traversal” patch, which makes IPSec and L2TP play nice with NAT.
After confirming ZDNet’s tests which show how updating to SP2 negatively impacted L2TP-based VPN connectivity with NAT’d servers (essentially undoing the NAT-T patch), Mitchell said that Microsoft will add a document to its on-line knowledge base within the next couple of weeks that explains how to reset Windows XP to its pre-SP2 default behavior and the risks associated with that change.
The configuration change, which worked as advertised in our tests, requires the addition of a new key to Windows XP registry. According to Mitchell, the registry key that must be added is as follows (without the brackets):
[HKLM\System\CurrentControlSet\Services\IPSec\AssumeUDPEncapsulationContextOnSendRule = REG_DWORD].
The value data should be set to equal 2. In an e-mail, Mitchell noted that “You can reset the behavior to Default SP2 by changing the Value to “0”. A value of “1” will only enable a Client with a public (i.e.non-NAT’d) address to connect to a NAT’d server. The value of “2” enables both public and NAT’d clients to connect to a NAT’d server. The value of “2” is equal to the pre-SP2 behavior.
The key can be entered into the registry by a system’s user. But the preferred way is to push the change to the users who need it with Active Directory scripts or a third-party systems management tool.
In our discussions with Microsoft, officials were careful not to articulate this as a fix, nor the risks that go with it as a vulnerability. The risks, according to Mitchell, aren’t exactly known, which is why, in the name of security, Mitchell said he made the decision to change the default to a behavior that errs on the side of caution.
According to Microsoft, NAT introduces an additional layer of uncertainty (beyond that which is already there with non-NAT’d networks) over the fate of packets that are destined for a server connection that may have timed out. In L2TP-based VPN situations, the fate of such packets is largely irrelevant since their payload is encrypted (based on PKI, only the targeted system can decrypt them). Despite the irrelevance of that scenario, Mitchell claimed there are other scenarios that caused Microsoft to play it safe. Though Mitchell claims that such a scenario has never historically revealed a vulnerability, one of those scenarios has to do with unencrypted payload-bearing IPsec connections and the fate of packets when such a connection times out.]
Cross-Indexed:
|
|