Source Address Validation

Source Addresses and Communications

IP packets include address information for both the addressee (communications destination) and the source. When engaged in communications, the source sends an IP packet to the communications destination. The communications destination returns a response packet to the source address of the original IP packet. If the source address is not correct, the communications destination cannot correctly return a response.

Communications are conducted normally when the address assigned by the ISP is used as the source address. However, if for some reason an address is used that differs from the original source address, the response from the communications destination cannot be returned properly, preventing the establishment of two-way communications.

Improper Source Addresses

In general, the following types of addresses are considered to be improper source addresses:

• Private Addresses
• Unassigned Internet addresses
• Special addresses such as 0.0.0.0 and multicast addresses

In more precise terms, a normal state is one in which communications are conducted using an assigned address; an improper state is when a source address differs from the original assigned address.

There are several conceivable reasons as to why a source address may be different than an assigned address. One cause could be a problem with software. It is not uncommon for software defects to result in the attachment of incorrect IP addresses or incorrect NAT behavior. Another cause could be the falsification of the source address by malevolent software. Attackers engaging in spreading worms, DoS or other attacks may falsify the source address to disguise their identity or to make response difficult.

Over recent years, we have seen an increasing amount of source address falsification associated with DoS attacks and other improper Internet communications. Smurf attacks are one of the main types of attacks that use falsified source addresses. Other cases of source address falsification have been associated with SYN flood attacks and ICMP flood attacks. Source address falsification not only disrupts normal communications, but it also places extreme loads on ISP backbones and customer network environments due to the enormous volume of needless communications flow.

Source Address Validation Technology

IIJ uses Source Address Validation to reduce the effects of needless communications from falsified source addresses by verifying the legitimacy of source address.

The following are some of the technologies used for verify the legitimacy of a source address:

Source Address Validation Incorporated into IIJ Services

Effect of Implementation on Communications

Under uRPF strict mode and ACL packet filtering, communications with a source address that is the same as the IP address space for using the access service that has been assigned by IIJ (or the IP address already owned by the customer and reported to IIJ to be used) are treated as normal communications. Alternately, packets with a different source than the source address used to link to the access service are rejected.

In general, strict mode has no effect on communications when only one Internet access service is used.

However, under certain conditions where a multiple number of Internet access services are used in a specific manner, strict mode can negatively affect communications.

For example, an organization uses two Internet connection lines, each having its own assigned IP address:

• Address assigned by Access Service A: 10.1.1.1/32
• Address assigned by Access Service B: 192.168.1.0/24

Strict source address verify for Access Service B

When communicating using the Access Service B line, a problem will occur if the address assigned by Access Service A is used as the source address.

Using the Access Service B, only packets using source address 192.168.1.0/ 24 linked to the access service will be allowed to pass through, while any packets using a different source address will be rejected. Accordingly, any packets with the source address assigned through Access Service A will be rejected when coming from the Access Service A line.

Even under this structure, there will be no effect on communications as long as the access service and assigned addresses correspond properly.

In cases where the network structure may cause a discrepancy in access service and source addresses, we ask that customers revise their network so that addresses match, and that each connection service uses the correct address.

With ISP-to-ISP connections, or where networks have a redundant structure using multiple access lines, the upstream and downstream communications paths may be in an asymmetric state. According to uRPF strict mode, the path to the source address and the interface from which the packet comes do not match; consequently, even packets having a correct source address can be rejected. In other words, uRPF strict mode cannot be implemented under certain connection topologies.

In the preceding situation, uRPF loose mode can be used as the technology for confirming source addresses. Under uRPF loose mode, packets that have a source address that exists within the path information are allowed to pass through, and any other packets are rejected. This means that, for example, packets using private address and unused addresses (generally viewed as improper source addresses), as well as packets using multicast addresses or other special addresses are detected and rejected. However, the drawback here is that if the source address exists within the path information, even if that source address has been falsified, the packet will be allowed through.

uRPF loose mode has no effect on customer communications, since only packets with a clearly improper source address are rejected. Prior to implementation, even packets containing a source address not located within the path information will arrive at the addressee; however, the response from the addressee will not be able to reach the source, preventing communications. In a post-implementation environment, packets with source addresses determined as improper are rejected before they can reach the addressee. There is no change here in the sense that communications do not occur, but the benefit of implementation is a reduced level of unneeded packets moving within the network.

The Future Outlook of Source Address Validation

The closer to the packet source, the more effective Source Address Validation is. When Source Address Validation is close to the source, unneeded communications can be rejected at a much quicker stage in the process, reducing the effect on an internal network. In addition, the closer to the source, the more detail with which a source address can be checked. This characteristic means that implementation of Source Address Validation not only on the part of the ISP, but also on the part of the customer's internal network results in much more effective source checking.

Firmware version 1.60 (SEIL/Plus, SEIL/Turbo) for IIJ's "SEIL" routers will be released in March 2006. This new version will offer traditional filtering functions, as well as uRPF functions. This will allow our customers the ability to easily implement Source Address Validation on their networks.

Since Source Address Validation does not have any effect on normal communications, customers may find it difficult to actually feel whether it is effective. But be assured that Source Address Validation will prevent damage to your networks that can be caused by worms or DoS attacks using falsified source IP addresses. Both RFC2827 (BCP38) and RFC3704 (BCP84) recommend that all network administrators cooperate to help prevent IP source address falsification.

In theory, if Source Address Validation were implemented not only on the IIJ network, but on all networks worldwide, we could eradicate from the Internet any attacks relying on source address falsification.

At IIJ, we have actively engaged in Source Address Validation measures and education to reduce the effects of improper communications, providing an environment whereby our customers can use the Internet with greater safety and confidence.