snmp audio call of 7/27/98

George Kajos gkajos at VIDEOSERVER.COM
Mon Jul 27 12:36:00 EDT 1998

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.


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.

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

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.


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
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

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.


Senthil Sengodan
Nokia Research Center

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
103=0D=0AFlorham Park, NJ 07932=0D=0AU=
nited States of America

More information about the sg16-avd mailing list