Subject: Re: Question about media desinations

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Feb 2000 11:23:10 -0500

Michael Thomas wrote:
> 
> The packetcable security spec specifies a 2 or 4
> byte MAC (using MMH) to be appended to the RTP

Is this simply hash(RTP packet | shared secret)?

Could the bad guy record a conversation, including the hash, and then
mix in the old data with the "real" one?

> packet itself. I have argued that RFC 2198 might
> actually be a cleaner way to append the MAC
> itself, but so long as the parties agree to the
> payload format, a relatively weak MAC should make
> barge in sufficiently difficult that even if an
> attacker managed to get through every once in a
> while, they probably wouldn't do anything
> especially exciting.

Since this is an RTP issue, I wonder if this shouldn't be written up for
avt. Another possibility is an RTP header extension. That, at least,
would be backward compatible with non-MMH implementations.

>  >
>  > >   So, what's stopping a haxor like me from strobbing a gateway with random
>  > > audio... ??

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 9 Feb 2000 09:06:19 -0800 (PST)

> Is this simply hash(RTP packet | shared secret)?

Yes. In packetcable, the payload is encrypted with
RC4, but the MAC is applied to the entire RTP
packet.
 
 > mix in the old data with the "real" one?

Not if you use the RTP timestamp. Built in
replay protection :-)

 > would be backward compatible with non-MMH implementations.

Whatever way has the least number of bytes is
probably the right answer. Packetcable's only
incurs the cost of the MAC itself since there is
an agreement between the sender and receiver that
there be the MAC tacked on to the end. Since it's
a trailer, it ought not effect a naive
implementation (though it would certainly violate
the "conservative in what you send" principle).

I do sort of like the idea of the MAC being a
payload not entirely unlike a codec payload,
though I'm not wedded to the notion. It does have
the advantage that we can offer up the MAC "codec"
up in SDP m= as being something that the endpoint
is willing to receive. With RFC 2198, the sender
would then oblige by sending several different
"codecs", namely the real codec and the MAC at the
same time.

	       Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Feb 2000 12:27:20 -0500

Michael Thomas wrote:

> the "conservative in what you send" principle).

Since RTP doesn't have a length field, a "naive" implementation would
treat the MAC bytes as G.711 samples. Not good.

> "codecs", namely the real codec and the MAC at the

My major concern with this is that there's a fair amount of overhead
just to get 2 or 4 bytes across.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 09 Feb 2000 18:03:27 +0000

>just to get 2 or 4 bytes across.

It's one more byte than using the RTP header extension.....

Still, it may be better to define a new RTP profile which includes the 
MAC as part of the fixed RTP header. That's probably the solution with 
the least overhead, and the protocol definition can be straightforward
RFC1890 + 4 bytes of MAC header.

Colin

---

From: Michael Thomas <[email-masked]>
Date: Wed, 9 Feb 2000 11:00:01 -0800 (PST)

> RFC1890 + 4 bytes of MAC header.

Would that not lead to a combinatorial explosion
of name space with rtpmap in SDP? Ie, G711-MMH2,
etc?  I'm all for having zero overhead, but not at
the expense of making a mess of SDP. That is sort
of why I was attracted to RFC 2198. If somebody
else has a better way of doing the same thing
without requiring, for example, structured names
in SDP that would be great too.
  
	Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Feb 2000 14:15:30 -0500

Michael Thomas wrote:

> of name space with rtpmap in SDP? Ie, G711-MMH2,

No, not really, this designation would replace the RTP/AVP in SDP with
something like RTP/AVP-MMH. The codec names would stay the same, since
they are unaffected by this change. .