Subject: [straw] DTLS-SRTP relay + forking

From: Simon Perreault <[email-masked]>
Date: Wed, 20 May 2015 11:58:03 -0400

Thinking a little bit more about forking, there is something important
that I think needs to be added to the draft.

Topology graph:

A ---------------- B2BUA ---------------+---- B
                                        |
                                        +---- C

A call from A is relayed by the B2BUA and then gets forked to B and C.

DTLS-SRTP deals with 5-tuples pretty intimately. First, the DTLS
connection is on its own 5-tuple. Having multiple DTLS connections on
the same 5-tuple will not work. Therefore, when the B2BUA relays DTLS
packets from B and C back to A, it must use different 5-tuples. Since
the destination, A, will necessarily be the same, this means that
different source 3-tuples must be used by the B2BUA for packets relayed
from B and packets relayed from C.

Second, keying material extracted from a DTLS connection applies to SRTP
packets flowing on the same 5-tuple as the DTLS connection. Therefore,
different 5-tuples need to be used for SRTP pakets between A and the B2BUA.

What this all means is that the B2BUA needs to do some kind of
application-layer NAT. It needs to track remote sources (B, C, etc.) and
map them to local sources that are used to send packets to A.

Makes sense?

Simon

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 21 May 2015 04:39:49 +0000

Hi Simon,

Thanks for the input. You are right that for forking cases the B2BUA
should act like a NAT and create unique binding (on peer leg) for each
forked response.
Will add some text in the next revision.

Regards,
Ram

-----Original Message-----
From: Simon Perreault <[email-masked]>
Date: Wednesday, 20 May 2015 9:28 pm
To: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: DTLS-SRTP relay + forking
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>
Resent-Date: Wednesday, 20 May 2015 9:28 pm

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 21 May 2015 08:49:51 +0000

Hi Simon,

Attached diff of updated draft to address the comment. Please have a look.

Cheers,
-Tiru

> From: straw [mailto:[email-masked]] On Behalf Of Ram Mohan R
> (rmohanr)
> Sent: Thursday, May 21, 2015 10:10 AM
> To: Simon Perreault; [email-masked];
> [email-masked]
> Subject: Re: [straw] DTLS-SRTP relay + forking
> 
> Hi Simon,
> 
> Thanks for the input. You are right that for forking cases the B2BUA should act
> like a NAT and create unique binding (on peer leg) for each forked response.
> >Second, keying material extracted from a DTLS connection applies to
> >SRTP packets flowing on the same 5-tuple as the DTLS connection.
> >Therefore, different 5-tuples need to be used for SRTP pakets between A
> >and the B2BUA.
> >
> >application-layer NAT. It needs to track remote sources (B, C, etc.)
> >and map them to local sources that are used to send packets to A.
> >
> >Makes sense?
> >
> >Simon
> 
> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw

---

From: Simon Perreault <[email-masked]>
Date: Thu, 21 May 2015 12:15:49 -0400

> Attached diff of updated draft to address the comment. Please have a look.

Looks good! Thanks for the quick RTT!

One comment: "candidate" is ICE terminology. It would be better to use a
more generic term, e.g. 5-tuple or transport address.

Simon