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

[Magnus Westerlund <[e-mail]>]

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, [e-mail] wrote:
> 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
> 
>