Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Mon, 2 Sep 2013 09:04:35 +0000

Hello Christer,

I did follow the T.38 development in ITU-T a couple of years, but I have to admit that I'm also missing the origins and history of T.4, T.30 and T.38 in the 1990 decade.

The original requirement for secure fax transport was subject of the application protocol itself (e.g. T.30) AFAIK. That's why T.38 is silent on that aspect.

The indication of RTP/SAVP in T.38 (2004) was listed just for completeness, but not really motivated by T.38 security requirements (Paul may correct me).

Further, we should only refer to T.38 2010 (due to the well known issue with V.34G3 fax).

That said, like to suggest following revision proposal to clause 1 and references, see below.

Regards,

Albrecht

PS

Cc'd ITU-T Q.15 SG16, which is technology owner of T.38 in current Study Period.

1.  Introduction

There are three transport options for T.38 fax-over-IP, called "T.38 transport modes" [ITU.T38.2010]. T.38 transport mode "UDPTL/UDP" [ITU.T38.1998] is the predominant protocol for fax transport in

   IP networks.  The protocol stack for fax transport using UDPTL is

   shown in Table 1.

                      +-----------------------------+

                      |           Protocol          |

                      +-----------------------------+

                      | Internet facsimile protocol |

                      +-----------------------------+

                      |            UDPTL            |

                      +-----------------------------+

                      |             UDP             |

                      +-----------------------------+

                      |              IP             |

                      +-----------------------------+

                Table 1: Protocol stack for UDPTL over UDP

T.38 itself does not support integrity and confidentiality protection, because supposed to be subject of the application layer.

NOTE 1: Encryption of end-to-end facsimile transfer between fax devices was/is historically part of the application layer, such as [ITU.T.30] in case of group 3 facsimile equipment (G3FE). See e.g., T.30 "Annex H - Security in facsimile G3 based on the RSA algorithm"

Hence, none of the three T.38 transport modes was required to support additional security.

NOTE 2: Keeping in mind that T.38 communication was/is normally limited between T.38 endpoints located in IP-PSTN gateways (due to G3FE) besides Internet-Aware Fax (IAF) devices).

UDPTL does not offer integrity and confidentiality protection.  To

   enable integrity and confidentiality protection, [ITU.T38.2004]

   specifies fax transport over RTP/SAVP.  However, fax transport over

   RTP/SAVP is not widely supported.

   The 3rd Generation Partnership Project (3GPP) has performed a study

   on how to provide secure fax in the IP Multimedia Subsystem (IMS),  which concluded that secure fax shall be transported using UDPTL over

   DTLS.

NOTE 3: Because, 1st limited end-to-end scope ("IMS domain only") and 2nd support of transport security due to the assumption of unsecured facsimile data at application layer.

...

   [ITU.T38.1998]
              International Telecommunications Union, "Procedures for
              real time Group 3 facsimile communication between
              terminals using IP Networks", ITU-T Recommendation T.38,
              1998.

   [ITU.T38.2004]
              International Telecommunications Union, "Procedures for
              real-time Group 3 facsimile communication over IP
              networks", ITU-T Recommendation T.38, 2004.

   [ITU.T38.2010]

              International Telecommunications Union, "Procedures for

              real time Group 3 facsimile communication between

              terminals using IP Networks", ITU-T Recommendation T.38,

              2010.

https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-T.38-201009-I!!PDF-E&type=items

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Dan,

The protocols listed in draft-ietf-tls-applayerprotoneg-01 are used without SIP/SDP, so using such mechanism makes sense for those protocols.

In SIP, SDP is used to negotiate the media (including nonsecure fax), and I see no reason why we should introduce a new mechanism for secure fax.

Regards,

Christer

-----Original Message-----

From: Dan Wing [mailto:[email-masked]]

Sent: 28. elokuuta 2013 20:41

To: Christer Holmberg

Cc: mmusic WG

Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

On Aug 22, 2013, at 2:37 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

> Hi Dan,

> Regarding the 3GPP SA3 study, the information I gave was a little misleading. From a security perspective SRTP would be fine.

> The focus of the SA3 study was on how to provide security for the existing fax transmission mechanism, which uses UDPTL/UDP.

> 3GPP already mandates IMS terminals to support UDPTL/UDP for unsecure fax. And, new terminals (supporting secure fax) are still required to also support unsecure fax, in order to communicate with legacy terminals when unsecure fax is sufficient.

> So, using UDPTL/DTLS/UDP for secure fax makes more sense, as it avoids implementing different mechanisms for secure and unsecure fax - UDPTL/DTLS/UDP only requires a new layer between UDPTL and UDP, it does not require changing the upper layers (UDPTL and above).

> Hopefully this clarifies :)

(Sorry for my delay.  I was on vacation.)

Thanks for the clarification.

Back to your document, it says:

   Since the DTLS record layer "application_data" packet does not

   indicate whether it carries UDPTL, or some other protocol, the usage

   of a dedicated DTLS association for transport of UDPTL needs to be

   negotiated, e.g. using the Session Description Protocol (SDP)

   [RFC4566] and the SDP offer/answer mechanism [RFC3264].

   Therefore, this document specifies a new <proto> value [RFC4566] for

   the SDP "m=" line [RFC3264], in order to indicate UDPTL over DTLS in

   SDP messages [RFC4566].

Have you considered doing UDPTL negotiation in the DTLS handshake itself, using http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg?  That seems ideally suited for indicating the application layer protocol, perhaps in addition to the SDP signaling described in your I-D.

-d

> Regards,

> Christer

> -----Original Message-----

> From: Dan Wing [mailto:[email-masked]]

> Sent: 19. elokuuta 2013 20:43

> To: Christer Holmberg

> Cc: mmusic; [email-masked]<mailto:[email-masked]>

> Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

> On Aug 19, 2013, at 6:03 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

>> Hi,

>> We have submitted a new draft, draft-holmberg-mmusic-udptl-dtls-00, which defines usage of UDPTL over DTLS, in order to provide secure fax.

>> The draft was previously submitted to DISPATCH. Based on discussions with the ADs and chairs, it was decided that it shall be submitted to MMUSIC (note that no DTLS extensions are needed).

>> As is indicated in the draft, 3GPP has performed a study on how to

>> provide secure fax in the IMS, and the outcome was that secure fax shall be transported using UDPTL over DTLS.

> Got a pointer to that study?  Seems easier to carry UDPTL over RTP, which would allow the RTP to be secured using SRTP (and thus the UDPTL would be secured using SRTP).  There is a spec floating around to do exactly that (carry fax over RTP so that SRTP can secure it).  Advantage of using SRTP to secure fax is it separates the keying mechanism from security, so that Security Descriptions / MIKEY / DTLS-SRTP / whatever-is-invented-in-2020 will work just as effectively for voice as for fax.  And also that upgrading from a voice call to a "fax" call has no additional complexities due to security ("please press START to begin the fax transmission").

> -d

>> However, there is nothing "3GPP/IMS specific" about the mechanism, as UDPTL is commonly used for fax also elsewhere.

>> Regards,

>> Christer

>> _______________________________________________

>> mmusic mailing list

>> [email-masked]<mailto:[email-masked]>

>> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________

mmusic mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 2 Sep 2013 20:01:06 -0400

Folks,

RTP was introduced primarily for use with SRTP, but it was not specified for
use with SRTP since there was contention with respect to how keying material
would be exchanged (e.g., SDES or something else).  The more important part
was just defining how to replace UDPTL as a transport.

During that time, we were also exploring why T.38 fax failed so often, an
area of work that seems to never end.  The biggest challenge with FoIP has
been timer expiry, corruption, and collisions on TDM links.  Fax machines
are sometimes slow to reply, there is delay end-to-end, and there are
sometimes gateways in the path that introduce a lot of delay.  All of those
have been contributors to timer expiry and failed fax calls.  In some
testing we did, we even saw T.38 converted to audio and then carried via
G.729.  As you can imagine, the end result was not very desirable.

So, T.38/RTP and Voice Band Data (VBD) (V.152) work was done to try to
address some of the transport issues we were seeing, not only with fax, but
also with other kinds of modulated signals.

Use of RTP would have been better than UDPTL for security reasons, of
course.  DTLS is certainly a possible candidate today, though not having
RTCP means that there is still some opportunity for packet loss to go
undetected.  We wanted those properties of RTP to help troubleshoot the
network - properties completely lacking in UDPTL.  (Yes, missing information
can be detected, but missing information might be a TDM-link issue or an IP
packet loss issue.  UDPTL cannot differentiate.)

Paul

PS - I fully support the use of PDF over SMTP, BTW. It really gives
customers a lot fewer headaches.

From: Schwarz, Albrecht (Albrecht)
[mailto:[email-masked]] 
Sent: Monday, September 02, 2013 5:05 AM
To: Christer Holmberg
Cc: mmusic WG; [email-masked]; Paul E. Jones
Subject: RE: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hello Christer,

I did follow the T.38 development in ITU-T a couple of years, but I have to
admit that I'm also missing the origins and history of T.4, T.30 and T.38 in
the 1990 decade.

The original requirement for secure fax transport was subject of the
application protocol itself (e.g. T.30) AFAIK. That's why T.38 is silent on
that aspect.

The indication of RTP/SAVP in T.38 (2004) was listed just for completeness,
but not really motivated by T.38 security requirements (Paul may correct
me).

Further, we should only refer to T.38 2010 (due to the well known issue with
V.34G3 fax).

That said, like to suggest following revision proposal to clause 1 and
references, see below.

Regards,

Albrecht

PS

Cc'd ITU-T Q.15 SG16, which is technology owner of T.38 in current Study
Period.

1.  Introduction
 
There are three transport options for T.38 fax-over-IP, called "T.38
transport modes" [ITU.T38.2010]. T.38 transport mode "UDPTL/UDP"
[ITU.T38.1998] is the predominant protocol for fax transport in
   IP networks.  The protocol stack for fax transport using UDPTL is
   shown in Table 1.

 
T.38 itself does not support integrity and confidentiality protection,
because supposed to be subject of the application layer.  
 
NOTE 1: Encryption of end-to-end facsimile transfer between fax devices
was/is historically part of the application layer, such as [ITU.T.30] in
case of group 3 facsimile equipment (G3FE). See e.g., T.30 "Annex H -
Security in facsimile G3 based on the RSA algorithm"
 
Hence, none of the three T.38 transport modes was required to support
additional security.
 
NOTE 2: Keeping in mind that T.38 communication was/is normally limited
between T.38 endpoints located in IP-PSTN gateways (due to G3FE) besides
Internet-Aware Fax (IAF) devices). 

   The 3rd Generation Partnership Project (3GPP) has performed a study
   on how to provide secure fax in the IP Multimedia Subsystem (IMS),  which
concluded that secure fax shall be transported using UDPTL over
   DTLS.
NOTE 3: Because, 1st limited end-to-end scope ("IMS domain only") and 2nd
support of transport security due to the assumption of unsecured facsimile
data at application layer. 

.

   [ITU.T38.1998]

              1998.

   [ITU.T38.2004]

   [ITU.T38.2010]
              International Telecommunications Union, "Procedures for
              real time Group 3 facsimile communication between
              terminals using IP Networks", ITU-T Recommendation T.38,
              2010.
https://www.itu.int/rec/dologin_pub.asp?lang=e
<https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-T.38-201009-I!!PDF-
E&type=items> &id=T-REC-T.38-201009-I!!PDF-E&type=items 

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Dan,

The protocols listed in draft-ietf-tls-applayerprotoneg-01 are used without
SIP/SDP, so using such mechanism makes sense for those protocols.

In SIP, SDP is used to negotiate the media (including nonsecure fax), and I
see no reason why we should introduce a new mechanism for secure fax. 

Regards,

Christer

-----Original Message-----

From: Dan Wing [ <mailto:[email-masked]> mailto:[email-masked]] 

To: Christer Holmberg

Cc: mmusic WG

 

On Aug 22, 2013, at 2:37 AM, Christer Holmberg <
<mailto:[email-masked]> [email-masked]>

> Regarding the 3GPP SA3 study, the information I gave was a little
misleading. From a security perspective SRTP would be fine.

> The focus of the SA3 study was on how to provide security for the existing
fax transmission mechanism, which uses UDPTL/UDP.

> 3GPP already mandates IMS terminals to support UDPTL/UDP for unsecure fax.
And, new terminals (supporting secure fax) are still required to also
support unsecure fax, in order to communicate with legacy terminals when
unsecure fax is sufficient. 

> So, using UDPTL/DTLS/UDP for secure fax makes more sense, as it avoids
implementing different mechanisms for secure and unsecure fax -
UDPTL/DTLS/UDP only requires a new layer between UDPTL and UDP, it does not
require changing the upper layers (UDPTL and above).

 

   SDP messages [RFC4566].

Have you considered doing UDPTL negotiation in the DTLS handshake itself,
using  <http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg>
http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg?  That seems
ideally suited for indicating the application layer protocol, perhaps in
addition to the SDP signaling described in your I-D.

-d

> From: Dan Wing [ <mailto:[email-masked]> mailto:[email-masked]]

> Cc: mmusic;  <mailto:[email-masked]>
[email-masked]

> On Aug 19, 2013, at 6:03 AM, Christer Holmberg <
<mailto:[email-masked]> [email-masked]>
wrote:

>> We have submitted a new draft, draft-holmberg-mmusic-udptl-dtls-00, which
defines usage of UDPTL over DTLS, in order to provide secure fax.

>> The draft was previously submitted to DISPATCH. Based on discussions with
the ADs and chairs, it was decided that it shall be submitted to MMUSIC
(note that no DTLS extensions are needed).

> Got a pointer to that study?  Seems easier to carry UDPTL over RTP, which
would allow the RTP to be secured using SRTP (and thus the UDPTL would be
secured using SRTP).  There is a spec floating around to do exactly that
(carry fax over RTP so that SRTP can secure it).  Advantage of using SRTP to
secure fax is it separates the keying mechanism from security, so that
Security Descriptions / MIKEY / DTLS-SRTP / whatever-is-invented-in-2020
will work just as effectively for voice as for fax.  And also that upgrading
from a voice call to a "fax" call has no additional complexities due to
security ("please press START to begin the fax transmission").

>> However, there is nothing "3GPP/IMS specific" about the mechanism, as
UDPTL is commonly used for fax also elsewhere.

>>  <mailto:[email-masked]> [email-masked]

>>  <https://www.ietf.org/mailman/listinfo/mmusic>

mmusic mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/mmusic>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Sep 2013 10:57:12 +0000

Hi Paul,

You provide interesting input. However, 3GPP has chosen UDPTL as the transport protocol for FoIP (and, as others have also indicated, UDPTL is also the most common transport protocol for FoIP).

If you want to change the transport protocol for FoIP used in 3GPP, please talk to your 3GPP folks. I don't think this is the place.

The scope of the draft, and the work that we suggest, is to provide DTLS security on top of the already used transport protocol for FoIP (i.e. UDPTL).

Regards,

Christer

Lähettäjä: Paul E. Jones [mailto:[email-masked]]
Lähetetty: 3. syyskuuta 2013 3:01
Vastaanottaja: 'Schwarz, Albrecht (Albrecht)'; Christer Holmberg
Kopio: 'mmusic WG'; [email-masked]
Aihe: RE: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Folks,

RTP was introduced primarily for use with SRTP, but it was not specified for use with SRTP since there was contention with respect to how keying material would be exchanged (e.g., SDES or something else).  The more important part was just defining how to replace UDPTL as a transport.

During that time, we were also exploring why T.38 fax failed so often, an area of work that seems to never end.  The biggest challenge with FoIP has been timer expiry, corruption, and collisions on TDM links.  Fax machines are sometimes slow to reply, there is delay end-to-end, and there are sometimes gateways in the path that introduce a lot of delay.  All of those have been contributors to timer expiry and failed fax calls.  In some testing we did, we even saw T.38 converted to audio and then carried via G.729.  As you can imagine, the end result was not very desirable.

So, T.38/RTP and Voice Band Data (VBD) (V.152) work was done to try to address some of the transport issues we were seeing, not only with fax, but also with other kinds of modulated signals.

Use of RTP would have been better than UDPTL for security reasons, of course.  DTLS is certainly a possible candidate today, though not having RTCP means that there is still some opportunity for packet loss to go undetected.  We wanted those properties of RTP to help troubleshoot the network - properties completely lacking in UDPTL.  (Yes, missing information can be detected, but missing information might be a TDM-link issue or an IP packet loss issue.  UDPTL cannot differentiate.)

Paul

PS - I fully support the use of PDF over SMTP, BTW. It really gives customers a lot fewer headaches.

From: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Sent: Monday, September 02, 2013 5:05 AM
To: Christer Holmberg
Cc: mmusic WG; [email-masked]<mailto:[email-masked]>; Paul E. Jones
Subject: RE: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hello Christer,

Regards,

Albrecht

PS

1.  Introduction

   shown in Table 1.

                      |           Protocol          |

                      |            UDPTL            |

                      |             UDP             |

                      |              IP             |

   DTLS.

...

   [ITU.T38.1998]

   [ITU.T38.2004]

   [ITU.T38.2010]

              2010.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Dan,

Regards,

Christer

-----Original Message-----

To: Christer Holmberg

Cc: mmusic WG

   SDP messages [RFC4566].

-d

mmusic mailing list

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 3 Sep 2013 11:15:30 -0400

Christer,

I’m not trying to change the transport protocol.  I was asked about the
history of the RTP addition to T.38, so I provided that information along
with some of the reasons it was introduced.

That said, I do think it’s reasonable to consider using RTP if 3GPP is
considering using DTLS.  After all, DTLS is a change in transports, just as
using RTP would be.  Whether that is using RTP/DTLS or SRTP for security,
there are benefits in using RTP, such as the ability to report packet loss,
delay, jitter, etc. as is done for other RTP flows.  Plus, it would be
possible to switch between voice and fax within the same RTP media flow.

In any case, I was just asked for the history and I gave it.

Paul

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, September 03, 2013 6:57 AM
To: Paul E. Jones; 'Schwarz, Albrecht (Albrecht)'
Cc: 'mmusic WG'; [email-masked]
Subject: VS: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Paul,

You provide interesting input. However, 3GPP has chosen UDPTL as the
transport protocol for FoIP (and, as others have also indicated, UDPTL is
also the most common transport protocol for FoIP).

If you want to change the transport protocol for FoIP used in 3GPP, please
talk to your 3GPP folks. I don’t think this is the place.

The scope of the draft, and the work that we suggest, is to provide DTLS
security on top of the already used transport protocol for FoIP (i.e.
UDPTL).

Regards,

Christer

Lähettäjä: Paul E. Jones [ <mailto:[email-masked]>
mailto:[email-masked]] 
Lähetetty: 3. syyskuuta 2013 3:01
Vastaanottaja: 'Schwarz, Albrecht (Albrecht)'; Christer Holmberg
Kopio: 'mmusic WG';  <mailto:[email-masked]>
[email-masked]
Aihe: RE: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Folks,

network – properties completely lacking in UDPTL.  (Yes, missing information

Paul

PS – I fully support the use of PDF over SMTP, BTW. It really gives
customers a lot fewer headaches.

Cc: mmusic WG; [email-masked] <mailto:[email-masked]> ;
Paul E. Jones

Hello Christer,

I did follow the T.38 development in ITU-T a couple of years, but I have to
admit that I’m also missing the origins and history of T.4, T.30 and T.38 in
the 1990 decade.

The original requirement for secure fax transport was subject of the
application protocol itself (e.g. T.30) AFAIK. That’s why T.38 is silent on
that aspect.

Regards,

Albrecht

PS

Cc’d ITU-T Q.15 SG16, which is technology owner of T.38 in current Study
Period.

1.  Introduction
 
There are three transport options for T.38 fax-over-IP, called “T.38
transport modes” [ITU.T38.2010]. T.38 transport mode “UDPTL/UDP”
[ITU.T38.1998] is the predominant protocol for fax transport in
   IP networks.  The protocol stack for fax transport using UDPTL is
   shown in Table 1.

 
 
NOTE 1: Encryption of end-to-end facsimile transfer between fax devices
was/is historically part of the application layer, such as [ITU.T.30] in
case of group 3 facsimile equipment (G3FE). See e.g., T.30 “Annex H -
Security in facsimile G3 based on the RSA algorithm”

   
 
NOTE 3: Because, 1st limited end-to-end scope (“IMS domain only”) and 2nd

…

   [ITU.T38.1998]

              1998.

   [ITU.T38.2004]

   [ITU.T38.2010]
 
<https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-T.38-201009-I!!PDF-
E&type=items>
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-T.38-201009-I!!PDF-E
&type=items 

-----Original Message-----
From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf
Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Dan,

Regards,

Christer

-----Original Message-----

To: Christer Holmberg

Cc: mmusic WG

 

 

   SDP messages [RFC4566].

-d

wrote:

mmusic mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Sep 2013 15:36:26 +0000

Hi Paul,

>I'm not trying to change the transport protocol.  I was asked about the history of the RTP addition to T.38, so I provided that information along with some of the reasons it was introduced.
>
>That said, I do think it's reasonable to consider using RTP if 3GPP is considering using DTLS.  After all, DTLS is a change in transports, just as using RTP would be.  Whether that is using RTP/DTLS or
>SRTP for security, there are benefits in using RTP, such as the ability to report packet loss, delay, jitter, etc. as is done for other RTP flows.  Plus, it would be possible to switch between voice and fax within the same RTP media flow.

I am sure 3GPP took all those things into consideration when selecting the transport protocol for unsecure fax, and how they want to provide secure fax :)

And, as I said earlier, there is a 3GPP requirement for new terminals, supporting secure fax, to be able to communicate (in cases where non-secure fax is considered sufficient) with existing terminals that do not support secure fax, so they will have to support UDPTL for unsecure fax anyway.

>In any case, I was just asked for the history and I gave it.

I appreciate the fact that you did :)

Regards,

Christer

Cc: 'mmusic WG'; [email-masked]<mailto:[email-masked]>

Hi Paul,

Regards,

Christer

Kopio: 'mmusic WG'; [email-masked]<mailto:[email-masked]>

Folks,

Paul

Hello Christer,

Regards,

Albrecht

PS

1.  Introduction

   shown in Table 1.

                      |           Protocol          |

                      |            UDPTL            |

                      |             UDP             |

                      |              IP             |

   DTLS.

...

   [ITU.T38.1998]

   [ITU.T38.2004]

   [ITU.T38.2010]

              2010.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Dan,

Regards,

Christer

-----Original Message-----

To: Christer Holmberg

Cc: mmusic WG

   SDP messages [RFC4566].

-d

mmusic mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Sep 2013 07:36:05 +0000

Hi Paul,

I seems like my previous reply didn't show up on the MMUSIC list, so I re-send.

Regards,

Christer

Hi Paul,

Regards,

Christer

Folks,

Paul

Hello Christer,

Regards,

Albrecht

PS

1.  Introduction

   shown in Table 1.

                      |           Protocol          |

                      |            UDPTL            |

                      |             UDP             |

                      |              IP             |

   DTLS.

...

   [ITU.T38.1998]

   [ITU.T38.2004]

   [ITU.T38.2010]

              2010.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Dan,

Regards,

Christer

-----Original Message-----

To: Christer Holmberg

Cc: mmusic WG

   SDP messages [RFC4566].

-d

mmusic mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Sep 2013 13:17:50 +0000

Hi Albrecht,
 
I DO agree that we should refer to the latest version (2010) of T.38, but I don't think your other assumptions are correct.
 
T.38 [2010] does specify more than 3 methods - including the usage of SRTP. So, there is no assumption that security is always provided by the application layer (maybe that was the case in the past).
 
In a similar way, there is nowhere indicated that 3GPP would make a similar assumption.
 
Regards,
 
Christer

From: Schwarz, Albrecht (Albrecht) [[email-masked]]
Sent: Wednesday, 04 September 2013 4:11 PM
To: Christer Holmberg; Paul E. Jones; [email-masked]
Cc: [email-masked]
Subject: RE: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Thanks Paul for background info about the RTP/UDP transport option, appreciated!

Hi Christer,
thus, do you agree to my update proposals for “draft-holmberg-mmusic-udptl-dtls”? (Which are consistent with Paul’s view in my understanding)

Regards,
Albrecht

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Mittwoch, 4. September 2013 09:36
To: Paul E. Jones; Schwarz, Albrecht (Albrecht); [email-masked]
Cc: [email-masked]
Subject: VS: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Paul,

I seems like my previous reply didn’t show up on the MMUSIC list, so I re-send.

>I’m not trying to change the transport protocol.  I was asked about the history of the RTP addition to T.38, so I provided that information along with some of the reasons it was introduced.
> 
>That said, I do think it’s reasonable to consider using RTP if 3GPP is considering using DTLS.  After all, DTLS is a change in transports, just as using RTP would be.  Whether that is using RTP/DTLS or 

Regards,

Christer

Hi Paul,

If you want to change the transport protocol for FoIP used in 3GPP, please talk to your 3GPP folks. I don’t think this is the place.

Regards,

Christer

Folks,

Use of RTP would have been better than UDPTL for security reasons, of course.  DTLS is certainly a possible candidate today, though not having RTCP means that there is still some opportunity for packet loss to go undetected.  We wanted those properties of RTP to help troubleshoot the network – properties completely lacking in UDPTL.  (Yes, missing information can be detected, but missing information might be a TDM-link issue or an IP packet loss issue.  UDPTL cannot differentiate.)

Paul

PS – I fully support the use of PDF over SMTP, BTW. It really gives customers a lot fewer headaches.

Hello Christer,
I did follow the T.38 development in ITU-T a couple of years, but I have to admit that I’m also missing the origins and history of T.4, T.30 and T.38 in the 1990 decade.
The original requirement for secure fax transport was subject of the application protocol itself (e.g. T.30) AFAIK. That’s why T.38 is silent on that aspect.
The indication of RTP/SAVP in T.38 (2004) was listed just for completeness, but not really motivated by T.38 security requirements (Paul may correct me).
Further, we should only refer to T.38 2010 (due to the well known issue with V.34G3 fax).

PS
Cc’d ITU-T Q.15 SG16, which is technology owner of T.38 in current Study Period.

1.  Introduction
 
There are three transport options for T.38 fax-over-IP, called “T.38 transport modes” [ITU.T38.2010]. T.38 transport mode “UDPTL/UDP” [ITU.T38.1998] is the predominant protocol for fax transport in
   IP networks.  The protocol stack for fax transport using UDPTL is
   shown in Table 1.

 
 
NOTE 1: Encryption of end-to-end facsimile transfer between fax devices was/is historically part of the application layer, such as [ITU.T.30] in case of group 3 facsimile equipment (G3FE). See e.g., T.30 “Annex H - Security in facsimile G3 based on the RSA algorithm”

   
 
   The 3rd Generation Partnership Project (3GPP) has performed a study
   on how to provide secure fax in the IP Multimedia Subsystem (IMS),  which concluded that secure fax shall be transported using UDPTL over
   DTLS.
NOTE 3: Because, 1st limited end-to-end scope (“IMS domain only”) and 2nd support of transport security due to the assumption of unsecured facsimile data at application layer. 

…

   [ITU.T38.1998]

   [ITU.T38.2004]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Dan,

Regards,

Christer

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: 28. elokuuta 2013 20:41
To: Christer Holmberg
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

-d

> Cc: mmusic; [email-masked]
> On Aug 19, 2013, at 6:03 AM, Christer Holmberg <[email-masked]> wrote:
> 
>> Hi,
>> 
>> [email-masked]

[email-masked]

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 4 Sep 2013 13:11:26 +0000

Hi Christer,
thus, do you agree to my update proposals for "draft-holmberg-mmusic-udptl-dtls"? (Which are consistent with Paul's view in my understanding)

Regards,
Albrecht

Hi Paul,

Regards,

Christer

Hi Paul,

Regards,

Christer

Folks,

Paul

Hello Christer,

Regards,

Albrecht

PS

1.  Introduction

   shown in Table 1.

                      |           Protocol          |

                      |            UDPTL            |

                      |             UDP             |

                      |              IP             |

   DTLS.

...

   [ITU.T38.1998]

   [ITU.T38.2004]

   [ITU.T38.2010]

              2010.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Dan,

Regards,

Christer

-----Original Message-----

To: Christer Holmberg

Cc: mmusic WG

   SDP messages [RFC4566].

-d

mmusic mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Sep 2013 13:16:39 +0000

Hi Albrecht,

Regards,

Christer

________________________________

Hi Christer,

Regards,
Albrecht

Hi Paul,

Regards,

Christer

Hi Paul,

Regards,

Christer

Folks,

Paul

Hello Christer,

Regards,

Albrecht

PS

1.  Introduction

   shown in Table 1.

                      |           Protocol          |

                      |            UDPTL            |

                      |             UDP             |

                      |              IP             |

   DTLS.

…

   [ITU.T38.1998]

   [ITU.T38.2004]

   [ITU.T38.2010]

              2010.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Dan,

Regards,

Christer

-----Original Message-----

To: Christer Holmberg

Cc: mmusic WG

   SDP messages [RFC4566].

-d

mmusic mailing list

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 4 Sep 2013 13:38:33 +0000

Hello Christer,

wrt "T.38 transport mode":
I did not use the term "method", rather intentionally the notion of "T.38 transport mode".
=> introduced in Annex D.2.1.2/T.38 [2010]
=> more important: used in Annex H/T.38 [2010], see Table H.1

There are three T.38 transport modes.
T.38 essentially does not restrict the usage of any "RTP profile" for T.38 transport mode "RTP/UDP" (Annex D.2.3.4).
Hence, I would talk about a *variation* of a T.38 transport mode (when using RTP profile "SAVP", "AVPF", etc instead of "AVP").

wrt "application- vs transport-level security for fax":
Agreed. Such background/historical information should be provided by ITU-T (e.g. as a Supplement or Addendum to T.38). The usual clause on "Security considerations" of ITU-T Recs is missing in T.38.

Regards,
Albrecht

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Mittwoch, 4. September 2013 15:18
To: Schwarz, Albrecht (Albrecht); Paul E. Jones; [email-masked]
Cc: [email-masked]
Subject: RE: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Albrecht,

 
 
Regards,
 
Christer

Hi Christer,

Regards,
Albrecht

Hi Paul,

>That said, I do think it's reasonable to consider using RTP if 3GPP is 
>considering using DTLS.  After all, DTLS is a change in transports, just as using RTP would be.  Whether that is using RTP/DTLS or SRTP for security, there are benefits in using RTP, such as the ability to report packet loss, delay, jitter, etc. as is done for other RTP flows.  Plus, it would be possible to switch between voice and fax within the same RTP media flow.

Regards,

Christer

Hi Paul,

Regards,

Christer

Folks,

Paul

Hello Christer,

PS

1.  Introduction

 

 

 

.

   [ITU.T38.1998]

   [ITU.T38.2004]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Dan,

Regards,

Christer

-----Original Message-----
From: Dan Wing [mailto:[email-masked]]
Sent: 28. elokuuta 2013 20:41
To: Christer Holmberg
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

-d

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Sep 2013 13:51:58 +0000

Hi Albrecht,

We can mention what security mechanisms exist for other T.38 transport modes, and add a reference to where they are defined.

Regards,

Christer

________________________________________
From: Schwarz, Albrecht (Albrecht) [[email-masked]]
Sent: Wednesday, 04 September 2013 4:38 PM
To: Christer Holmberg; Paul E. Jones; [email-masked]
Cc: [email-masked]
Subject: RE: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hello Christer,

Regards,
Albrecht

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Mittwoch, 4. September 2013 15:18
To: Schwarz, Albrecht (Albrecht); Paul E. Jones; [email-masked]
Cc: [email-masked]
Subject: RE: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Albrecht,

Regards,

Christer

Hi Christer,

Regards,
Albrecht

Hi Paul,

Regards,

Christer

Hi Paul,

Regards,

Christer

Folks,

Paul

Hello Christer,

PS

1.  Introduction

.

   [ITU.T38.1998]

   [ITU.T38.2004]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi Dan,

Regards,

Christer

-----Original Message-----
From: Dan Wing [mailto:[email-masked]]
Sent: 28. elokuuta 2013 20:41
To: Christer Holmberg
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

-d

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 10 Sep 2013 17:10:31 +0000

Thanks James for sharing this information on technology history!
Actually it confirms my assumptions concerning the original approach wrt security support (T.30).

I would consider T.30 still an end-to-end protocol, - whether (a) transported natively entire over an end-to-end PSTN domain, or (b) if "emulated" by T.38 for any interim IP segment.
Because the transported facsimile image(s) itself are the same for each scenario ("T.38 does not do any "transcoding for image data").

Hence, we could differentiate between application-, transport- and network-level security in case of facsimile traffic.
T.30 could be considered as application protocol.
The described T.30 security tools by you would be then application-level security, which is applicable on (a) and (b) in principle.

The T.38 protocol stack, - T.30/IFP/"T.38 transport mode"/IP/L2 -, could be categorized in:
1) application protocol = T.30
2) application-level framing (ALF) protocol = "IFP/UDPTL" | "IFP/RTP" | "IFP" (for the three T.38 transport modes)
3) transport protocol = UDP | TCP
and
4) network protocol = IP

Essentially, security support would be possible at all four levels (in case of T.38 "RTP/UDP" transport).
In case of 3GPP remain (1) application level security (= T.30 ...) and (3) transport level security (= DTLS) due to T.38 "UDPTL/UDP" transport and the exclusion of IPsec as network level security.

Regards,
Albrecht

From: James Rafferty [mailto:[email-masked]] 
Sent: Montag, 9. September 2013 19:42
To: Christer Holmberg
Cc: Schwarz, Albrecht (Albrecht); Paul E. Jones; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

Hi, 

I can fill in history gaps about the activities re: T.30 et al in the Nineties, since I was an active member of SG8 at the time when we were adding security to T.30.   

There were 2 security initiatives for T.30 during this period and they were both adopted in the 1996 version of T.30.  Albrecht notes the Annex H based on use of RSA (for which I helped write the protocol portions) and there was an additional annex G produced using a secret key (HKM/HFX) method.  

However, the marketplace did not adopt either of these approaches to fax security.  One likely reason was due to other priorities.  Both V.34 fax and IP fax were becoming active at this time in the ITU and the members were much more focused on these efforts.   V.34 fax was adopted in short order over the next few years, but adoption of both T.37 and T.38 were slow.  Eventually, T.38 did catch on, since it fit in well with Voice over IP, and several of us worked to ensure that the T.38 annex supporting SIP was adopted by the ITU around the year 2000.   

I think it would have been great if the ITU-T had adopted RTP in 1998 instead of UDPTL, but the fax community was given some bad advice and decided to build UDPTL on top of UDP.  The limitations of this approach became obvious when many enhancements were made to the RTP / RTCP protocols (such as SRTP) and UDPTL was not able to take advantage of any of them.  

Paul and others helped drive the addition of T.38 over RTP in 2004, but by this time, the fax industry had already begun to adopt UDPTL widely and there is minimal support of T.38 over RTP in the marketplace today as far as I know.  For example, my former employer Dialogic sells a lot of T.38 fax over IP and has even added support for V.34 over T.38 (also approved in 2004), but does not support the RTP transport mode.   

In summary, I think adding a DTLS security layer as Christer has suggested does make lots of sense and stands a good chance to get adopted in the marketplace if standardized.   The companies selling fax and their customers are beginning to get more interested in security based on things I've been hearing from the software vendors, so this kind of addition is timely.  

James

On 9/4/2013 9:16 AM, Christer Holmberg wrote:
Hi Albrecht,

 
 
Regards,
 
Christer

Hi Christer,
 
Regards,
Albrecht

Hi Paul,

 

 
Regards,
 
Christer

Hi Paul,

Regards,

Christer

Folks,

 

Paul

 
Hello Christer,

PS

1.  Introduction

 

 

 

.
 
   [ITU.T38.1998]
 
   [ITU.T38.2004]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00
 
Hi Dan,

 
Regards,
 
Christer

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: 28. elokuuta 2013 20:41
To: Christer Holmberg
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

 

 

 
-d

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Sep 2013 17:50:36 +0000

Hi,

>In case of 3GPP remain (1) application level security (= T.30 ...) and (3) transport level security (= DTLS) due to T.38 "UDPTL/UDP" transport and the exclusion of IPsec as network level security.

3GPP has already chosen on which "level" they want to provide fax security.

But, I have no problem to mention T.30 in the introduction part of the draft.

Regards,

Christer

Hi, 

James

 

Regards,
 
Christer

Hi Christer,
 
Regards,
Albrecht

Hi Paul,

 

 
Regards,
 
Christer

Hi Paul,

Regards,

Christer

Folks,

 

Paul

 
Hello Christer,

PS

1.  Introduction

 

 

 

.
 
   [ITU.T38.1998]
 
   [ITU.T38.2004]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 29. August 2013 10:17
To: Dan Wing
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00
 
Hi Dan,

 
Regards,
 
Christer

-----Original Message-----
From: Dan Wing [mailto:[email-masked]]
Sent: 28. elokuuta 2013 20:41
To: Christer Holmberg
Cc: mmusic WG
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00

 

 

 
-d