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

[[e-mail]]

Hi Magnus,

Please see inline.

Regards

Jon

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: 18 December 2020 09:53
> To: [e-mail]; magnus.westerlund=[e-mail]; supjps-
> [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; draft-ietf-dots-
> [e-mail]
> Subject: Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-
> home-11: (with DISCUSS)
> 
...
> > > 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).
> 
> 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] 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"

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

[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
> you can start the DTLS processing in the dispatcher and then hand over the DTLS
> state and only have encrypted UDP payloads being dispatached.

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

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

[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