Yes, extra care needs to be taken when using UDP rather than TCP. The security drawbacks to using UDP need to be weighed against the several advantages to using UDP which include the possibility of multicast and reduced latency.

A somewhat orthogonal issue is that security requirements may be satisfied when considering IGCP in the light of address resolution/routing alone, but may fail when other issues such as roaming and billing are later incorporated into the protocol.

Regards, Senthil

Senthil Sengodan Nokia Research Center ---------- From: Mailing list for parties associ To: ITU-SG16 Subject: Re: Intergatekeeper UDP security Date: Friday, July 24, 1998 1:28PM

This is a multi-part message in MIME format.

Senthil, Thanks for your description of the cookie based scheme for reducing the chances of denial of service attacks when running UDP based protocols. As you mention, this method is currently employed at the application layer, not at lower layers. This is in contrast to TCP where SYN flood attacks, at least, can largely be thwarted in the TCP stack implementation.

There are undoubtedly a number of ways to prevent or severely limit denial of service attacks at the application layer (you've pointed out two), and my point in the teleconference was just that we need to be especially vigilant when designing a UDP based inter-gatekeeper protocol to make sure that denial of service attacks are hard to mount. Moreover, we need to build the protection into the protocol itself so that different implementations of it will not differ with regards to their susceptibility to denial of service attacks.

Regards,

Hal Purdy AT&T Laboratories 180 Park Avenue Room E263, Bldg. 103 Florham Park, NJ 07932 (973) 360-8636 (w) (973) 360-8187 (fax)

-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.jf.INTEL.COM]On Behalf Of Sengodan Senthil NRC/Boston Sent: Thursday, July 23, 1998 4:05 PM To: ITU-SG16@mailbag.jf.INTEL.COM Subject: Intergatekeeper UDP security

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

BEGIN:VCARD VERSION:2.1 N:Purdy;K.;Hal FN:K. Hal Purdy TITLE:Principal Member Technical Staff TEL;WORK;VOICE:(973) 360-8636 TEL;WORK;FAX:(973) 360-8187 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;180 Park Avenue=0D=0ARoom E263, Bldg. 103;Florham Park;NJ;07932;United Sta= tes of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:180 Park Avenue=0D=0ARoom E263, Bldg. 103=0D=0AFlorham Park, NJ 07932=0D=0AU= nited States of America ADR;HOME:;;;;;;USA LABEL;HOME:USA URL:http://www.serve.com/ppa/hezz EMAIL;PREF;INTERNET:khp@att.com REV:19980525T184413Z END:VCARD