Subject: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 17 Dec 2020 06:29:25 -0800

Magnus Westerlund has entered the following ballot position for
draft-ietf-dots-signal-call-home-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 7.1: Port request for DOTS signal for home.

I think the WG has failed to take the assignment principles in RFC 6335 to
heart:

>From Section 7:

   "The basic principle of service name and port number registry
   management is to conserve use of the port space where possible."

   o  IANA strives to assign only one assigned port number per service
      or application.

      Note: At the time of writing of this document, there is no IETF
      consensus on when it is appropriate to use a second port for an
      insecure version of a protocol.

   o  IANA strives to assign only one assigned port number for all
      variants of a service (e.g., for updated versions of a service).

   o  IANA strives to encourage the deployment of secure protocols.

   o  IANA strives to assign only one assigned port number for all
      different types of devices using or participating in the same
      service.

   o  IANA strives to assign port numbers only for the transport
      protocol(s) explicitly named in an assignment request.

   o  IANA may recover unused port numbers, via the new procedures of
      de-assignment, revocation, and transfer.

After having reviewed Appendix A I think the WG has made the wrong choice and
also not considered all the available choices for enabling DOTS signal and call
home to be colocated on the same port. Several options exists:

        - URI name space so that it is the same protocol just making requests
        with different URIs depending on mode - Use the already existing
        settings negotiation to determine the mode of operation. - Using ALPN
        on (D)TLS connection establishment

>From my perspective the DOTS WG have multiple choices that are quite simple to
solve there colocation issue that would not incur significnat cost or overhead.
Using an additional port do incur a cost of consuming a resource that is
endless and not easily recoverable. I do share the IANA port experts team's
verdict that this port assignment should be denied and alternative solution
found as the motivation appears very weak.

---

From: <[email-masked]>
Date: Thu, 17 Dec 2020 15:22:32 +0000

Hi Magnus, 

I wonder whether you had a chance to read this message where explain why this is a new service, not a variant of an existing service: https://mailarchive.ietf.org/arch/msg/dots/GQP-QCmC-4XtJHPmsPR_quuyO0c/ 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Magnus Westerlund via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 17 décembre 2020 15:29
> À : The IESG <[email-masked]>
> Cc : [email-masked]; dots-
> [email-masked]; [email-masked]; Valery Smyslov <[email-masked]>;
> [email-masked]
> Objet : Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-
> home-11: (with DISCUSS)
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> After having reviewed Appendix A I think the WG has made the wrong
> choice and also not considered all the available choices for
> enabling DOTS signal and call home to be colocated on the same port.
> Several options exists:
> 
> >From my perspective the DOTS WG have multiple choices that are
> quite
> >simple to
> Using an additional port do incur a cost of consuming a resource
> that is endless and not easily recoverable. I do share the IANA port
> experts team's verdict that this port assignment should be denied
> and alternative solution found as the motivation appears very weak.
> 
> 
> 
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Dec 2020 15:54:32 +0000

Hi,

I hadn't read this before. But I have now read it and it don't really change my
perspective. I think there are several options here that should work for you. 

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. And future
implementation that are combined can simply use that ALPN signal as a basic
indication on behavior in common code paths. 

Cheers

Magnus Westerlund

On Thu, 2020-12-17 at 15:22 +0000, [email-masked] wrote:
> Hi Magnus, 
> 
> I wonder whether you had a chance to read this message where explain why this
> is a new service, not a variant of an existing service: 
> https://mailarchive.ietf.org/arch/msg/dots/GQP-QCmC-4XtJHPmsPR_quuyO0c/ 
> 
> Thank you. 
> 
> Cheers,
> Med
> 
> ______________________________________________________________________________
> ___________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Thu, 17 Dec 2020 16:56:47 -0000

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.

> 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.

There is also a minor concern in about exposing the protocol as https://tools.ietf.org/html/rfc7301#section-5  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.

Regards

Jon

> -----Original Message-----
> From: Magnus Westerlund [mailto:ietf-supjps-
> [email-masked]]
> Sent: 17 December 2020 15:55
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-ietf-dots-
> [email-masked]
> Subject: Re: Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-
> 11: (with DISCUSS)
> 
> Hi,
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Dec 2020 17:34:16 +0000

Hi,

On Thu, 2020-12-17 at 16:56 +0000, [email-masked] wrote:
> 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.

> 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. 

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. 

> 
> There is also a minor concern in about exposing the protocol as 
> https://tools.ietf.org/html/rfc7301#section-5  which states
> 

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.

Cheers

Magnus

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 17 Dec 2020 09:45:51 -0800

> being used based on the handshake.

The ALPN in the CH is still unencrypted, so if you only offer one option,
the server's pick being in EE doesn't really gain you anything.

-Ben

---

From: <[email-masked]>
Date: Thu, 17 Dec 2020 21:32:24 -0000

Hi Marcus,

Thanks for coming back on this and the suggestions.

Please see inline.

Regards

Jon

> From: Magnus Westerlund [mailto:magnus.westerlund=[email-masked]]
> Sent: 17 December 2020 17:34
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-
> home-11: (with DISCUSS)
> 
> Hi,
> 
> > 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

[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).

> another security model and trust relationship between the dispatcher and the

[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.
> 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

[Jon]  Agreed.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Dec 2020 09:53:11 +0000

Hi

Please see below

On Thu, 2020-12-17 at 21:32 +0000, [email-masked] wrote:
> > From: Magnus Westerlund [mailto:
> > magnus.westerlund=[email-masked]]
> > 
> > 
> > > 
> [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).

So I don't have a code exmample for this available, but I thought you can make
it work with so_reuseport/so_reuseaddr. There are some downside in that the new
socket can receive packets prior to the connect that just arrive. 

> [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.

Sorry, I don't understand why you bring in changes to network flow IP address. I
said secure communication here, and I mean internal to the server software
between processes. Basic interprocess communication here. Also, it might be that
you can start the DTLS processing in the dispatcher and then hand over the DTLS
state and only have encrypted UDP payloads being dispatached.

I would note that I think a lot of this dicsussion comes from that the
implementation you made so far has been done based on the assumption that there
would be a new port and separation rather than designing for coloaction. If we
take the step beyond your current implenentation from a protocol perspective in
an implementation built for co-location is there really any significant issues
here? 

Cheers

Magnus Westerlund

---

From: <[email-masked]>
Date: Sat, 19 Dec 2020 12:08:08 -0000

Hi Magnus,

Please see inline.

Regards

Jon

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: 18 December 2020 09:53
> To: [email-masked]; magnus.westerlund=[email-masked]; supjps-
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-ietf-dots-
...
> socket can receive packets prior to the connect that just arrive.
[Jon] I was using SO_REUSEADDR, but have found a bug in my test code so I now able to bind(same_port).  While a new socket and connect() can be done to match a new UDP client, it needs to be thought through when this is done - the arrival of the first UDP packet, when the DTLS APLN is known, or when the DTLS handshake is complete.  The DOTS stack we have is https://tools.ietf.org/html/rfc8782#section-3 Figure 3

DOTS
CoAP
DTLS
UDP
IP

[Jon] It is unclear to me as to how you can hand off a DTLS context to a different, non identical process along with its socket (this may be possible with OpenSSL, not sure about other TLS libraries - there is limited kernel AF_KTLS support which may help).  DTLS session resumption then also gets a lot more complicated.

[Jon] Then there is the challenge of how the received DTLS context + socket are integrated into the CoAP & DTLS stack on the receiving application so that things keep working.  In my port, it is the CoAP library that handles the sockets, not the DOTS application which would mean having customized code for the CoAP library - not ideal for maintenance long term.

[Jon] My surmise would be that implementors would say "forget this complexity with its inherent risks and just use a non-standard port"

> between processes.

[Jon] I latched on to "different servers" as possibly having different backend IPs.  Here, we actually have a DOTS server (sends responses) and a DOTS client (generates requests) that traffic needs to be steered to.

> Basic interprocess communication here. Also, it might be
> that

[Jon] As above, it is unclear to me as to how you can hand off a DTLS context to a different, non identical, process along with its socket and then integrate the received DTLS context into the different application.

> an implementation built for co-location is there really any significant issues

[Jon] I am the sort of person that needs to implement something to prove something is practically feasible, find what the issues are and what needs to be changed based on a specification and then debate how the spec needs to be updated to make it usable.

[Jon] DOTS call home did come later to the table after the initial DOTS was done which created the DOTS client and DOTS server as different applications in the implementations done to date.  Adding in the DOTS call home logic was very simple (with different port) - simple addition of accepting new connections on the call home DOTS client which triggered the client logic start up and initiating connections on the call home DOTS server and associated configuration logic. 

[Jon] While it is only software and hence not impossible, it is significant work to merge the client and server into a single application as well as having to maintain separate applications for running on limited resource devices.  We do not want to put in barriers to implementation of this draft by making it complex to implement.  Hence using a different port for the client service and the server service.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Dec 2020 11:03:18 +0000

Hi,

I will start my Christmas vacation tomorrow, so don't expect any more responses
until after the 7th of December. 

I am hearing what you are saying about implementability. However, I have the
feeling that the WG design process have failed to take into account some
relevant aspects here.

1. You are using COAP which do share high level semantics with HTTP. Thus,
different functionalites can easily be defined to work in parallel on a server.
Thus it could have been easy to ensure that individual or coloated dots-signal
and dots-call-home could be co-locate. Especially as you do have it part of what
is considered. 

2. You got a port for dots-signal to enable firewalls and routers etc to
identify and handle this traffic, otherwise I think dots-signal would have been
leaned hard on using the default COAP port. Expecting to consume another port
just because you didn't consider the constraints, which RFC6335 is clear with I
think is tough for me to swallow. 

3. You have several ways of designing yourself out of these issues that has been
raised. I understand this might be considered a late surprise, but it shouldn't
if you had read the in force BCP. 

My next question, do you actually need a fixed port at all for this. The service
name enables you to do SRV look ups to find port and IP address for the service.
Isn't that sufficient if you still want to run it on dedicated port compared to
DOTS-signal? 

Cheers

Magnus Westerlund

On Sat, 2020-12-19 at 12:08 +0000, [email-masked] wrote:
> > > > So I think there are several possible implementation paths for this. I
> > > > see
> > > > at least
> > > > two.
> > > > 
> [Jon] I was using SO_REUSEADDR, but have found a bug in my test code so I now
> able to bind(same_port).  While a new socket and connect() can be done to
> match a new UDP client, it needs to be thought through when this is done - the
> arrival of the first UDP packet, when the DTLS APLN is known, or when the DTLS
> handshake is complete.  The DOTS stack we have is 
> https://tools.ietf.org/html/rfc8782#section-3 Figure 3
> 
> DOTS
> CoAP
> DTLS
> UDP
> IP
> 
> [Jon] It is unclear to me as to how you can hand off a DTLS context to a
> different, non identical process along with its socket (this may be possible
> with OpenSSL, not sure about other TLS libraries - there is limited kernel
> AF_KTLS support which may help).  DTLS session resumption then also gets a lot
> more complicated.
> 
> [Jon] Then there is the challenge of how the received DTLS context + socket
> are integrated into the CoAP & DTLS stack on the receiving application so that
> things keep working.  In my port, it is the CoAP library that handles the
> sockets, not the DOTS application which would mean having customized code for
> the CoAP library - not ideal for maintenance long term.
> 
> [Jon] My surmise would be that implementors would say "forget this complexity
> with its inherent risks and just use a non-standard port"
> 
> > > 
> > > > 
> > > > and tracks all the different DTLS connection and have secure message
> > 
> > passing
> > > > another security model and trust relationship between the dispatcher and
> > 
> > the
> > > > servers.
> > > 
> [Jon] I latched on to "different servers" as possibly having different backend
> IPs.  Here, we actually have a DOTS server (sends responses) and a DOTS client
> (generates requests) that traffic needs to be steered to.
> 
> [Jon] As above, it is unclear to me as to how you can hand off a DTLS context
> to a different, non identical, process along with its socket and then
> integrate the received DTLS context into the different application.
> 
> > 
> [Jon] I am the sort of person that needs to implement something to prove
> something is practically feasible, find what the issues are and what needs to
> be changed based on a specification and then debate how the spec needs to be
> updated to make it usable.
> 
> [Jon] DOTS call home did come later to the table after the initial DOTS was
> done which created the DOTS client and DOTS server as different applications
> in the implementations done to date.  Adding in the DOTS call home logic was
> very simple (with different port) - simple addition of accepting new
> connections on the call home DOTS client which triggered the client logic
> start up and initiating connections on the call home DOTS server and
> associated configuration logic. 
> 
> [Jon] While it is only software and hence not impossible, it is significant
> work to merge the client and server into a single application as well as
> having to maintain separate applications for running on limited resource
> devices.  We do not want to put in barriers to implementation of this draft by
> making it complex to implement.  Hence using a different port for the client
> service and the server service.
> 
> > 
> > 
> > Cheers
> > 
> > Magnus Westerlund
> 
>

---

From: <[email-masked]>
Date: Mon, 21 Dec 2020 13:03:49 +0000

Hi Magnus,

Thank you for sharing your thoughts. 

We considered seriously the use of a distinct port vs. using the one that is already assigned to dots-signal. We documented the rationale in an appendix and also provided a detailed answer to why we think reusing the existing port is not that straightforward. We already answered why SRV records are not sufficient. Please refer to the message we shared with you early in this thread: https://mailarchive.ietf.org/arch/msg/dots/GQP-QCmC-4XtJHPmsPR_quuyO0c/ ((4) Why not using a dynamic port number following, e.g., draft-ietf-dots-server-discovery?). 

Also, we are familiar with existing BCPs. Please trust me, if dots-call-home was the same service as dots-signal, we wouldn't make the request. "DOTS server" and "DOTS client" are distinct and fully decoupled services. 
dots-call-home is a distinct service vs dots-signal in the same way netconf/restconf-call-home is a distinct service vs netconf/restocnf. As a reminder, *** three (3) *** additional port numbers were assigned in rfc8071#section-6 for the call-home in addition to the already assigned *** four (4) *** port numbers for NETCONF.

The proposal to define a (DTLS) dispatcher and the internal machinery to steer the traffic to a specific service is, if it works, a ** new service ** per se, that it is worth to be assigned a dedicated port on it owns: "One service, one port". Yet, we don't have evidence that service is feasible/works. What would be helpful for the community in the future, is that tsv area provides a spec of such service and evidence that it works without side effects. With that service defined, protocols running on DTLS can be muxed on that port number. Nevertheless, we need to remind that the dispatcher service might be similar in its goals to TCPMUX, which is *** obsoleted *** for reasons documented in RFC7805.

Cheers,
Med

> De : Magnus Westerlund [mailto:[email-masked]]
> Envoyé : lundi 21 décembre 2020 12:03
> À : [email-masked]; magnus.westerlund=[email-masked];
> [email-masked]; BOUCADAIR Mohamed TGI/OLN
> <[email-masked]>
> Cc : [email-masked]; [email-masked]; [email-masked]; draft-
> [email-masked]
> Objet : Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-
> signal-call-home-11: (with DISCUSS)
> 
> Hi,
> 
> > > To: [email-masked];
> magnus.westerlund=[email-masked]; supjps-
> > > Cc: [email-masked]; [email-masked]; [email-masked];
> draft-ietf-
> > > dots-
> > > Subject: Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-
> dots-signal-
> > > call-
> > > home-11: (with DISCUSS)
> > >
> >
> > ...
> > > > > First, do a 5-tuple connect on UDP to filter that particular
> UDP flow,
> > > > > process the
> > > > > 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
> > > > different IP etc.) and set up a new socket to specifically
> handle the
> > > > stream
> > > So I don't have a code exmample for this available, but I
> thought you can
> > > make
> > > it work with so_reuseport/so_reuseaddr. There are some downside
> in that the
> > > new
> > > > > Secondly, is to run some type of front end dispatcher that
> processes the
> > > > > packets
> > > > > between the front end dispatcher and the different servers.
> But this do
> > > > > requie
> > > > [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
> > > Sorry, I don't understand why you bring in changes to network
> flow IP
> > > address. I
> > > you can start the DTLS processing in the dispatcher and then
> hand over the
> > > DTLS
> > > implementation you made so far has been done based on the
> assumption that
> > > there
> > > would be a new port and separation rather than designing for
> coloaction. If
> > > we
> > > take the step beyond your current implenentation from a protocol
> perspective
> > > in
> > > an implementation built for co-location is there really any
> significant
> > > issues
> > > here?
> >