in a network zone protected by firewalls, you'll often have to secure server-to-server communication channels. for example, in an enterprise app, your workflow server might be calling in to your middle-tier business logic web service.

imagine that, for whatever reason, it's difficult to negotiate a web-services based authentication scheme for use between your middle tier web service and the workflow server calling into it. you might consider a network identity-based approach to authenticating the caller: the middle-tier web service could be configure to reject calls not originating from a set of known, trusted IP addresses.

start out assuming that we can trust that the source IP address is actually the IP address of the originating machine. source IP address-based security doesn't adhere to the principle of defence-in-depth: any attacker able to run code capable of talking of the network from a machine with a trusted IP address can then make whatever calls he wants to the exposed service. this differs from, say, an approach where credentials must be presented by the client because an attacker in that case would have to compromise the credential store, which in turn presumably is secured based on a service account's credentials.

now we should question the assumption that the IP address is reliably the IP address of the originating machine: if you read the IP spec, you'll see the "source IP address" field in the IP packet header. this is specified by the sender, so we're vulnerable to IP spoofing, in which an attacker sends his web services-call packet from an untrusted machine, but (here's the spoof) specifies the source address of one of the trusted machines.

there are, however, a few mechanisms which protect against IP spoofing.

firstly, TCP, layered on top of IP, introduces a handshake that initiates a reliable conversation. the initiator sends a SYN, the other party responds with a SYN/ACK, and the initiator finalises the setup with an ACK. if the source IP address has been spoofed, in the second step, the "other" party's SYN/ACK response will go to the source IP address identified in the IP header, not the attacker. this machine's not expecting the SYN/ACK, so it won't send an ACK, so the conversation won't be initiated, so the attack fails.

this leaves the possibility of hijacking a pre-established conversation between a legitimate IP address and the server. TCP guards against conversation hijacking by introducing sequence numbers. running out of time. not sure exactly how sequence numbering protects against malicious attack - surely if the attacker observes the sequence (assuming it's incremental), he can predict the next value (x + 1!) and insert his own malicious packet. later, the legitimate party to the conversation will send a packet with the same sequence number, but it will be dropped as invalid. but the attacker's packet was accepted, so maybe the attack succeeds?

what i may be missing is some cryptographic aspect to sequence numbering which means that the sequence is cryptographically hard to predict.