Subject: [Perc] Open Issue: Tunnel Multiplexing

From: Adam Roach <[email-masked]>
Date: Wed, 27 Apr 2016 18:57:27 -0500

Following up from my other message, once we nail down how we're 
communicating between the KMF and the MDD, we need to decide how we 
represent the endpoint-to-KMF traffic on that interface.

For this message, I'm assuming that we're still planning to use a 
datagram-based interface between the KMF and MDD rather than a 
stream-based one. If that assumption does not hold, we'll need to 
revisit these issues.

On the call, I heard several different options, which I will attempt to 
summarize at a high level:

 1. DTLS/Tunnel/DTLS/UDP: Have the KMF establish one (or possibly more)
    DTLS association per conference, and then send the client-to-KMF
    packets inside that association as application data, and use the
    scheme described in draft-jones-perc-dtls-tunnel-02 to multiplex the
    client DTLS associations within this tunnel.

 2. Multiple DTLS/UDP: Have the KMF establish one DTLS association with
    the MDD for key management. The KMF will forward every DTLS packet
    received from clients to the KMF, in raw form, using a unique source
    port for each client.

 3. DTLS/SCTP/DTLS/UDP: Have the KMF establish one (or possibly more)
    DTLS association per conference, and run SCTP inside this DTLS
    association. Using one flow per client, tunnel client DTLS packets
    inside the SCTP association.

 4. DataChannel/SCTP/DTLS/UDP: Something like #3 but using WebRTC data
    channels. I think Richard would need to expand on this, since the
    deeper I go on trying to figure out the details, the less it holds
    up to scrutiny. I assume I've misunderstood something.

Compared against the status quo (#1):

#2 has the benefit of allowing the KMF to simply process inbound client 
packets using a stock DTLS stack, rather than having to worry about any 
kind of message encapsulation. It has the drawback of eating up 
substantial NAT/Firewall resources (ports and port bindings). It also 
has the lesser issues of requiring additional mechanism to associate the 
client connections with their conference (for KMFs that can serve more 
than one conference at a time), since the binding is not implicit (as it 
is with other approaches), and of requiring us to bolt reliability on to 
the MDD-to-KMF key management protocol.

#3 has the property (unless we work to avoid it) of decoupling the 
MDD-to-KMF protocol (communicating ciphersuites and selected keys) from 
the client-to-KMF messages, at the cost of requiring PERC endpoints and 
KMFs to include an SCTP stack. This is no big deal for WebRTC setups 
with co-located KMFs, but it may be unnecessarily complicated for 
non-WebRTC clients and for enterprise-hosted KMFs.

I think the idea behind #4 was to allow WebRTC endpoints that are 
serving as KMFs to use the DTLS association with the MDD as the KMF-MDD 
communication channel, but I'm not 100% certain. If such is the case, 
then we can reduce the number of DTLS associations between the 
endpoint/KMF and the MDD from two to one, at the cost of some design 
(and probably implementation) complexity. Like #3, it pushes SCTP onto 
endpoints and KMFs that might not otherwise need it, with the additional 
complication of also pushing the DataChannel protocol onto them. Again, 
I'll leave it to Richard to explain the approach and benefits, as I 
believe it was he who brought it up.

Regardless of whether we go with #4, there's a good chance that we could 
shoehorn any of the other approaches into re-using the DTLS-SRTP 
connection from a co-located endpoint/KMF for key management. I think 
we'd need to sketch out exactly how that would work before we weigh the 
impact of doing so against the value of having only one association.

What I most worry about with such an approach is that it basically 
results in two disparate modes of operation from an MDD perspective: one 
for a co-located KMF, and one for a non-co-located KMF. Once we have 
non-trivial protocol differences between these two network 
architectures, I fear we're going to rapidly get into situations where 
some MDDs will support only one style of conference and not the other, 
and will be difficult to adapt to support the other. We would 
effectively have two different protocols for performing the same 
function, which isn't generally good for interop.

/a

---

From: Christian Groves <[email-masked]>
Date: Fri, 29 Apr 2016 14:17:11 +1000

Hello Adam,

For 2 in the second sentence I assume you mean "The <MDD> will forward 
every DTLS packet
    received from clients to the KMF,.."?

For 4, I guess it also depends on whether clients will in general use 
datachannel towards the MDD given that the MDD isn't trusted. A client 
may need multiple DTLS associations for datachannels depending on the 
sub-protocol and peer-endpoints. Given this it doesn't seem onerous for 
the client to support an additional DTLS association for the co-located 
KMF/Client case if it means a common method for both co-located and 
non-located deployments.

Regards, Christian

On 28/04/2016 9:57 AM, Adam Roach wrote:
> On the call, I heard several different options, which I will attempt 
> to summarize at a high level:
>
> #2 has the benefit of allowing the KMF to simply process inbound 
> client packets using a stock DTLS stack, rather than having to worry 
> about any kind of message encapsulation. It has the drawback of eating 
> up substantial NAT/Firewall resources (ports and port bindings). It 
> also has the lesser issues of requiring additional mechanism to 
> associate the client connections with their conference (for KMFs that 
> can serve more than one conference at a time), since the binding is 
> not implicit (as it is with other approaches), and of requiring us to 
> bolt reliability on to the MDD-to-KMF key management protocol.
>
> MDD-to-KMF protocol (communicating ciphersuites and selected keys) 
> from the client-to-KMF messages, at the cost of requiring PERC 
> endpoints and KMFs to include an SCTP stack. This is no big deal for 
> WebRTC setups with co-located KMFs, but it may be unnecessarily 
> complicated for non-WebRTC clients and for enterprise-hosted KMFs.
>
> serving as KMFs to use the DTLS association with the MDD as the 
> KMF-MDD communication channel, but I'm not 100% certain. If such is 
> the case, then we can reduce the number of DTLS associations between 
> the endpoint/KMF and the MDD from two to one, at the cost of some 
> design (and probably implementation) complexity. Like #3, it pushes 
> SCTP onto endpoints and KMFs that might not otherwise need it, with 
> the additional complication of also pushing the DataChannel protocol 
> onto them. Again, I'll leave it to Richard to explain the approach and 
> benefits, as I believe it was he who brought it up.
>
> Regardless of whether we go with #4, there's a good chance that we 
> could shoehorn any of the other approaches into re-using the DTLS-SRTP 
> we'd need to sketch out exactly how that would work before we weigh 
> the impact of doing so against the value of having only one association.
>
> results in two disparate modes of operation from an MDD perspective: 
> one for a co-located KMF, and one for a non-co-located KMF. Once we 
> have non-trivial protocol differences between these two network 
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 29 Apr 2016 14:53:14 -0600

Good summary. 

#3 and #4 just seem to add complexity that is not needed. I prefer 1 as it seems like 2 can run into running out of ports issues on the KMF. 

> On Apr 27, 2016, at 5:57 PM, Adam Roach <[email-masked]> wrote:
> 
> Following up from my other message, once we nail down how we're communicating between the KMF and the MDD, we need to decide how we represent the endpoint-to-KMF traffic on that interface.
> 
> For this message, I'm assuming that we're still planning to use a datagram-based interface between the KMF and MDD rather than a stream-based one. If that assumption does not hold, we'll need to revisit these issues.
> 
> On the call, I heard several different options, which I will attempt to summarize at a high level:
> 
> #2 has the benefit of allowing the KMF to simply process inbound client packets using a stock DTLS stack, rather than having to worry about any kind of message encapsulation. It has the drawback of eating up substantial NAT/Firewall resources (ports and port bindings). It also has the lesser issues of requiring additional mechanism to associate the client connections with their conference (for KMFs that can serve more than one conference at a time), since the binding is not implicit (as it is with other approaches), and of requiring us to bolt reliability on to the MDD-to-KMF key management protocol.
> 
> #3 has the property (unless we work to avoid it) of decoupling the MDD-to-KMF protocol (communicating ciphersuites and selected keys) from the client-to-KMF messages, at the cost of requiring PERC endpoints and KMFs to include an SCTP stack. This is no big deal for WebRTC setups with co-located KMFs, but it may be unnecessarily complicated for non-WebRTC clients and for enterprise-hosted KMFs.
> 
> I think the idea behind #4 was to allow WebRTC endpoints that are serving as KMFs to use the DTLS association with the MDD as the KMF-MDD communication channel, but I'm not 100% certain. If such is the case, then we can reduce the number of DTLS associations between the endpoint/KMF and the MDD from two to one, at the cost of some design (and probably implementation) complexity. Like #3, it pushes SCTP onto endpoints and KMFs that might not otherwise need it, with the additional complication of also pushing the DataChannel protocol onto them. Again, I'll leave it to Richard to explain the approach and benefits, as I believe it was he who brought it up.
> 
> Regardless of whether we go with #4, there's a good chance that we could shoehorn any of the other approaches into re-using the DTLS-SRTP connection from a co-located endpoint/KMF for key management. I think we'd need to sketch out exactly how that would work before we weigh the impact of doing so against the value of having only one association.
> 
> What I most worry about with such an approach is that it basically results in two disparate modes of operation from an MDD perspective: one for a co-located KMF, and one for a non-co-located KMF. Once we have non-trivial protocol differences between these two network architectures, I fear we're going to rapidly get into situations where some MDDs will support only one style of conference and not the other, and will be difficult to adapt to support the other. We would effectively have two different protocols for performing the same function, which isn't generally good for interop.
> 
> /a
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 29 Apr 2016 15:03:47 -0600

> On Apr 29, 2016, at 2:53 PM, Cullen Jennings <[email-masked]> wrote:
> 

Oops - meant to say running out of ports on MDD not KMF. 

In #2, if you have a lot of endpoints behind a single CGN and each of these endpoints in running a KMF for a different conference, the MDD will need to make sure that each DTLS connection from the MDD to the KMF originates from  different port because the rest of the 5 tuple can be the same. And if the the MDD is supporting a lot of users across all the combined conferences, that might get large. 

You also have the issue of it is is easiest to set up the connection from KMF to MDD but the natural flow in 2 would be KMF to MDD which would take some extra work to get going.