Re: [Dots] TR: [IANA #1181897] expert review for draft-ietf-dots-signal-call-home (service-names-port-numbers)

[Jon Shallow <[e-mail]>]

Hi,

Please see inline.

Regards

Jon

> -----Original Message-----
> From: Dots [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: 13 November 2020 10:11
> To: Jon Shallow; [e-mail]; Benjamin Kaduk
> Subject: Re: [Dots] TR: [IANA #1181897] expert review for draft-ietf-dots-signal-
> call-home (service-names-port-numbers)
> 
> Hi Jon,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Jon Shallow [mailto:[e-mail]]
> > Envoyé : vendredi 13 novembre 2020 10:54
> > À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>;
> > [e-mail]; Benjamin Kaduk <[e-mail]>
> > Objet : RE: [Dots] TR: [IANA #1181897] expert review for draft-ietf-
> > dots-signal-call-home (service-names-port-numbers)
> >
> > Hi All,
> >
> > I strongly recommend that we continue to press for separate ports.
> >
> > We have here 2 applications, very little overlap in functionality
> > using a common protocol (DOTS/CoAP/(D)TLS) - no real different to
> > say, mail and web both using a common protocol - TLS.
> >
> > If they insist on a single port, then we would have to do at least
> > one of
> >
> > a) Use different IP addresses albeit probably on the same host
> 
> [Med] We can't force that.
Jon> Agreed.
> 
> > b) De-multiplex incoming data to IP:port and steer to appropriate
> > application and transmit responses accordingly - a sort of DOTS
> > proxy front-ending things
> 
> [Med] I'm not sure to get this one. Based on which criteria we can steer the
> traffic?
Jon> Some addition to the DOTS protocol that is used at start up to say this is "call-home". However,  a DOTS client / Call Home DOTS server could not use the same source port as the DOTS proxy could not differentiate based on the 5-tuple - so the steering would have to be done based on source port - all a bit messy.
> 
> > c) Merge the 2 applications into a single entity and enhance DOTS
> > protocol
> 
> [Med] We could define an explicit message that requests "role reversal" once
> the (D)TLS session is created but this is might not be efficient especially when the
> session is to be established/reestablished during attack times.
Jon> Agreed.  Merging the 2 applications in my case would not be an easy task.  Again, a combined DOTS client / Call Home DOTS server talking to a combined DOTS server / Call Home DOTS client would have to use different source ports so that channel usage can be separated unless we tag each request/response with its usage.
> 
> > d) Spawn off the appropriate instance when a new connection comes in
> > - but we are UDP here.
> > e) Rely on server (and call-home) discovery to provide an
> > alternative port.
> 
> [Med] We do mention this one in the draft. The default port is used only when
> no config is available. To the question why discovery is not sufficient, the
> response is the same as the one we provided when we got assigned 4646.

Jon> Agreed
> 
> >
> > Note that the CoAP library I am using is not multi-thread safe which
> > complicates things further.
> 
> [Med] Good point to know.
Jon> Given that CoAP is supposed to be lightweight, this could also be true for other CoAP libraries.
> 
> >
> > Regards
> >
> > Jon
> >
> > > -----Original Message-----
> > > From: Dots [mailto:[e-mail]] On Behalf Of
> > > [e-mail]
> > > Sent: 13 November 2020 08:06
> > > To: [e-mail]; Benjamin Kaduk ([e-mail])
> > > Subject: [Dots] TR: [IANA #1181897] expert review for
> > > draft-ietf-dots-signal-call- home (service-names-port-numbers)
> > >
> > > Hi All,
> > >
> > > We received this reply from the port expert.
> > >
> > > We do have an appendix that explains why we do need a port number:
> > > demux two distinct services (one to handle mitigation and another
> > one
> > > to request mitigations). When a DTLS connection is received, the
> > node
> > > hosting both the base and call home has no means to determine
> > which
> > > role it needs to proceed with.
> > >
> > > I'm not sure how we can follow the suggestion to "use two
> > different
> > > messages on the same port" especially that we don't define the
> > > transport but rely upon existing ones.
> > >
> > > Unless there are other tweaks not already discarded in the past, I
> > > suggest we maintain our request.
> > >
> > > Thoughts?
> > >
> > > Cheers,
> > > Med
> > >
> > > -----Message d'origine-----
> > > De : Sabrina Tanamal via RT [mailto:[e-mail]]
> > > Envoyé : jeudi 12 novembre 2020 23:43
> > > Cc : [e-mail]; BOUCADAIR Mohamed TGI/OLN
> > > <[e-mail]>; [e-mail];
> > > [e-mail]; [e-mail]; [e-mail];
> > > [e-mail] Objet : [IANA #1181897] expert review for
> > > draft-ietf-dots-signal-call-home
> > > (service-names-port-numbers)
> > >
> > > Dear Authors,
> > >
> > > We have a response from the IESG-designated port expert:
> > >
> > > I do not see sufficient reason for a second port assignment to be
> > made
> > > for this single system. At best, they should just use two
> > different
> > > messages on the same port.
> > >
> > > This request should not be considered in isolation; it is coupled
> > to
> > > https://tools.ietf.org/html/draft-ietf-dots-server-discovery.
> > >
> > > One service, one port.
> > >
> > > ===
> > >
> > > Best regards,
> > >
> > > Sabrina Tanamal
> > > Senior IANA Services Specialist
> > >
> > >
> _________________________________________________________________
> > > ________________________________________________________
> > >
> > > 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.
> > >
> > > _______________________________________________
> > > Dots mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dots
> 
> 
> _________________________________________________________________
> ________________________________________________________
> 
> 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.
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots