Subject: [Perc] Open issue: TCP or UDP for the tunnel?

From: Adam Roach <[email-masked]>
Date: Wed, 27 Apr 2016 17:19:44 -0500

Today's interim call focused on the protocol between the KMF and the 
MDD. While we didn't make it very far into the proposed solution, the 
call was still very useful in teasing out some of the larger open issues 
that we're going to want to think about. I'm going to discuss one in 
this message, and will be sending out subsequent messages to talk 
through others.

One issue we discussed was the transport to be used between the KMF and 
the MDD. Prior to the Buenos Aires meeting, discussions had assumed that 
such a connection would be some form of DTLS, presumably directly on top 
of UDP (but see below). This is the design reflected in the current 
tunnel protocol draft (draft-jones-perc-dtls-tunnel-02).

During our face-to-face conversations in Buenos Aires, Magnus Westerlund 
raised some concerns about whether the overhead of encapsulating DTLS 
handshake messages inside a "Tunnel" message that is then itself carried 
over DTLS runs the risk of exceeding the underlying MTU. By my 
understanding (and a quick check of RFC6347 confirms this), one of the 
adaptations made for DTLS is the ability to fragment (at the TLS level, 
not the IP level) handshake messages according to the application's 
knowledge and/or guess of PMTU.

This means that, at worst, the use of DTLS for the tunnel makes us 
subtract on the order of 30 bytes (for the "Tunnel" messages), plus 
whatever overhead the additional DTLS header imposes, from our notion of 
PMTU for handshake messages in PERC implementations. I'm not close 
enough to that part of the stack to know how PMTU is computed (or 
assumed) for normal DTLS handshake usage, but I presume it's pretty 
conservative. Perhaps someone with DTLS implementation knowledge can 
weigh in on the topic.

All of which is to say the fragmentation issue seems to be of little or 
no consequence. I'm happy to be corrected by someone who is intimately 
familiar with the inner workings of DTLS if I'm off base here (Richard? 
EKR?).

So, unless that turns out to be an issue that legitimately runs us over 
MTU on a regular basis, we should make our decision based on the 
properties of the transports.

The point I made on the call was fundamentally this: once we make the 
assumption that the network containing the KMF is suitable for passing 
media to and from the MDD (which is manifestly true for a co-located 
KMF, and presumptively true for a non-co-located one) for the duration 
of a conference, then we know for certain that it is behind a firewall 
that can support UDP associations for the duration of a conference.

What we do *not* know is that it is behind a firewall that is willing to 
support a TCP connection for that long. And we do know that some 
firewalls -- intended to be HTTP proxies -- limit the duration of TCP 
connections to prevent unauthorized use for non-HTTP purposes.

So my take here is that we're going to want to retain the use of DTLS 
rather than shifting to a TLS-based tunnel for the KMF-MDD 
communication, unless I've made some bad assumptions about how DTLS does 
handshake fragmentation.

/a

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 28 Apr 2016 02:31:27 +0000

Adam,

You are correct that that the handshake messages are fragmented "under 
the covers" to ensure that the MTU size is not exceeded.

At least with OpenSSL, there is a function called SSL_set_mtu() that 
allows one to set an MTU.  It will allow one to reduce the MTU size, but 
not exceed what the DTLS stack believes is the max MTU.  Additionally, 
one can query what the stack thinks is the current MTU via 
DTLS_get_link_min_mtu().  It gets this by querying the kernel, 
subtracting some number of octets for IP and UDP overhead (max 48 octets 
overhead).

The overhead introduced in the current tunnel draft is minimal and we 
could shrink it further by reducing the size of the version field (or 
eliminating it) and reducing the size of the association ID.

The largest chunk of data added by the tunnel is the key and salt 
information which is ONLY transmitted when the "Finished" message is 
sent.  For the AES-GCM using a 256 bit key, those would be:
   Client write: 32 (256 bit)
   Server write: 32 (256 bit)
   Client master salt: 12 (96 bits)
   Server master salt: 12 (96 bits)
   data type field: 1
   Protection profile: 2
   MKI length: 1 (this could be eliminated for PERC, because we will not 
be using MKI and is only there because it is in DTLS-SRTP)
   MKI value: 2 (actually variable, but 2 is reasonable.  Again, we could 
remove this from the protocol.)

So,  that gives us 91 octets if I counted correctly (beyond the other 
tunnel header data). If AES-CTR was used, we could add another 2 octets 
to the read/write salt values (total 4 octets).  Let's just say 100 
octets max.

The other part of it is how long is the CipherChangeSpec and Finished, 
which are sent in the same flight with the key info.  I don't have an 
exact octet count for those.  ChangeCipherSpec is about 1 octet (plus 
the record overhead) and Finished is about 12 (plus the record 
overhead), as I understand.  In any case, it is well below any 
reasonable MTU size, even with the "tunnel+key info" additions.

Paul

------ Original Message ------
From: "Adam Roach" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Magnus Westerlund" <[email-masked]>
Sent: 4/27/2016 6:19:44 PM
Subject: [Perc] Open issue: TCP or UDP for the tunnel?

>call was still very useful in teasing out some of the larger open 
>issues that we're going to want to think about. I'm going to discuss 
>one in this message, and will be sending out subsequent messages to 
>talk through others.
>
>the MDD. Prior to the Buenos Aires meeting, discussions had assumed 
>that such a connection would be some form of DTLS, presumably directly 
>on top of UDP (but see below). This is the design reflected in the 
>current tunnel protocol draft (draft-jones-perc-dtls-tunnel-02).
>
>During our face-to-face conversations in Buenos Aires, Magnus 
>Westerlund raised some concerns about whether the overhead of 
>encapsulating DTLS handshake messages inside a "Tunnel" message that is 
>then itself carried over DTLS runs the risk of exceeding the underlying 
>MTU. By my understanding (and a quick check of RFC6347 confirms this), 
>one of the adaptations made for DTLS is the ability to fragment (at the 
>TLS level, not the IP level) handshake messages according to the 
>application's knowledge and/or guess of PMTU.
>
>whatever overhead the additional DTLS header imposes, from our notion 
>of PMTU for handshake messages in PERC implementations. I'm not close 
>What we do *not* know is that it is behind a firewall that is willing 
>to support a TCP connection for that long. And we do know that some 
>communication, unless I've made some bad assumptions about how DTLS 
>does handshake fragmentation.
>
>/a
>
>_______________________________________________
>Perc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/perc

---

From: Christian Groves <[email-masked]>
Date: Fri, 29 Apr 2016 13:39:19 +1000

+1 for using DTLS.

Christian

On 28/04/2016 8:19 AM, Adam Roach wrote:
> One issue we discussed was the transport to be used between the KMF 
> and the MDD. Prior to the Buenos Aires meeting, discussions had 
> assumed that such a connection would be some form of DTLS, presumably 
> directly on top of UDP (but see below). This is the design reflected 
> in the current tunnel protocol draft (draft-jones-perc-dtls-tunnel-02).
>
> encapsulating DTLS handshake messages inside a "Tunnel" message that 
> is then itself carried over DTLS runs the risk of exceeding the 
> underlying MTU. By my understanding (and a quick check of RFC6347 
> confirms this), one of the adaptations made for DTLS is the ability to 
> fragment (at the TLS level, not the IP level) handshake messages 
> according to the application's knowledge and/or guess of PMTU.
>
> All of which is to say the fragmentation issue seems to be of little 
> or no consequence. I'm happy to be corrected by someone who is 
> intimately familiar with the inner workings of DTLS if I'm off base 
> here (Richard? EKR?).
>
> So, unless that turns out to be an issue that legitimately runs us 
> over MTU on a regular basis, we should make our decision based on the

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Apr 2016 14:49:45 +1000

On 28 April 2016 at 08:19, Adam Roach <[email-masked]> wrote:
> This means that, at worst, the use of DTLS for the tunnel makes us subtract
> on the order of 30 bytes (for the "Tunnel" messages), plus whatever overhead
> the additional DTLS header imposes, from our notion of PMTU for handshake
> messages in PERC implementations. I'm not close enough to that part of the
> stack to know how PMTU is computed (or assumed) for normal DTLS handshake
> usage, but I presume it's pretty conservative. Perhaps someone with DTLS
> implementation knowledge can weigh in on the topic.

DTLS records have a 13 octet header, and will likely carry a 16 octet
authentication tag, so your analysis is correct.

PMTU handling in DTLS is fairly crude, but should handle a wart of
that size.  NSS starts out assuming that it can send 1472 octets
(excluding the IP and UDP headers, which make it up to 1500).  It then
steps down on every other retransmission attempt to 1252, 548, and
then 228.

That last value is nuts.  If you can't get that many octets through,
just give up.

Future versions of DTLS might be leaner by a few octets on its own
headers, but the authentication tag will remain.  I don't imagine that
saving 10 octets will have much impact here.

---

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

> On Apr 28, 2016, at 9:39 PM, Christian Groves <[email-masked]> wrote:
> 
> +1 for using DTLS.
> 
> Christian

+1 - I think as we dig into the MTU issue we will decide there is no problem with it