9

From my understanding, for incoming packets over IPSec, the Security Association (SA) is identified by the SPI field of the ESP header.

Then let's say I have a bunch of nodes where each node wants to be able to talk to each other node using IPSec tunnels (so n nodes, each of which talk to n-1 other nodes). If that is the case, no SPI value can be used for more than one SA and since there are 2 SAs between each pair of nodes, and since SPI is a 32-bit field, is it correct that there can only be ~65535 nodes in such a configuration?

If so, is there a way to have more nodes in such a configuration? The practicality of this "configuration" is a separate matter.

mmtauqir
  • 281
  • 3
  • 9
  • 1
    An SA is uniquely identified by both a SPI as well as a Destination Address. This means that you could theoretically have a single SPI for multiple destination nodes that would still uniquely be identified. This would increase the number of nodes that could be connected. – RoraΖ Sep 14 '14 at 21:39
  • I thought about that but because of an unusual situation, the addresses might change frequently, so using the dest/src address isn't reliable. – mmtauqir Sep 15 '14 at 11:43
  • What unusual situation? This configuration in general is unusual, and at a minimum impractical. – RoraΖ Sep 15 '14 at 12:20
  • Well, I would still like to have the original question answered, regardless of how how unusual/impractical it is. Let's call it an educational question. – mmtauqir Sep 15 '14 at 12:55
  • That's cool, I'm just curious as to what unusual situation makes the destination IP unreliable. – RoraΖ Sep 15 '14 at 13:00
  • Both ends of the traffic are behind NAT and use hole-punching and the NAT address frequently changes. – mmtauqir Jan 01 '15 at 11:01
  • @mtahmed Putting a NAT in front of a device intended to use IPsec doesn't sound like the best idea. – kasperd Jul 30 '15 at 05:14
  • @kasperd Why not? IPsec RFCs specifically make provisions for using IPsec behind NAT. – mmtauqir Jul 30 '15 at 22:22
  • @mtahmed Anything which isn't TCP or UDP is more likely to break when passing through a NAT. – kasperd Jul 31 '15 at 06:37
  • Of course we wouldn't be using IPsec behind NAT without UDP encapsulation. So it *is* UDP. – mmtauqir Aug 01 '15 at 01:11
  • IPsec does not use UDP. In vanilla IPsec, you would have an IP header, then the ESP/AH header. This *can* pass through an IP-only NAT (think static NAT). But *can not* pass through a PAT (which tries to modify the TCP/UDP header, which doesn't exist at this point). NAT Traversal *inserts* a UDP/4500 header between the IP header and IPsec header, allowing it to pass through a PAT device. This only works for ESP, however, since AH includes the IP Payload in its integrity validation, so even with the added UDP header, if the IP header changes, the integrity check will fail. – Eddie Sep 22 '15 at 18:55

1 Answers1

1

The math...32 bits. 

2^32 / 2 != 65535

2^32 = 4,294,967,296
4,294,967,296 / 2 = 2,147,483,648

You don't get IPSec without IP and IP defines a source and destination address in every packet. You'll always have a source/destination with each of our SAs.

That means your limit is 4,294,967,296 or 2,147,483,648 per IP address you communicate with because your software can keep track of the SA assigned to each IP.

@eddie clarified this answer in comments.

@Kasperd points out that it's possible that the limit is actually 2^32 without dividing by two. As pointed out in comments there is no requirement that the SPIs can't be the same in both directions because the receiver can see the peer IP address. So the max could be closer to 4,294,967,296.

You'll also notice that 2^32 is the entire IPv4 space, (discounting which are globally routable) and for this question, you will not run out of SPIs any time soon and I'm pretty sure other limits (memory, bandwidth, etc) will prevent you from exceeding a much smaller threshold.

Jonathan
  • 2,288
  • 13
  • 16
  • What about broadcast addresses and all that jazz? – cutrightjm Jul 29 '15 at 23:13
  • @ekaj I think you are misunderstanding the answer. But I am not sure because this answer is a bit unclear to me, so maybe I am the one who is misunderstanding. There are 32 bits in the SPI, that gives 2³² combinations of which I think only one is reserved. I think that is the point of this answer. I have seen many cases of people mentioning the 2³² possible IPv4 addresses completely ignoring that only 3700 million are globally routable. But this answer doesn't look like one of those cases. – kasperd Jul 31 '15 at 06:47
  • @Kasperd correct. Jonathan is doing 2^32 since there are 32 bits in an SPI. He is also dividing by two because each IPsec conversation has a unique SPI for each direction of the conversation. AKA, If you and I were speaking IPsec to each other, we would be using two different SPIs -- one to encrypt/decrypt data sent from me to you, and the other to encrypt/decrypt data sent from you to me. – Eddie Sep 22 '15 at 18:58
  • @Eddie The SPI is chosen by the receiving end, so usually different SPI will be used for each direction, but sometimes by chance the same SPI will be chosen for both directions. There is nothing preventing a node from having more than 2³² security associations for outgoing traffic because as long as those destinations have different IP addresses the SPI need not be unique. A node is limited to 2³² security associations for incoming traffic, no need to divide by two. – kasperd Sep 22 '15 at 19:34