Subject: [AVT] draft-ietf-avt-rtp-clearmode-02.txt review

From: John Lazzaro <[email-masked]>
Date: Wed, 17 Sep 2003 12:12:37 -0700

Hi everyone,

	Quick review of draft-ietf-avt-rtp-clearmode-02.txt:

  [1] There's an ID-nits issue on line length, according to "wc -L" the
  longest line is 90 characters over the 72-char limit (according to
  http://www.ietf.org/ID-nits.html).

  [2] Abstract formatting problem, the final line needs to be placed
  in the appropriate place.

  [3] In Section 5 final paragraph, the a=fmtp is discussed, yet 
  Clearmode has no defined fmtp parameters ... seems like there
  was a typo here (maybe "rtpmap" was meant instead of "fmtp"?).

	Finally, one potential security issue, I'm not a telephony guy
but ... are there any sort of in-band signalling security issues here?
I.e. if the stream is unauthenticated, could someone craft a single
RTP packet with a plausible timestamp and sequence number, inject it
into a Clearmode stream, and get network switching gear to do
something "interesting" for an attacker or for someone looking for
free phone calls?

	If so, one wonders if the "MAY" in the security considerations
for authentication is appropriate ... but as I said, I'm not a
telephony guy, and I've probably heard too many Captain Crunch
<http://www.wikipedia.org/wiki/Captain_Crunch> stories :-).

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Tom Taylor <[email-masked]>
Date: Thu, 18 Sep 2003 14:45:00 -0400

The whole point of this payload type is to provide a means of passing a 64 kbit/s 
bit stream end-to-end.  It is not processed as signalling in a telephone gateway. 
The only interaction I can think of is that bits apparently representing a 2600 kHz 
pure tone might be picked up by network signal processing equipment and interpreted 
as a request to disable echo suppressors, but without looking at details I'd be 
surprised if that were really an issue.