Welcome Sign in
TechNet Magazine
Printer Friendly Version      Send     
Click to Rate and Give Feedback
Related Articles
Many organizations rely on ISA Server 2006 to secure their environment, but few take the important step of securing ISA Server itself. Here’s a guide to using the Security Configuration Wizard and Administrative roles to limit its attack surface and secure your ISA Server 2006 implementation.

By Alan Maddison (September 2008)
The recent update to the Windows Vista Firewall offers some impressive new features that make it a compelling choice for the corporate environment. Jesper M. Johansson gives a brief overview of the evolution of the Windows Firewall and delves into enhancements—such as new rules and profiles, domain isolation, and encryption—that will have administrators taking a closer look.

By Jesper M. Johansson (June 2008)
Troubleshooting enforcement behaviors in the Network Access Protection platform can be challenging. The Cable Guy explains how NAP health policy evaluation works and how you can troubleshoot the most common issues.

By Joseph Davies (April 2008)
How do you allow network access to those who need it without sacrificing security? See how new technologies in Windows Server 2008, such as Windows Firewall with Advanced Security and Network Access Protection, let you implement a policy-based approach to help you achieve this goal. Ian Hameroff and Amith Krishnan 62 Configuring Roles with Server Manager A DNS server need not be a print server. One approach Windows Server 2008 takes to improve security and manageability is to simplify server roles so you can easily install only the tools and services you need, and nothing more. Here's an introduction to using Server Manager for configuring roles and simplifying deployments.

By Ian Hameroff and Amith Krishnan (March 2008)
More ...
Articles by this Author
Troubleshooting enforcement behaviors in the Network Access Protection platform can be challenging. The Cable Guy explains how NAP health policy evaluation works and how you can troubleshoot the most common issues.

By Joseph Davies (April 2008)
Getting ready to move to IPv6? The Cable Guy explains how you can use an IPv6 transition technology to get IPv6 connectivity and migrate to an IPv6-capable intranet.

By Joseph Davies (March 2008)
IEEE 802.1X authentication provides an additional security barrier for access to your intranet. See how Windows Vista and Windows Server 2008 make it a snap to implement IEEE 802.1X authentication for your wired network.

By Joseph Davies (February 2008)
Windows Server 2008 includes many DNS server enhancements. Take a close look at how these updates make name resolution faster, improve support for IPv6, and add greater flexibility to DNS administration.

By Joseph Davies (January 2008)
The Network Policy Server (NPS) service in Windows Server 2008 replaces the Internet Authentication Service used in Windows Server 2003 and brings numerous enhancements, from the ability to enforce system health requirements to improved management capability.

By Joseph Davies (December 2007)
Single Sign On offers many advantages for both end users and administrators. Here's a look at how Single Sign On can simplify implementation of wireless authentication for your network.

By Joseph Davies (November 2007)
The Internet Key Exchange protocol and Authenticated Internet Protocol are both used to determine keying material and negotiate security parameters for IPsec-protected communications. Get an in-depth look at how they work.

By Joseph Davies (October 2007)
There's more to IPv6 than just extending the address space from 32 bits to 128 bits. Here's a look at how IPv6 hosts can automatically configure themselves, even without the use of an address configuration protocol.

By Joseph Davies (August 2007)
More ...
Popular Articles
When you want to reduce the total cost of ownership of the desktop machines in your organization, application lockdown can be a great help, letting you limit IT issues related to unsupported applications. See how you can use software restriction policies and Group Policy to control the applications being run throughout your IT infrastructure.

By Chris Corio and Durga Prasad Sayana (June 2008)
Many mobile professionals today need the line of business applications they use in the office (CRM, ERP, and the like) to be accessible from a mobile device when they are in the field. See how Windows Mobile and Mobile Device Manager allow you to deploy rich mobile functionality for critical line of business applications.

By Matt Fontaine (September 2008)
The key to successfully scaling an ASP.NET application is having a collaborative effort between developers and network administrators, starting at the beginning of the application’s lifecycle. Find out what factors are necessary to scale an application, and see how this collaboration can help ensure the application will run as intended.

By Richard Campbell (August 2008)
Michael Murgolo is back with an update to his Elevation PowerToys. You'll find enhanced Run as Administrator functionality that works with third-party scripting tools, a way to replace a handy Windows XP feature removed from Windows Vista, and many more useful tools.

By Michael Murgolo (June 2008)
More ...
Read the Blog
If you’re an OpsMgr 2007 administrator, chances are good that you’ll be creating custom monitoring objects (rules, groups, and so forth), and for each one you build, you have to decide what target to use. That’s a critical decision, but knowing how to go about choosing the correct target is not always clear. Steve ...
Read more!
The November 2008 issue of TechNet Magazine is now available online.   FEATURE ARTICLES                                                                   ...
Read more!
It's been about 8 years since Scott Culp published "The 10 Immutable Laws of Security." It is one of the best and most important essays on computer security ...
Read more!
As you might have guessed, October is virtualization month. TechNet Magazine is celebrating with a blockbuster issue,  there are launch events all over the country, and there are a slew of on-demand webcasts that let you explore the world of server virtualization. Here’s just ...
Read more!
As we've been discussing over the last few weeks, the latest issue of TechNet Magazine delves into the exciting new virtualization technologies now becoming available. But if an entire magazine worth of info just doesn't satisfy your appetite, get yourself to one of the Virtualization Launch ...
Read more!
Have you ever wished Windows PowerShell would launch with a work environment tailored to your specific needs? This is actually pretty easy to do. In the ...
Read more!
More ...
The Cable Guy Strong and Weak Host Models
Joseph Davies


An increasingly common configuration for network hosts is to be multihomed with multiple network interfaces. A multihomed host provides enhanced connectivity because it can be simultaneously connected to multiple networks, such as an intranet or the Internet. Because they can be connected to both an intranet and the
Internet, however, services running on multihomed hosts can be vulnerable to attack. In order to help prevent attack, and to get an idea of how IP traffic is processed for a multihomed host, I'm going to take a look at the weak and strong host models of multihomed hosts and then describe how these models are supported in Windows®.
RFC 1122 is the specification that describes the two models for a multihomed host that is not acting as a router and is only sending and receiving unicast IP traffic. These models, known as strong host and weak host, specify whether unicast traffic sent or received must be associated with the network interface on which the traffic travels. These models determine how a host sends and receives packets and impacts the vulnerability of the services running on the host.
Although RFC 1122 defines these models for IPv4, they also apply to IPv6. An example of a multihomed host for IPv6 is a computer using both IPv4 and IPv6 that has a network adapter that is connected to an intranet and an IPv6 tunneling interface.

Weak Host Model
In the weak host model, an IP host (either IPv4 or IPv6) can send packets on an interface that is not assigned the source IP address of the packet being sent. This is known as weak host send behavior. An IP host can also receive packets on an interface that is not assigned the destination IP address of the packet being received. This is known as weak host receive behavior.
When you have a multihomed IP host with multiple interfaces, enabling weak host receive behavior on interfaces can sometimes make the host vulnerable to multihome attacks. For example, Figure 1 shows Host A connected to both the Internet and an intranet. Host A has the public IPv4 address 131.107.89.211 assigned to its Internet interface and the private IPv4 address 192.168.17.48 assigned to its intranet interface.
Figure 1 Example of a multihomed computer 
With weak host send behavior enabled on both its Internet and intranet interfaces, Host A can send packets from 131.107.89.211 on its Internet interface, packets from 192.168.17.48 on its Internet interface, packets from 131.107.89.211 on its intranet interface, and packets from 192.168.17.48 on its intranet interface.
With weak host receive behavior enabled, Host A can receive the following types of packets (assuming that the host firewall rules permit the incoming traffic): packets to 131.107.89.211 on its Internet interface, packets to 192.168.17.48 on its Internet interface, packets to 131.107.89.211 on its intranet interface, packets to 192.168.17.48 on its intranet interface.
When you have weak host receive behavior enabled, a malicious user on the Internet can send packets to Host A's Internet interface to attack services running on Host A that are only available to hosts on the intranet. This type of attack can occur if the Internet infrastructure supports the forwarding of packets destined for 192.168.17.48 to Host A's Internet interface. You can prevent this type of attack by setting the appropriate firewall rules on Host A's Internet interface. Even if you do, however, the services running on Host A that are available to intranet clients can be at risk.

Strong Host Model
In the strong host model, the send and receive behaviors are different. With strong host sends, the host can only send packets on an interface if the interface is assigned the source IP address of the packet being sent. With strong host receives, the host can only receive packets on an interface if the interface is assigned the destination IP address of the packet being received.
With strong host send behavior enabled on its Internet and intranet interfaces, Host A in Figure 1 can only send packets from 131.107.89.211 on its Internet interface, and packets from 192.168.17.48 on its intranet interface.
With strong host receive behavior enabled, Host A can only receive packets to 131.107.89.211 on its Internet interface and packets to 192.168.17.48 on its intranet interface.
In Figure 1, the strong host model for Host A drops all incoming packets on the Internet interface that are addressed to 192.168.17.48 without the need for you to configure firewall rules, effectively isolating the intranet interface of Host A from the Internet.
When you choose the strong host model, remember that it might impact some types of connectivity that are designed for weak host behavior. For example, some load balancing implementations might use weak host receive behavior to receive packets on any interface and then route them to the appropriate interface internally. A host that uses weak host sends to send traffic from any source address on an interface corresponding to a fast connection can also be impacted.

Strong Host Sending and Receiving
Now let's see how the sending and receiving process works on a generic host for either IPv4 or IPv6 when you allow strong host sends and receives to be enabled or disabled on a per-interface basis.
For packets being sent, IP first checks whether a source address has already been specified. If it hasn't, IP performs an unconstrained lookup of the destination address of the packet in the routing table. In an unconstrained lookup, all of the routes in the routing table are considered. Based on the selected route for the destination, IP determines the next-hop interface (the interface used for placing the packet on the link layer) and the next-hop address. Based on the next-hop interface, IP uses the address selection process defined in RFC 3484 as needed to determine the best source address. At this point, IP has everything it needs to send the packet: the source and destination addresses, the next-hop interface, and the next-hop address.
If the source address has been specified, the source interface is known. The source interface is assigned the source address. IP then determines whether strong host sends are enabled on the source interface.
If they are disabled, IP performs an unconstrained lookup of the packet's destination address in the routing table. Based on the best matching route for the destination, IP determines the next-hop interface and the next-hop address. IP has the source and destination addresses, the next-hop interface, and the next-hop address. Note that with strong host send behavior disabled on the source interface, the next-hop interface might not be the same as the source interface.
If strong host sends are enabled on the source interface, IP performs a constrained lookup of the destination address of the packet in the routing table. In a constrained lookup, only those routes with a next-hop interface of the source interface are considered. Based on the selected route for the destination, IP determines the next-hop address. IP has the source and destination addresses, the next-hop interface, and the next-hop address. Note that with strong host send behavior enabled on the source interface, the next-hop interface is always the same as the source interface. Figure 2 shows the generic IP sending host process.
Figure 2 Generic IP sending host process (Click the image for a larger view)
When the source address has been specified, the constrained route lookup can select a route with a higher metric among multiple routes in the routing table that are the closest match to the destination. For example, Host A in Figure 1 has two default routes; one points to the Internet with a metric of 10 and another points to the intranet with a metric of 20. Strong host behavior is enabled on both LAN interfaces.
If the sending application on Host A does not specify a source address, the result of the route lookup is the default route with the lowest metric; Host A always sends the traffic out of the Internet interface with a source address of 131.107.89.211. However, if the sending application on Host A specifies a source address of 131.107.89.211, the result of the lookup is the default route for the Internet interface; Host A sends the traffic out of the Internet interface. If the sending application on Host A specifies a source address of 192.168.17.48, the lookup selects the default route for the intranet interface; Host A sends the traffic out of the intranet interface. With the constrained route lookup, IP sends traffic with a source address of 192.168.17.48 using the default route with the higher metric.
For received traffic, IP first determines whether the traffic is destined for the host. If not, IP silently discards the packet because the host is not acting as a router. IP then determines whether strong host receives are enabled on the incoming interface (the interface on which the packet was received). If disabled, IP processes the packet. If enabled, IP determines whether the destination address in the packet is assigned to the incoming interface. If so, IP processes the packet. If not, IP silently discards the packet. Figure 3 shows the generic receiving host process.
Figure 3 Receiving host process 

Weak and Strong Host Behavior in Windows
Windows XP and Windows Server® 2003 use the weak host model for sends and receives for all IPv4 interfaces and the strong host model for sends and receives for all IPv6 interfaces. You cannot configure this behavior. The Next Generation TCP/IP stack in Windows Vista and Windows Server 2008 supports strong host sends and receives for both IPv4 and IPv6 by default on all interfaces except the Teredo tunneling interface for a Teredo host-specific relay. Figure 4 lists the commands that you can use to configure send and receive behavior for both IPv4 and IPv6 on a per-interface basis. Note that InterfaceNameOrIndex is either the name of the interface from the Network Connections folder or its interface index. You can obtain the interface index of an interface from the display of the command:
netsh interface ipv6 show interface
Weak and Strong Host Behavior and RFC 3484
To provide a standardized method to choose source and destination IPv6 and IPv4 addresses with which to attempt connections, RFC 3484 defines two algorithms. The first is a source address selection algorithm to choose the best source address to use with a destination address. The other is a destination address selection algorithm to sort the list of possible destination addresses in order of preference.
Strong and weak host behavior is in effect when determining the list of candidate source addresses for a given destination address, and this also affects the final sorted list of destination addresses. For strong host send behavior, the list of candidate source addresses consists of the unicast addresses assigned to the sending interface for the destination. For weak host send behavior, the list of candidates can include addresses assigned to any interface that has weak host sends enabled. For more information about source and destination address selection, please go to microsoft.com/technet/community/columns/cableguy/cg0206.mspx.

By default, both weak host sends and weak host receives are disabled for both IPv4 and IPv6 for all interfaces except the Teredo tunneling interface for a Teredo host-specific relay.
For more information about RFC 3483, see the sidebar "Weak and Strong Host Behavior and RFC 3484."

Disabling Default Routes for Remote Access VPN Connections
A remote access virtual private network (VPN) client is another example of a multihomed host. Even though it might have a single LAN interface that is connected to the Internet, when a remote access VPN client completes a VPN connection, it is multihomed. It has two interfaces: its LAN interface and an interface based on Point-to-Point Protocol (PPP) for the VPN connection. It also has two IPv4 addresses: an Internet Service Provider-assigned IPv4 address for the LAN interface and a VPN server-assigned IPv4 address for the PPP-based interface.
To ensure that the VPN client sends default route traffic across the VPN connection to the intranet, Windows XP and Windows Server 2003 modify the IPv4 routing table by raising the metric of the existing default route and adding a new default route with a lower metric that uses the PPP interface. This default behavior makes the locations on the intranet reachable and almost all of the locations on the Internet unreachable for the duration of the VPN connection. It is possible to configure a VPN client for split tunneling to have simultaneous access to both Internet and intranet locations by not adding the default route for the VPN connection and adding specific routes for intranet destinations. However, there is a risk that split tunneling VPN clients can route packets between the Internet and the intranet. For more information, see microsoft.com/technet/community/columns/cableguy/cg1003.mspx.
The default VPN client behavior in Windows XP and Windows Server 2003 was designed for weak host send behavior. The route lookup always uses the default route for the VPN connection because it has the lowest metric. However, when you use strong host send behavior, the default route used for sent traffic depends on the source IP address in the packet. The route lookup for traffic from the IPv4 address assigned by the ISP will use the default route that uses the LAN interface, making all Internet locations reachable. The route lookup for traffic from the IPv4 address assigned by the VPN server will use the default route that uses the PPP interface, making all intranet locations reachable. Therefore, when you use strong host send behavior, the VPN client has a split tunneling configuration and simultaneous access to both the Internet and intranet, even for applications that do not have administrator-level privileges to directly modify the IPv4 routing table.
To prevent strong host send behavior from creating a split tunneling configuration by default, the VPN client in Windows Vista® and Windows Server 2008 automatically disables the default routes of LAN interfaces when the VPN connection completes. This behavior ensures that there is only a single active default route in the routing table that uses the PPP interface. This behavior also ensures that applications without administrator-level privileges cannot perform split tunneling.
Because of the fact that traffic from the VPN client computer must originate from the IPv4 address assigned by the VPN server, this behavior provides better isolation of the intranet from the Internet. When the VPN connection is terminated, the disabled default routes are enabled.
You can control this behavior with the command:
netsh interface ipv4 set interface [InterfaceNameOrIndex]
ignoredefaultroutes=enabled|disabled

Joseph Davies is a technical writer with Microsoft and has been teaching and writing about Windows networking topics since 1992. He has written eight books for Microsoft Press and is the author of the monthly online TechNet Cable Guy column.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
Page view tracker