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

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 6 Nov 2003 11:51:29 -0700

Paul wrote:
> 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.
I'll let other folks comment on whether it is appropriate to not address the draft's connections with SRTP.

> > --
> > 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.
> > --
> 
> What was the specifc change you want made above?  Just 
> calling out the "an RTP"?

How about something like:
s/encrypting the UDPTL stream/authenticating or encrypting the UDPTL stream

> > --- 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?
> 
> 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.
I would rather let you wordsmith my comments into something general you like on this one. 

Jean-François 

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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 06 Nov 2003 11:27:08 -0800

>the draft's connections with SRTP.

I think that there is _an_ SRTP connection (or is it connexion :?) that 
should be referred to in the security considerations.  The text that is in 
the current draft could be extended slightly to say that t38 is vulnerable 
to attacks that are common on other types of RTP payloads and that the 
security considerations and mechanisms of RTP and SRTP apply to t38.

Mark

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 6 Nov 2003 16:40:21 -0500

Mark,

Your comments are valid.  In fact, it's SRTP that is one driver (but not the
only driver) for wanting to move to RTP.  But, I hesitate to mention SRTP
without discussing the use of SRTP.

Is there specific text that you'd like to propose.  If you propose it and
folks agree, I definitely have no objections to incorporating it.

Paul

---

From: Mark Baugher <[email-masked]>
Date: Thu, 06 Nov 2003 16:14:39 -0800

Paul
   I think the approach that you mentioned in the security consideration is 
good since it relies on the security consideration and security mechanisms 
found in RTP and SRTP.  What is needed is to specify what might be specific 
to the fax payload type with respect to SRTP.  I'd say that a short 32-bit 
tag is a SHOULD NOT for fax and not a MAY as it is with other applications 
owing to the fact that the effects of fraud are so much greater form 
certain fax applications than is generally true for voice.  I'd offer 
something like this.
"T38 is vulnerable to attacks that are common on other types of RTP 
payloads.  The security considerations and mechanisms of RTP and SRTP apply 
to T38.  Regarding SRTP configuration, fax payloads SHOULD NOT use an 
HMAC-SHA1 authentication tag that is shorter than 80 bits."

Mark

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 14 Nov 2003 17:00:24 -0500

Mark, Jean-Francois,

Taking your input and that of others, I've drafted the following text for
the "security considerations" section of this draft.  Please tell me if you
like this or suggest specific changes:

  T38 is vulnerable to attacks that are common to other types
  of RTP and SRTP payloads.  However, unlike audio, T.38 data
  may be manipulated in ways that are more obtrusive than
  audio.  As examples, rogue packets may cause
  transmission failure and manipulated packets may alter
  terminal identity.

  The security considerations discussed in the RTP [3] and
  SRTP [5] specification and any applicable RTP profile (for
  example, [9]) are applicable to T.38.  Regarding SRTP
  configuration, fax payloads SHOULD NOT use an HMAC-SHA1
  authentication tag that is shorter than 80 bits

Looking forward to your comments.

Paul

----- Original Message ----- 
From: "Mark Baugher" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: "Jean-Francois Mule" <[email-masked]>; <[email-masked]>; "Mats
Näslund" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Elisabetta Carrara (KI/EAB)"
<[email-masked]>
Sent: Thursday, November 06, 2003 7:14 PM
Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward

> > > >I'll let other folks comment on whether it is appropriate to not
address
> > > >the draft's connections with SRTP.
> > >
> > > >I would rather let you wordsmith my comments into something general
you
> > > >like on this one.