2. IKE Protocol Details and Variations

2. IKE Protocol Details and Variations

IKE normally listens and sends on UDP port 500, though IKE messages may also be received on UDP port 4500 with a slightly different format (see Section 2.23). Since UDP is a datagram (unreliable) protocol, IKE includes in its definition recovery from transmission errors, including packet loss, packet replay, and packet forgery. IKE is designed to function so long as (1) at least one of a series of retransmitted packets reaches its destination before timing out; and (2) the channel is not so full of forged and replayed packets so as to exhaust the network or CPU capacities of either endpoint. Even in the absence of those minimum performance requirements, IKE is designed to fail cleanly (as though the network were broken).

Although IKEv2 messages are intended to be short, they contain structures with no hard upper bound on size (in particular, digital certificates), and IKEv2 itself does not have a mechanism for fragmenting large messages. IP defines a mechanism for fragmentation of oversized UDP messages, but implementations vary in the maximum message size supported. Furthermore, use of IP fragmentation opens an implementation to denial-of-service (DoS) attacks [DOSUDPPROT]. Finally, some NAT and/or firewall implementations may block IP fragments.

All IKEv2 implementations MUST be able to send, receive, and process IKE messages that are up to 1280 octets long, and they SHOULD be able to send, receive, and process messages that are up to 3000 octets long. IKEv2 implementations need to be aware of the maximum UDP message size supported and MAY shorten messages by leaving out some certificates or cryptographic suite proposals if that will keep messages below the maximum. Use of the "Hash and URL" formats rather than including certificates in exchanges where possible can avoid most problems. Implementations and configuration need to keep in mind, however, that if the URL lookups are possible only after the Child SA is established, recursion issues could prevent this technique from working.

The UDP payload of all packets containing IKE messages sent on port 4500 MUST begin with the prefix of four zeros; otherwise, the receiver won't know how to handle them.

Contents

• 2.1. Use of Retransmission Timers
• 2.2. Use of Sequence Numbers for Message ID
• 2.3. Window Size for Overlapping Requests
• 2.4. State Synchronization and Connection Timeouts
• 2.5. Version Numbers and Forward Compatibility
• 2.6. IKE SA SPIs and Cookies
  • 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD (see Section 2.6)
• 2.7. Cryptographic Algorithm Negotiation
• 2.8. Rekeying
  • 2.8.1. Simultaneous Child SA Rekeying (see Section 2.8)
  • 2.8.2. Simultaneous IKE SA Rekeying (see Section 2.8)
  • 2.8.3. Rekeying the IKE SA versus Reauthentication (see Section 2.8)
• 2.9. Traffic Selector Negotiation
  • 2.9.1. Traffic Selectors Violating Own Policy (see Section 2.9)
  • 2.9.2. Traffic Selectors in Rekeying (see Section 2.9)
• 2.10. Nonces
• 2.11. Address and Port Agility
• 2.12. Reuse of Diffie-Hellman Exponentials