The Internet Protocol Journal, Volume 16, No. 1

Address Authentication

by Scott Hogg, GTRI

Some Internet services use the source address of the client's computer as a form of authentication. These systems keep track of the Internet Protocol (IP) address that an end user used the last time that user accessed the site and try to determine if the user is legitimate. When that same user accesses the site from a different source IP address, the site asks for further authentication to revalidate the client's computer. The theory is that a user's typical location computer has a somewhat persistent IP address, but when the user has a new address, that user may be mobile or using a less secure wireless media, and then require further authentication. For example, many organizations have firewall policies with objects named like "Bob's Laptop" with the single IP address of his computer. This technique is used by some banking sites, some online gaming sites, and Gmail (for example, Google Authenticator) [1].

Some online retailers track the client IP address for Business Intelligence or fraud detection and forensics purposes. The retailer tracks the client IP address using the source address to analyze fraudulent purchases and to track down criminal activity. Some industries frequently use the customer's IP address as a form of authentication. Also, many sites that use Server Load Balancers (SLBs) and Application Delivery Controllers (ADCs) use X-forwarded-for (XFF) [2] or Hypertext Transfer Protocol (HTTP) header insertion so that the back-end real servers are aware of the client's original IP address associated with the reverse proxy connection. The application can then use the IP address for tracking purposes or simply log the address with the transaction details.

Other applications try to validate the client's source IP address when the server receives an inbound connection. E-mail Simple Mail Transfer Protocol (SMTP) servers or Internet Relay Chat (IRC) servers can use the Ident protocol [3] to try to validate the originating e-mail server or client computer validity. SMTP e-mail servers [4] also use other protocols such as SenderID [5], Sender Policy Framework (SPF) [6], and DomainKeys Identified Mail (DKIM) [7] in an effort to restrict spam. Domain Name System (DNS) pointer (PTR) records are sometimes used as a way to confirm that the client IP address is configured in DNS (for example, forward-confirmed reverse DNS [8]).

Statically configured IP addresses are frequently used to signify some limited form of authentication. These addresses may not be used to authenticate a user, but authenticate IT systems to each other. Many manually configured systems rely on IP address to permit connectivity, including manually configured tunnels, IP Security (IPsec) peers, Apache .htaccess [9], .rhosts [10], SAMBA, and Border Gateway Protocol (BGP) peers, among many others.

The address is used as one part of the connection authentication. Obviously, IPsec connections are authenticated with certificates or preshared keys to strengthen their validation of the endpoints. Similarly, BGP peers use passwords (and/or Time To Live [TTL] [11]) to help secure the peer beyond just IP address confirmation.

Identity-based firewalls police users' network behavior by IP address through Windows Active Directory, Remote Authentication Dial-In User Service (RADIUS), or Lightweight Directory Access Protocol (LDAP). Palo Alto firewalls championed the UserID concept as part of their analysis of connections to permit or deny authentication [12]. The Cisco Adaptive Security Appliance (ASA) firewalls running Version 8.4 or later can be configured for Identify firewall functions [13]. Firewalls have always used manually configured IP addresses as the fundamental element of their policies. The IP address is used in the policy as if that concretely defines a system and/or user. This process of adding rules based on IP address continues until the firewall is a pincushion full of pinholes.

Organizations that rely on using an IP address as a form of authentication run the risk of an attacker learning that IP address and attacking using that address. Attackers who know the addresses that are being used could perform a Man-in-the-Middle (MITM) attack or use TCP session hijacking. The attacker needs to know only the information about which IP addresses are used for the communications. The attacker might be able to ascertain the IP addresses the organization uses by guessing or by other means. The attacker could find the external IP address of the company's firewall and assume that IPv4 Network Address Translation (NAT) [24] was being performed. The attacker could also suppose the business partner IP address. Organizations that use these techniques are relying on the secrecy of their IP addressing for the purposes of security.

Address Quality

The quality of the IP address is an important concept to consider. For example, a global address is of higher surety and authenticity than a private address. Many organizations use private addresses and overlap between private networks, whereas global addresses are unique and they are registered to a specific entity. Public addresses can reveal the clients' Internet Service Provider (ISP), the organization that has registered the IP addresses, and some geolocation information. However, any IP packet can be spoofed and the source-address modified or crafted. Of course, if the source IP addresses is spoofed, the return packets will not necessarily be sent back to the attacker's source in these cases, but one-way blind attacks are still possible. Furthermore, systems such as Tor [14] are intended to protect the identity of the end user.

Using the IP address as a form of authentication does not work if the client changes its location frequently. Today, many clients use mobile devices that can change their Layer 3 addresses often. The source IP address of the mobile device could change frequently and could even change during the transaction.

With increasing mobile device usage for business purposes, the ability to determine the typical IP address of the client becomes impossible. Increased scarcity of IPv4 addresses is leading service providers to use Carrier-Grade NAT (CGN) or Large-Scale NAT (LSN) and shorter and shorter Dynamic Host Configuration Protocol (DHCP) lease times, meaning that the client IP address is not static.

Many organizations and systems assume that a single computer with a single IP address represents a single user. The problem arises where IPv4 public addresses may not uniquely identify a single user. The industry may be trying to anticipate the implications of CGN/LSN and the effect of systems that rely on the uniqueness of a public IP address. Similar problems related to the mega-proxies of the late 1990s occurred (for example, AOL). With CGN/LSN systems in place, online retailers and banks will no longer be able to use the client IPv4 as the "real client IP." Instead, the IP address observed on the retailer's web servers will come from a pool of IPv4 addresses configured in the LSN system. In this situation, one bad actor could spoil that NAT pool IPv4 address for subsequent lawful users who follow. When a legitimate user tries to make an online purchase and that user's system happens to use that IPv4 address of the bad actor, then the purchase attempt might be blocked. This situation would be bad for business on Cyber-Monday, or any day for that matter.

IPv4 IPv6
Extensive use of NAT No motivation for NAT
End users use private addresses End users use global addresses
Use of CGN/LSN starting Abundance of IPv6 addresses
Robust geolocation Geolocation needs improvement
Addresses could be spoofed Addresses could be spoofed

Public Addresses

Public IPv4 addresses are becoming increasingly scarce[15, 25], however, an abundance of global IPv6 addresses are available [16]. Global IPv6 addresses can be obtained from Regional Internet Registries (RIRs) or from an IPv6-capable service provider. Residential broadband Internet users today use private IPv4 addresses on their internal computers, but these computers will soon start to use global IPv6 addresses as they upgrade to IPv6-capable Customer Premises Equipment (CPE). IPv6-enabled residential subscribers and employees of IPv6-enabled enterprises will be using global addresses when they access an IPv6-capable Internet service.

To online retailers, this situation may represent a change to their IP address authentication measures. As IPv4 residential users start to go through CGN/LSN systems, their IPv4 addresses will be useless for authentication.

However, their IPv6 addresses will be global addresses with no NAT taking place between the client and the server [17]. It will be seemingly more accurate to use the IPv6 address to determine the validity of the source. IPv6 could potentially help to create an environment with more "trustworthiness" and less anonymity. For example, IPv6 IPsec connections could use the Authentication Header (AH) and Encapsulating Security Payload (ESP) together to create stronger connections, where IPv4 IPsec connections rely on NAT-Traversal and can use only ESP [18].

As we head toward an increasingly dual-stack world, applications will need to do "dual-checking" of both the client's IPv4 and IPv6 addresses. In a dual-stack world, there is more work to do [19], and servers using IP address authentication will need to understand that a single user will have both an IPv4 address and an IPv6 address and keep track of both. The other consideration is that IPv6 nodes may have multiple global IPv6 addresses in some situations.

Authentication with Addresses

Security experts know that the secrecy of the encryption algorithm is not important, but the secrecy of the key is vitally important (Kerckhoffs's Principle [20]). The same concept should hold true for an IP address. Users should not rely on the secrecy of their IP addresses to be secure; the security of the individual node should be strong enough to defend against attacks. To the extreme, users should feel confident enough in their security posture that they feel comfortable widely publicizing their IP address. However, even if you are using LifeLock [21], you should still keep your Social Security Number or government ID numberj private.

Security practitioners know that authentication should involve multiple factors. A combination of "something you are" (biometrics), "something you know" (username/password) and "something you have" (token, Common Access Card [22]) forms a more solid foundation for identifying a user. Combining two factors provides more assurance than just one factor. We are all aware of the weaknesses of using username and password as a means of authentication [23].

The systems mentioned so far in this article are three-factor systems (username, password, and IP address) which are presumably better than just username/password. However, we should acknowledge that an IP address is not a characteristic of a person. IP addresses have more to do with "somewhere you are," because the IP address reflects location within a network topology by the prefix/subnet. The last few bits of an IPv4 address representing the point-of-attachment or an IPv6 Interface Identifier (IID) do not necessarily uniquely identify a user. Having authentication based on your location becomes difficult with mobile devices that roam widely. However, controlling authentication to users who /are within the office subnet rather than outside the office may be useful.

An IP address is not something anyone really owns outright. Few organizations actually have complete ownership of their IP addresses. Organizations should read the fine print in the policies of their RIR. Organizations just pay RIR annual fees for their addresses, but if they stop paying those dues, the IP address allocation is revoked and the addresses go back into a pool for reallocation to another organization. Therefore, public IP addresses do not truly represent unequivocal ownership or legitimacy of a network.


Many different types of systems use the client's source address as a form of authentication. Systems that rely on IP address checking will need to do so for IPv4 and will need to be modified to use IPv6 addresses. IPv6 systems will use global addresses without NAT, so the security systems must stand on their own even though the IPv6 address is publicized. IPv4 and IPv6 addresses can be spoofed, and as CGN/LSN systems become widely deployed the validity of a public IPv4 address decreases. However, IPv6 addresses are not necessarily any more trustworthy than IPv4 addresses when used for authentication. Regardless, the IP address should not be the only factor used for authentication, and we should not be using IPv4 or IPv6 addresses as a form of authentication. The truth is that the IT industry needs to be aware of where IP addresses are used as a form of authentication and seek out better forms of authentication beyond just username, password, and IP address.


[1] Google Authenticator,


[3] Mike St. Johns, "Identification Protocol," RFC 1413, February 1993.


[5] Meng Weng Wong and Jim Lyon, "Sender ID: Authenticating E-Mail," RFC 4406, April 2006.

[6] Wayne Schlitt and Meng Weng Wong, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1," RFC 4408, April 2006.

[7] Miles Libbey, Michael Thomas, and Mark Delany, "DomainKeys Identified Mail (DKIM) Signatures," RFC 4871, May 2007.




[11] Vijay Gill, John Heasley, and David Meyer, "The Generalized TTL Security Mechanism (GTSM)," RFC 3682, February 2004.

[12] Palo Alto Networks, UserID,

[13] Cisco ASA firmware 8.4 Identify Firewall,




[17] Scott Hogg and Owen DeLong, "IPv6 NAT - You can get it, but you may not need or want it," Infoblox Blog, October 2, 2012.


[19] Scott Hogg, "Dual-Stack Will Increase Operating Expenses," Network World, July 31, 2012,



[22] Common Access Card (CAC),

[23] Mat Honan, "Kill the P@55W0rD," WIRED Magazine, December 2012,

[24] Geoff Huston, "Anatomy: A Look inside Network Address Translators," The Internet Protocol Journal, Volume 7, No. 3, September 2004.

[25] Several articles on IPv4 Exhaustion and IPv6 Transition in The Internet Protocol Journal, Volume 14, No. 1, March 2011.

SCOTT HOGG is the Director of Technology Solutions at GTRI in Denver Colorado. He holds a B.S. in Computer Science from Colorado State University, a M.S. in Telecommunications from the University of Colorado, and CCIE® #5133 and CISSP #4610 certifications. Hogg is active in the IPv6 community, Chair Emeritus of the RMv6TF, author of IPv6 Security (Cisco Press), a member of the Infoblox IPv6 Center of Excellence, a frequent presenter, and a Network World blogger. He can be reached at or followed on twitter @scotthogg