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

[[e-mail]]

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

> -----Message d'origine-----
> De : Magnus Westerlund [mailto:[e-mail]]
> Envoyé : lundi 21 décembre 2020 12:03
> À : [e-mail]; magnus.westerlund=[e-mail];
> [e-mail]; BOUCADAIR Mohamed TGI/OLN
> <[e-mail]>
> Cc : [e-mail]; [e-mail]; [e-mail]; draft-
> [e-mail]
> Objet : Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-
> signal-call-home-11: (with DISCUSS)
> 
> 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
> >
> >

_________________________________________________________________________________________________________________________

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.