Hi All,
This is in reference to the discussion we had in the Annex G tele-conference earlier today regarding the security implications (particularly denial-of-service attacks) of using UDP for the inter-gatekeeper communication rather than TCP. Although it is known that TCP is inherently more secure than UDP, there are some mechanisms that may be employed to increase the security of UDP.
One mechanism that helps mitigate denial-of-service attacks in UDP is to use cookies. This was initially proposed by Phil Karn in his Photuris key exchange draft, and the use of cookies has consequently been incorporated into the Internet Key Exchange (IKE). IKE is the default mechanism for setting up security associations in the Internet. I've described below how the cookie mechanism can be used at the application layer of the intergatekeeper communication protocol. It can potentially be used at other layers too, but then those layers need modification.
The cookie exchange mechanism in the context of intergatekeeper communication using UDP works as follows. Initially, when a gatekeeper GK1 wishes to send, say, some kind of zone information to another gatekeeper GK2, it would include its cookie CKI1 in the crypto-token of the message. There are several ways to compute a cookie. For instance, it could be a keyed hash of GK1 IP address, GK2 IP address, GK1 port number, GK2 port number. The secret used to compute the keyed hash is known to GK1 alone (and not even GK2). the important thing is that the time that it takes to compute the cookie should be very small, and keyed hashes are very fast. Upon receiving this initial zone exchange message from GK1, GK2 could ignore the message (since it is not sure of the authentication) and send a message of its own to GK1 using its own cookie, CKI2.
For every subsequent zone exchange message between GK1 and GK2 using this pair of ports, both cookies are included in the crypto-token of the message. Now, when GK2 receives a message from GK1, it looks at the source IP address (GK1's IP address), destination IP address (GK2's IP address), source port, destination port in the packet and computes its cookie based on the secret that it alone knows. If this cookie matches CKI2 included in the message from GK1, then GK2 is reasonably sure that the message came from GK1. Similarly, when GK1 receives a message from GK2, it computes the cookie based on the IP addresses, ports and its secret and compares the cookie with the CKI1 sent by GK2. If they match, GK2 is reasonably sure that the packet came from GK1. Since the cookies are computed extremely fast, denial of service does not occur.
This method of using cookies against denial-of-service attacks is not failsafe. What it protects against is the case where an attacker can spoof arbitrary source IP addresses and port numbers and hence overwhelm a receiving GK. If the attacker can intercept packets sent from GK1 to GK2 containing GK1's cookie, he can spoof GK2 in this case. But, the most general case of denial-of-service attacks are where an attacker does not have access to such resources, but still arbitrarily tries to spoof some GK.
Source address filtering may come to mind to counter such spoofing and denia-of-service attacks, but suffers at least from the drawbacks that not all routers are equipped with source address filters and that even if they were, an attacker can at least spoof some gatekeeper within his domain.
The cookie mechanism can be employed at lower layers, but would mean a modification to the lower layers or some patches. It is much faster than AH in IPSEC because AH needs a security association to be established and either the establishment of a shared secret or the use of public key cryptography. The cookie mechanism does not use any shared secret. However, AH is definitely more secure and flexible. In any case, the use of cookies at the IP layer has not been seriously considered.
Regards, Senthil
Senthil Sengodan Nokia Research Center