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.
.gif)
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.
.gif)
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.
.gif)
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:
Figure 4 Commands to configure strong and weak send and receive behavior
• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled |
| |
netsh interface ipv6 show interface
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.