Intergatekeeper UDP security

[Hal Purdy]

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 at mailbag.jf.INTEL.COM]On Behalf Of Sengodan Senthil
NRC/Boston
Sent: Thursday, July 23, 1998 4:05 PM
To: ITU-SG16 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: K. Hal Purdy.vcf
Type: application/octet-stream
Size: 550 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/19980724/f852bc2a/attachment-0006.obj>