Subject: [tsvwg] sanity checking DTLS ICMP errors

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 19 Jan 2015 11:43:51 -0800

To reduce the attack surface, TCP implementations have been validating ICMP error messages to be in-window (RFC5927).

On a thread over on RTCWEB with Michael Tüxen, it seems DTLS-encrypted packets might benefit from a similar validation.  There are some fields early in the packet that might be useful for such validation,

      struct {
        ContentType type;
        ProtocolVersion version;
        uint16 epoch;                                     // New field
        uint48 sequence_number;                           // New field
        uint16 length;
        select (CipherSpec.cipher_type) {
          case block:  GenericBlockCipher;
        } fragment;
      } DTLSCiphertext;

however, both the Epoch and Sequence Number start at zero (unlike TCP's initial sequence number which has been random for nearly 20 years).  

Do we want to validate ICMP error messages for DTLS packets?  If so, can DTLS have a randomized initial sequence number?

-d

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 19 Jan 2015 23:36:44 +0100

> On 19 Jan 2015, at 20:43, 🔓Dan Wing <[email-masked]> wrote:
> 
> On a thread over on RTCWEB with Michael Tüxen, it seems DTLS-encrypted packets might benefit from a similar validation.  
Just to add some information:
Dan was asking why we couldn't just process incoming ICMP packets indicating that a packet
sent was too big by SCTP when running over DTLS. My point was that we can't the validation
of the verification tag as we do normally for SCTP. That is why we use PMTUD as described
in RFC4821 for
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-08
> There are some fields early in the packet that might be useful for such validation,
> 
>      struct {
>        ContentType type;
>        ProtocolVersion version;
One difference is that the TCP initial sequence number is negotiated during the TCP handshake.
DTLS doesn't do this.
> Do we want to validate ICMP error messages for DTLS packets?  If so, can DTLS have a randomized initial sequence number?
At least you need to change the specification. So it is something one might consider when working on DTLS 1.3, I guess.

Best regards
Michael

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 22 Jan 2015 00:34:54 -0800

On Mon, Jan 19, 2015 at 2:36 PM, Michael Tuexen <
[email-masked]> wrote:

> > To reduce the attack surface, TCP implementations have been validating
> ICMP error messages to be in-window (RFC5927).
> >
> > On a thread over on RTCWEB with Michael Tüxen, it seems DTLS-encrypted
> packets might benefit from a similar validation.

Sorry if I miss something..
I'm just curious after reading the following texts.

 Incoming ICMP or ICMPv6 messages can't be processed by the SCTP
   layer, since there is no way to identify the corresponding
   association.

If the socket used for UDP encap is connected and if only one SCTP
association over DTLS is mapped to the socket, is it still impossible for
SCTP layer to know if it receives ICMP errors?

Thanks,
--
Yoshi

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 22 Jan 2015 21:03:56 +0100

> On 22 Jan 2015, at 09:34, Yoshifumi Nishida <[email-masked]> wrote:
> 
> 
> On Mon, Jan 19, 2015 at 2:36 PM, Michael Tuexen <[email-masked]> wrote:
> If the socket used for UDP encap is connected and if only one SCTP association over DTLS is mapped to the socket, is it still impossible for SCTP layer to know if it receives ICMP errors?  
Please note that the ICMP processing of SCTP requires to check the verification tag. Since we use DTLS, this
is not present in cleartext in the ICMP message (if it is present at all).

Best regards
Michael

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 22 Jan 2015 23:40:10 -0800

Hi Michael,

On Thu, Jan 22, 2015 at 12:03 PM, Michael Tuexen <
[email-masked]> wrote:

> Please note that the ICMP processing of SCTP requires to check the
> verification tag. Since we use DTLS, this

What I meant was that an SCTP association might be able to know if it
receives ICMP errors, even though it cannot examine it.
I just felt that the texts "there is no way to identify the corresponding
association" might be a bit ambiguous expression. Sorry for picking up a
minor point.

Thanks,
--
Yoshi

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 23 Jan 2015 15:41:21 +0100

> On 23 Jan 2015, at 08:40, Yoshifumi Nishida <[email-masked]> wrote:
> 
> Hi Michael,
> 
> On Thu, Jan 22, 2015 at 12:03 PM, Michael Tuexen <[email-masked]> wrote:
> 
> What I meant was that an SCTP association might be able to know if it receives ICMP errors, even though it cannot examine it. 
> I just felt that the texts "there is no way to identify the corresponding association" might be a bit ambiguous expression. Sorry for picking up a minor point.
Well, if you can't. You could only apply the handling to all associations running over the the DTLS connection
and bypass the verification tag checking. So you can't figure out which association triggered the sending
of the ICMP packet, since the reflected packet is the DTLS cipher text.

Best regards
Michael