Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS) Thu, 17 December 2020 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 535A93A103F for <>; Thu, 17 Dec 2020 13:32:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bUuU-s6xmeqv for <>; Thu, 17 Dec 2020 13:32:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55D3A3A1038 for <>; Thu, 17 Dec 2020 13:32:38 -0800 (PST)
Received: from ([] helo=N01332) by with esmtp (Exim 4.92.3) (envelope-from <>) id 1kq0t2-0003OJ-Ku; Thu, 17 Dec 2020 21:32:36 +0000
From: <>
To: "'Magnus Westerlund'" <>, <>, <>
Cc: <>, <>, <>, <>
References: <> <26637_1608218552_5FDB77B8_26637_63_1_787AE7BB302AE849A7480A190F8B93303159F25D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <> <135d01d6d495$9b1b94e0$d152bea0$> <>
In-Reply-To: <>
Date: Thu, 17 Dec 2020 21:32:24 -0000
Message-ID: <13d001d6d4bc$1c543870$54fca950$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ2bnsKEk4cVClsqjQj7jfeJ0e02wFsH/eMAmTmvDoCv3IYJgJfyZeWqHTw/oA=
Content-Language: en-gb
Archived-At: <>
Subject: Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Dec 2020 21:32:41 -0000

Hi Marcus,

Thanks for coming back on this and the suggestions.

Please see inline.



> -----Original Message-----
> From: Magnus Westerlund []
> Sent: 17 December 2020 17:34
> To:;;
> Cc:;;
> Subject: Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-
> home-11: (with DISCUSS)
> Hi,
> On Thu, 2020-12-17 at 16:56 +0000, wrote:
> > Hi Magnus,
> >
> > We had considered using ALPN.
> >
> > While DOTS signal channel can use TLS, given that this DOTS protocol
> > has to be robust in an Distribute Denial of Service attack
> > environment, its primary use will be DTLS using UDP.
> To my understanding ALPN is part of the TLS mechansism that applies to both
> TLS and DTLS so I don't really understand the above sentence applicability.

[Jon] Apologies - I was trying to get the focus that UDP is our main headache here

> >
> > > Based on what you write in your email to my understanding ALPN in
> > > (D)TLS would work fairly well to dispatch the secured connection to
> > > the individual implementation of DOTS-signal and Dots-call home if that is
> needed.
> >
> > When using TCP, it is relatively easy to dispatch a secured connection
> > and attach it to, say a forked copy of the appropriate application or
> > a new thread in the application which then does all the network i/o
> > over that secured connection.
> >
> > However, for UDP from an implementation perspective, I cannot see how
> > this can be done so the network stack can itself steer each input
> > packet to the appropriate application when the traffic arrives on the
> > same IP and port (only one application can receive traffic on a
> > specific udp port).  I welcome any wisdom on how to do this.
> So I think there are several possible implementation paths for this. I see at least
> two.
> First, do a 5-tuple connect on UDP to filter that particular UDP flow, process the
> DTLS handshake for this socket and then based on ALPN decide on target
> process and then hand over the socket and the DTLS state to the right process.

[Jon] UDP has no concept of accept().  If you do a connect() on a socket that you have just received data on, then that updates the 5 tuple and then only receives traffic matching the tuple as expected. However, it appears not possible to leave the original socket ready for the next packet (from different IP etc.) and set up a new socket to specifically handle the stream matching the packet just received, bind(same_port), do the connect() on it etc. (the bind(same_port)fails in my test).

> Secondly, is to run some type of front end dispatcher that processes the packets
> and tracks all the different DTLS connection and have secure message passing
> between the front end dispatcher and the different servers. But this do requie
> another security model and trust relationship between the dispatcher and the
> servers.

[Jon] This does complicate things.  The DOTS signal channel requires mutual authentication of the agents and introducing some sort of man-in-middle that changes the network flow IP addresses etc. and potentially changes encryption characteristics breaks this mutual authentication.  It is not easy to change how the base DOTS signal works.
> >
> > There is also a minor concern in about exposing the protocol as
> >  which states
> >
> >    Implementers and document editors who intend to extend the protocol
> >    identifier registry by adding new protocol identifiers should
> >    consider that in TLS versions 1.2 and below the client sends these
> >    identifiers in the clear.  They should also consider that, for at
> >    least the next decade, it is expected that browsers would normally
> >    use these earlier versions of TLS in the initial ClientHello.
> >
> >    Care must be taken when such identifiers may leak personally
> >    identifiable information, or when such leakage may lead to profiling
> >    or to leaking of sensitive information.  If any of these apply to
> >    this new protocol identifier, the identifier SHOULD NOT be used in
> >    TLS configurations where it would be visible in the clear, and
> >    documents specifying such protocol identifiers SHOULD recommend
> >    against such unsafe use.
> >
> > Even though it is possible to derive things from the fact that a
> > particular port being used.
> I think the current security properties are basically the same between two well
> know ports and one port with unencrypted ALPN. And when you move to DTLS
> 1.3 the alpn extension will be encrypted and you have slightly better security as
> the third party observer can't know if it is DOTS signal or DOTS call home that
> being used based on the handshake.

[Jon]  Agreed. 
> Cheers
> Magnus