Subject: RE: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 5 Nov 2003 15:48:59 -0700

Hi Paul,

I did a brief review of draft 01 - glad to see updtl is not the end game
for t.38 fax. Find below some comments.
Hope this helps. 
Jean-Francois.

--- editorial comment
In section 3, secure RTP should be named or mentioned as one of the
advantages of going to t38/rtp for its overall capabilities. The concern
is that the paragraph in section 3 only refers to confidentiality of fax
streams (encryption) while I think that authentication is going to be as
important. 
Also consider change "an RTP" to "a RTP"
--
A number of issues were raised with respect to the usage of UDPTL for
   the long-term, though.  Specifically, there were concerns over the
   fact that UDPTL does not provide the same kind of statistics
   reporting as RTCP.  Further, there are no procedures in place for
   encrypting the UDPTL stream.  While the latter could be addressed in
   UDPTL, doing so would require a lot of effort and would largely be a
   duplication of the security work already on-going within the IETF.
--

--- technical comment
The section 6 (security considerations) is rather silent on the security
threats. 
Looking at the IFP packet format, I would argue that those packets do
expose serious threats to the communication that you don't see in audio
voice. If you insert a bad RTP packet voice payload, oh well, you may
hear some garbage or clipping. With rtp/t38 fax, bad packets may cause
real harm: 
+ denial of service attacks can be mounted by inserting RTP/t38 packets
with hdlc-sig-end data field can simply terminate the fax control
channel. Same with HDLC-FCS-BAD-Sig-End. And one can easily create those
packets.
+ theft of terminal identity? In some countries, faxes have more legal
value that emails and the access to the rtp packet content could change
the Called Subscriber ID frame (phone numbers), etc.  As you well know,
this info is usually not coded in RTP but in signaling protocols.

I'm sure the Study Group has thought of more. Could some examples of
security threats be given in the security consideration section and
shouldn't this section again reference SRTP? 
--
   The IFP packets carried via RTP do not carry any particular security
   risks in and of themselves.  However, as with other audio packets,
   there is the potential for unauthorized eavesdropping or manipulation
   of facsimile transmissions if the media stream is not properly
   secured.

   The security considerations discussed in the RTP specification [3]
   and any applicable RTP profile (for example, [8]) are also
   applicable.
--

> -----Original Message-----
> From: Paul E. Jones [mailto:[email-masked]] 
> Sent: Friday, October 31, 2003 2:01 PM
> To: [email-masked]
> Subject: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward
> 
> 
> Folks,
> 
> I would like to seek agreement from the AVT group to move the 
> document audio/t38 document forward.  As I have mentioned 
> previously, the ITU would like to incorporate this in T.38 in 
> an amendment to be approved in January 2004.
> 
> The motivation for transporting T.38 via RTP is probably 
> obvious to most. In fact, I recall several saying that that 
> is the way it should have been done from the outset.  Most 
> certainly, this will prove to be a good step in leveraging 
> SRTP for fax to address security needs.
> 
> The document is relatively short, just seeking the MIME 
> registration.  The technical details will be specified in the 
> ITU-T Recommendation T.38.
> 
> Can I get agreement to make this an official working group 
> item?  Can we try to get this approved by the January 2004 
> ITU-T SG16 meeting?
> 
> Thanks,
> Paul
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 5 Nov 2003 19:02:11 -0500

Jean-Francois,

It has been a long time!  Hope you're doing well...

> streams (encryption) while I think that authentication is going to be as

I purposely did not address SRTP, because this brings in a different RTP
profile (SAVP) and I've not fully studied what (if anything) needs to be
done to use that profile.  Further, SRTP is still in draft form.  I really
don't want to have interdependencies.  If SRTP can be used without any
textual changes to this document, then is begs the question as to whether
anything needs to be said.  If textual changes are required here OR to T.38,
then it strongly suggests we need to address it separately.  Advise welcome,
but please keep in mind that Q11/16 would like to have this MIME
registration before the Jan 2004 meeting of SG16.

> Also consider change "an RTP" to "a RTP"

This is the most interesting request I've seen.  Doing a Google search, I
see 18K pages with "an RTP" and 13K pages with "a RTP".  Which is correct?
It looks right to see "a RTP", but it just doesn't "sound" right.  Spelling
out RTP, I'd agree with "a Real..."

What was the specifc change you want made above?  Just calling out the "an
RTP"?

> shouldn't this section again reference SRTP?

These are both valid points.  I fully support the addition of some text that
highlights this fact.  I would not want to call these out explicitly,
necessarily, as there may be other places (e.g., modification or injection
of NSF data, etc.), so I think it's reasonable to speak to this generically.

Would you like to suggest some text?  I'd be happy to incorporate it.

Paul

---

From: Colin Perkins <[email-masked]>
Date: Thu, 6 Nov 2003 00:26:25 +0000

On Thursday, Nov 6, 2003, at 00:02 Europe/London, Paul E. Jones wrote:
...
> out RTP, I'd agree with "a Real..."

http://www.google.com/search?q=%22a+or+an%22

Cheers,
Colin

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 5 Nov 2003 20:19:40 -0500

Based on what I could find, the use of "an" or "a" is based on sound, not
spelling.  Thus, "an RTP" is right... but who can trust these documents on
the web? ;-)

pj