Subject: proposal for RTP header authentication method / anti-spamming

From: Euchner Martin <[email-masked]>
Date: Wed, 23 Feb 2000 16:48:01 +0100

Dear experts,

the following contribution attached below proposes an RTP header
authentication method to protect against denial-of-service attacks using RTP
packet flooding on discovered UDP/RTP ports.

First, some background information may be helpful for the reader's
understanding in general in addition to the contribution:
-	I am the editor in ITU-T Study Group 16 of draft recommendation
H.235 version 2, that deals with "Security and encryption for H-Series
(H.323 and other H.245-based) multimedia terminals".

-	Basically, H.235 describes the framework for security in H.323 based
multimedia systems. It offers a variety of security services such as
authentication, access control, integrity, confidentiality, non-repudiation
with digital signatures and integrated key-management with security
capability negotiation for the secured call signaling and secure media
transport over RTP. H.235v2 features also interoperable security profiles
for various purposes and scenarios.

-	H.235 basically offers two methods for protection of the RTP media
streams:
-	network layer security using IPSEC,
-	or application-level security where the RTP media payload data is
encrypted. This is the preferred method that is currently of major interest.
Several encryption algorithms could be applied, among them are DES,
Triple-DES and RC2.
		Note, that ITU-T SG16 currently does not see necessities to
integrity protect the RTP media stream, this is an issue left for further
study, once there would be a requirement.

-	As the most recent successful and severe denial-of-service attacks
on major ISPs and Internet services shows, sophisticated attacking tools are
already available in the hacker community. Such attacking tools could simply
be misused (with none or slight modifications perhaps) also against the RTP
protocol and thus thwarting any system that uses the RTP protocol including
H.323 Voice-over-IP systems.

-	While approved recommendation H.235v1 does not provide explicit
countermeasures against denial-of-service attacks, it is recognized that
H.235v2 should provide a simple, light-weight security means that is
sufficiently effective without the necessity to integrity-protect complete
media packet for performance reasons. The proposed light-weight security
improvement for RTP interworks both works with H.235 encrypted media streams
but also simply with unencrypted RTP payload data. H.235v2 cares for the
necessary key-management with automatic, integrated session
key-distribution, key update/synchronization and security capability
negotiation using H.245 open logical channel signaling means. H.235 allows
also manual key-management with statically configured keys. RTP does not
define any key-management and defines key-management tasks as by "non-RTP
means". Thus, our proposal nicely fits already in the current RTP approach
and concept.

-	At the most recent ITU-T Study Group 16 meeting in Geneva, CH, 7-18
February 2000; the attached contribution D.335 was accepted for H.235v2.
However, it was pointed out by some delegates, that the IETF AVT working
group currently discusses a revised version of the RTP protocol. As the
fundamental problem is more related to RTP than H.323, we feel, that it
would be wise to solve the problem on an RTP level and provide the solution
to other RTP applications as well. Thus, we see good opportunities to
discuss our ideas with you and that we hopefully could come to an agreement
of a common procedure.

-	Our workplan in ITU-T SG16 is as follows: H.235v2 has recently been
determined. The final version of the draft is scheduled for
approval/decision in November 2000. Our next Rapporteurs meeting will be
held in May. We see good chances to come to a resolution of these common
matters until then.

-	The idea that is described in the proposal, cryptographically
protects the changing portion of the RTP header (i.e. timestamp and sequence
number) with a message digest. The result is put into the modified RTP
padding fields in the end of the RTP packet. This should be backwards
compatible with existing implementations. The message digest could be
computed using encryption techniques (DES-MAC) or using a secure hash
algorithm (SHA-1). These algorithms are not part of D.335 and have been
recently added to the draft of H.235v2. The receiver could verify the
authenticity of the packet and drop it if the digest is not correct. This
operation consumes only low effort and saves any significant processing
effort or resources of the application on top of RTP that would occur
otherwise.

-	Another option could be to deploy the RTP header extension method.
It is not clear, whether this had significant benefits and how that exactly
would work.

-	At present the enhanced RTP protocol format is still very flexible;
the length of the AUTH and padlen fields are not fully fixed since H.235 can
negotiate these parameters using H.245. When the protocol extension became
part of RTP, some further considerations should be given on defining
appropriate packet formats of course.

-	The contribution is the ASCII-converted delayed contribution D.335
with some minor modifications. I've decided to have the H.245 and H.235
stuff still included for better understanding of the entire procedures even
the RTP issues in the current draft would likely not be affected by this.
Those of you who are interested in the original Word97 version of the
document, may obtain it on request of course.

I am looking forward to hearing your comments, opinions and questions on
this.

With kind regards,

Martin Euchner.

Here is the proposal:

TITLE:	RTP anti-spamming method in H.235v2
____________________________________________

This contribution describes a security enhancement to H.235v2 to counter
denial-of service attacks on UDP/RTP ports when sending spam media packets
against the recipient. The described improvement will increase the security
and reliability of H.323 Voice-over-IP-systems.

1. Introduction

		Current H.323 and H.235 based multimedia systems do not
provide explicit means against denial-of-service attacks when flooding
discovered RTP/UDP media ports with spam  packets. This is of concern in
mission-critical VoIP systems that require high availability and have to
resist basic attacks.

		Some simple, lightweight security means are necessary to
counter the flooding attack on a discovered UDP port. As a result of a
successful attack, the end system (terminal, gateway, MCU,...) may no longer
provide its service or function appropriately due to caused overload
situation while considerably wasting resources (processing, memory,..). Such
an attack using IP-masquerading techniques is basically possible on any
H.323 system, regardless of whether H.235 media (voice/video) encryption is
implemented or not. While firewalls usually cannot counter this kind of
attack once the UDP ports have been connected through, the countermeasure
could be implemented in the end-system. For an attacker listening to the
media port negotiation (H.245 or H.225.0), the denial-of service attack is
quite easy to perform. The attacker either sends arbitrary media packets
with meaningful RTP header information or even replays intercepted RTP media
packets on the discovered port. The attacker may even probe the destination
ports without listening to a signaling connection.

		Present H.235 does not provide adequate security means to
protect against such threats. While media integrity in general would provide
means to detect such denial-of-service attacks too, the required
countermeasures are usually quite CPU-cycle intensive as the entire media
packet would have to be cryptographically integrity protected. Actually,
media integrity would not only counter any content manipulation of the data
in transit but also provide the media anti-spamming as a side effect.
However, as the need for true media integrity is not obvious at the moment,
section H.235/B.3 lists integrity and replay protection of the RTP stream as
for further study.
		We provide an appropriate, yet simple lightweight
countermeasure, which is suitable for H.323 systems both with and without
implemented media encryption. Thus, the security can be enhanced
step-by-step.

		The basic idea is to utilize the end-to-end secret that can
be negotiated by means of H.235 anyway and apply it cryptographically to a
short, non-constant portion of the RTP packet and compute some digest upon;
actually this is a cryptographic message authentication code. Rapid checking
of the digest allows the receiver to filter out unauthorized packets from
unknown sources before spending any further considerable resources
processing the malicious packet. This shall thwart the denial-of-service
attacks of RTP packet flooding. We therefore call this security mechanism
the "media anti spamming method". The cryptographic digest may be computed
using a symmetric crypto algorithm such as DES or SHA1.

2. Proposal

		We propose to use the new media anti-spamming method as an
option in H.235v2 (summarized in a new subsection 11.2 of H.235v2) and adopt
the following modifications to H.245 as well.
		It is proposed to use the DES algorithm for the digest
computation; SHA1 may be used as an alternative when the system does not
offer media encryption.

2.1. H.245 modifications:
{this subsection is provided just for your information, it is subject to
H.245 and H.235}

		The capability of a terminal to support anti-spamming is
signaled in H.245 as follows. The anti-spaming capability is thus subject to
negotiation as well:
		EncryptionAuthenticationAndIntegrity offers
AuthenticationCapability, which is extended as follows for media
anti-spamming:

Enhancements to H.245 ANNEX A:

AuthenticationCapability	::=SEQUENCE
{
	nonStandard            	NonStandardParameter OPTIONAL,
	...
	antiSpamAlgorithm	OBJECT IDENTIFIER OPTIONAL
}

		Enhancements to H.245 Annex B.2.2.8 (Encryption,
Authentication and Integrity Capabilities)
		EncryptionCapabilities, if present, indicate the encryption
capabilities of a terminal for each media type where the capabilities are
present. The scope of encryption indicates whether the encryption is applied
to the entire bit stream, a portion of the bit stream in a standard way, or
a portion of the stream in a non standard way. The algorithm selects the
encryption algorithm. 
		AuthenticationCapabilities if present, indicate that the
authentication components of H.235 [16] are supported by the terminal.
antiSpamAlgorithm indicates the method and algorithm how to provide
countermeasures against flooding and denial-of-service attacks.

2.2. H.235 additions

		H.235v2 provides a new subsection "11.2 Media anti-spamming"
with the following content:

		The receiver of an RTP media stream may wish to counter
denial-of-service and flooding attacks on discovered RTP/UDP ports.
Receivers, when having implemented the anti-spam capability, can quickly
determine whether an obtained RTP packet stems from an unauthorized source
and discard it.

		The anti-spamming capability when set indicates use of the
anti-spamming mechanism either
		- for plaintext media data without media encryption (see
case 1 below) or
		- in combination with encrypted media data when
EncryptionCapability features an encryption algorithm (see case 2 below).

		Both options provide a lightweight RTP packet authentication
on selected fields through a computed message authentication code (MAC). The
MAC may be computed using an encryption algorithm (e.g. DES in MAC mode, see
ISO/IEC 9797) or using a cryptographic one-way function (e.g. SHA1). The MAC
algorithm is indicated in the object identifier of antiSpamAlgorithm. The
algorithm OID implicitly indicates also the size of the MAC; e.g. 1 block =
64 bits for DES MAC. In order to save bandwidth, the MAC could be truncated
albeit sacrificing some security; e.g., to a 32-bit MAC; this requires a
different object identifier then. The anti-spam method is independent of any
additional payload encryption (see cases 1 and 2 below).

		Anti-spamming uses the following RTP packet format (see
Figure 1) where the RTP padding sequence is interpreted as follows (see
H.225.0 Annex A.5).
		- The P bit in the RTP header shall be set to 1.
		- Padding bytes shall be appended at the end of the payload
with the following meaning:

 <------------------------------- RTP packet
----------------------------------------------->
 <--        RTP Header            --> <-RTP payload-> <--         RTP
padding             -->

+----------+------+-----------+------+---------------+---------------+------
--------+--------+
|... P ... | SEQ# | timestamp | .... | media payload | padding bytes |
AUTH    | padlen |
+----------+------+-----------+------+---------------+---------------+------
--------+--------+

\____    e.g. 64 bits     ___/        \__ possibly encrypted      __/
\e.g.64 bits / \1 byte/

^
 
|
           MAC_k(...SEQ#,timestamp)
----------------------------------------+

		Figure 1: General RTP packet format for media anti-spamming

		Note: If anti-spamming is not used, then the AUTH and padlen
fields are not used either and the usual RTP packet format applies.

1. Case anti-spamming-only:
		This case applies when the media data are not encrypted; see
Figure 2. The last octet of the RTP padding contains a count of how many
padding octets should be ignored at the end of the RTP packet. The other
padding bytes carry the MAC; see Figure 3. The MAC shall be computed over
the first crypto block of the RTP header including the varying timestamp and
sequence number using the negotiated MAC algorithm of antiSpamAlgorithm and
applying the symmetric secret. A static or manually configured shared secret
or a dynamically negotiated shared secret may be used according to the
procedures of H.235. For larger block sizes (more than 64 bits), some
sufficient additional bits of the RTP header or even the first media payload
shall be taken.

		As key for the MAC computation, it is recommended to use the
key that is obtained from the H.235 media session key distribution; although
the session key applied is not used for payload encryption. Secure fast
connect with key establishment (see H.323 Annex J) or manual keying may be
used for key management. The sender computes the MAC as described above and
includes the result in the MAC field in the RTP padding AUTH field. Sender
and receiver know the size of the AUTH field and the length of the MAC by
the antiSpamAlgorithm.

		The MAC verification at the receiver side should be done as
early as possible, if possible already within the RTP stack or at latest
before decryption or decompressing the payload. The receiver first
recomputes the MAC in the same way as the sender did and compares the
computed MAC with the delivered MAC in the RTP padding. If the MACs
mismatch, the RTP header has been modified in transit or was sent by an
unauthorized entity that does not possess the key. Thus, the
mis-authenticated RTP packet shall be discarded, the event may be logged;
this likely indicates an attempted denial-of-service attack. Otherwise, the
authenticated RTP packet can be processed further, the RTP padding is
removed and the payload is fed through the codec.

		Note: The lightweight MAC computation/verification with DES
encryption involves only a single encryption operation; alternatively, SHA1
MAC is computed on a short part of the packets of fixed length, thus the
crypto operations consume absolutely minimal processing resources.

 <------------------------------- RTP packet
-------------------------------->
 <--        RTP Header            --> <-RTP payload-> <--   RTP padding
-->

+----------+------+-----------+------+---------------+---------------+------
--+
|... P ... | SEQ# | timestamp | .... | media payload |     MAC       |
padlen |
+----------+------+-----------+------+---------------+---------------+------
--+

\___ e.g. 64 bits         ___/                        \e.g.64 bits  / \1
byte/

                                                             ^
                                                             |
           MAC_k(...SEQ#,timestamp) -------------------------+

		Figure 2: RTP packet format for media anti-spamming without
encryption

 <----- RTP padding ----------->

+------------------+------------+
|       MAC        |  padlen    |
+------------------+------------+
 \_ e.g. 64 bits _/ \_ 1 byte _/

Figure 3: RTP padding for anti-spamming-only

2. Case anti-spam method and payload encryption:
		This case applies when the media data are encrypted and the
anti-spamming method is invoked; see Figure 4. When the payload does not
fall on even block boundaries, some additional padding bytes have to be
appended to the payload in front of the MAC. The media payload encryption is
according to chapter 11/H.235.

 <------------------------------- RTP packet
----------------------------------------------->
 <--        RTP Header            --> <-RTP payload-> <--         RTP
padding             -->

+----------+------+-----------+------+---------------+---------------+------
--------+--------+
|... P ... | SEQ# | timestamp | .... | media payload | padding bytes |
AUTH    | padlen |
+----------+------+-----------+------+---------------+---------------+------
--------+--------+

\____    e.g. 64 bits     ___/        \_ encrypted in CBC mode    __/
\e.g.64 bits / \1 byte/

^
 
|
           MAC_k(...SEQ#,timestamp)
----------------------------------------+

		Figure 4: RTP padding for anti-spamming with payload
encryption

		EncryptionCapability defines the payload encryption
algorithm while antiSpamAlgorithm defines the anti-spamming method. For
security reasons, the media encryption and the MAC shall use different
session keys. The MAC key k is computed by feeding the encryption key K
through the SHA1 one-way hash function;
		k = SHA1(K); sufficient bits shall be taken from the hashed
result in network byte order. When antiSpamAlgorithm indicates an encryption
algorithm, then the collected bits shall be made a correct encryption key;
e.g. setting DES parity bits.

		After the receiver successfully verified the authenticity of
the RTP packet, the payload is decrypted and then the RTP padding be
discarded. The general procedure is according to case 1 above.

3. References

- Draft H.235v2: Security and Encryption for H-series (H.323 and other
H.245-based) Multimedia Terminals
- Draft H.323 Annex J: Security for H.323 Annex F
- H.245v7: Control Protocol for Multimedia Communication
- ISO/IEC 9797: Data cryptographic techniques - Data integrity mechanism
using a cryptographic check function employing an n-bit algorithm with
truncation.

-----------------------------------------------------------------------
| Dipl.-Inf.                     Phone: +49 89 636-46201
| Martin Euchner                 Fax  : +49 89 636-48000
| Siemens AG
| ZT IK 3                        mailto:[email-masked]
|                                mailto:[email-masked]
| Otto-Hahn-Ring 6               Intranet:
http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16/
index.html
| D-81730 Muenchen               Internet: http://www.siemens.de
| __________________
| Germany     
-----------------------------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Feb 2000 16:56:55 -0800 (PST)

Euchner,

You might want to take a look at the Packetcable
security spec (http://www.packetcable.com) which
also defines RTP payload encryption and
authentication. The basic synopsis of the
packetcable media stream security scheme is as
follows:

1) Derive keying from upper layer signaling

2) Use RC-4 for the media encryption of the
   payload only. Since RC-4 is a stream cipher,
   potential packet drops need to be taken into
   account which the spec goes into quite a bit of
   detail about.

3) Use a 2 or 4 byte MAC which is appended to the
   end of the RTP packet itself. The packetcable
   spec does not use the pad bit, though in
   discussions on the SIP mailing list, this was
   also brought up as an option. Others think that
   the packetcable approach but using a different
   RTP profile (say, RTP/AVP-AUTH) ala RFC 1890
   might be the right answer. I tend toward that
   solution because it consumes the fewest bytes,
   but the pad method is also a potential.

   One other difference is that the packetcable
   spec runs the MAC algorithm over the entire
   RTP packet, instead of just selected fields.
   In addition to being more secure, I suspect
   that you will find that running the MAC
   algorithm over the entire RTP datagram is
   cheaper CPUwise since it is more regular
   (we're only talking about a few bytes
   difference, right?).

I have done some preliminary testing and the
overall results look very promising (this was
compiled on my Linux box at home with a P150 in
it):

code size: ~1kb
ram size: ~530 bytes/full duplex (ie send and receive) 
speed: 2MB/sec for the MAC+Encryption 

In other words, it is *very* well suited to
implementation on both large and small gateways,
and very DSP friendly.

		  Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Feb 2000 21:07:59 -0500

>    (we're only talking about a few bytes

In a sense, 12 bytes of RTP header is more "regular" than the whole
payload. I agree that picking and choosing bits and pieces of the RTP
header is probably a waste of time.

However, one consideration is that this is needed not just for audio,
but also for video, in which case running MAC over the whole packet is
probably a good idea (2 Mb/s may not do the trick there, particularly
since you don't want to dedicate your whole CPU to this).

Thus, as I would hope that PacketCable looks ahead to more than just
audio, it appears that a header-only approach may be preferable.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Feb 2000 12:46:09 -0500

Michael Thomas wrote:
> 
> Henning Schulzrinne writes:
>    So, I'm confused: you're saying that the MAC
>    *should* be run over the RTP header + payload?
>    If so, I agree, and that is in fact what the
>    packetcable spec mandates.

No, it should only use the first 12 bytes RTP header (i.e., without
worrying about CSRC lists, although this is debatable), since video
packets are generally quite long and the overall video rate can well
approach your 2Mb/s capacity, sucking up all CPU just with doing
integrity checks. 

> 
>    It wasn't clear given my cursory reading of their
>    spec whether the MAC was run over the payload or
>    not. Assuming that it is not, the obvious
>    complaint is that it is susceptible to man in
>    the middle attacks which tamper with the
>    payload. While I guess this comes down to how
>    rigorous you want to be, it seems there should
>    be a huge amount of motivation to *not* do the
>    more secure thing. I'm not convinced at all for
>    audio that there is any such motivation, and
>    I'm pretty doubtful about video as well.

The primary motivation is data handling. In your scheme, a PC would do
nothing but generate the outgoing MAC and verify the incoming MAC, with
no cycles left for anything else useful. A nice denial-of-service attack
right there.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Feb 2000 09:37:54 -0800 (PST)

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Feb 2000 15:51:36 -0800 (PST)

> approach your 2Mb/s capacity, sucking up all CPU just with doing

   Uh, I don't think we should get all hung up
   about actual speeds. My P150 can do 2-3 M*bytes*,
   not bits, and if done on a DSP with single
   cycle multiplies, it would be closer to 10MB.

   But this ignores the larger question though: do
   you actually consider man in the middle attacks
   to be of no concern? With the way you're
   proposing we do this, I can intercept your 700
   Club video packets, and adulter the payload to
   play out the Hustler Channel (or more
   frightening still, the reverse). Your RTP
   receiver would be none the wiser.

   As far as DoS attacks, I can just as easily
   send you lots of MTU sized packets with ESP
   headers with a valid SPI and spoofed IP headers 
   to and cause you do lots and lots of useless
   SHA-1 computations; it sort of goes with the
   territory. Making RTP marginally better for
   DoS attacks doesn't seem like it's worth much
   in the grander scheme of things, especially
   when you're opening yourself up to well known 
   (and serious, IMO) attacks.

		  Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Feb 2000 19:01:37 -0500

>    (and serious, IMO) attacks.

Practically speaking, I can launch a DOS attack from just about
anywhere. It requires a fair amount of network access to intercept your
packets (since I need to be able to snoop them and then inject them
again).

That said, I agree we'd all be better off if we can agree on one method
within ITU/PacketCable/etc., rather than have half a dozen. Preferably a
method that then has an SDP negotiation mechanism associated with it;
would be even nicer to have one which is backward-compatible with
existing systems, as that would speed its deployment significantly.
Padding offers this, under the probably mistaken assumption that a
certain common RTP client made by a famous maker actually doesn't choke
on these (or header extensions).