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

From: <[email-masked]>
Date: Fri, 13 Nov 2020 08:05:37 +0000

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:[email-masked]] 
Envoyé : jeudi 12 novembre 2020 23:43
Cc : [email-masked]; BOUCADAIR Mohamed TGI/OLN <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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.

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 13 Nov 2020 09:54:24 -0000

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
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
c) Merge the 2 applications into a single entity and enhance DOTS protocol
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.

Note that the CoAP library I am using is not multi-thread safe which complicates things further.

Regards

Jon

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 13 November 2020 08:06
> To: [email-masked]; Benjamin Kaduk ([email-masked])
> Subject: [Dots] TR: [IANA #1181897] expert review for draft-ietf-dots-signal-call-
> home (service-names-port-numbers)
> 
> Hi All,
> 
> 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.
> 
> Cc : [email-masked]; BOUCADAIR Mohamed TGI/OLN
> <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 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
> _________________________________________________________________
> ________________________________________________________
> 
> 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;
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Fri, 13 Nov 2020 10:11:24 +0000

Hi Jon, 

Please see inline. 

Cheers,
Med

> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : vendredi 13 novembre 2020 10:54
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> [email-masked]; Benjamin Kaduk <[email-masked]>
> Objet : RE: [Dots] TR: [IANA #1181897] expert review for draft-ietf-
> dots-signal-call-home (service-names-port-numbers)
> 
> Hi All,
> 
> 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.
> 

[Med] We can't force that.

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

> c) Merge the 2 applications into a single entity and enhance DOTS

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

> e) Rely on server (and call-home) discovery to provide an

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

> complicates things further.

[Med] Good point to know. 

> > Subject: [Dots] TR: [IANA #1181897] expert review for
> > draft-ietf-dots-signal-call- home (service-names-port-numbers)
> >
> > Hi All,
> >
> > 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.
> >
> > [email-masked] Objet : [IANA #1181897] expert review for
> > draft-ietf-dots-signal-call-home
> > (service-names-port-numbers)
> >
> > Dear Authors,
> >
> > 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.
> >
> > 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: "Jon Shallow" <[email-masked]>
Date: Fri, 13 Nov 2020 10:41:10 -0000

Hi,

Please see inline.

Regards

Jon

> Sent: 13 November 2020 10:11
> To: Jon Shallow; [email-masked]; 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
> 
Jon> Agreed.
> [Med] I'm not sure to get this one. Based on which criteria we can steer the
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.
> [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.
> [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
> [Med] Good point to know.
Jon> Given that CoAP is supposed to be lightweight, this could also be true for other CoAP libraries.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 13 Nov 2020 12:02:17 +0000

Unique ports were assigned in the past for NETCONF/RESTCONF call home, see https://tools.ietf.org/html/rfc8071#section-6 

-Tiru

> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Friday, November 13, 2020 1:36 PM
> To: [email-masked]; Benjamin Kaduk ([email-masked]) <[email-masked]>
> Subject: [Dots] TR: [IANA #1181897] expert review for draft-ietf-dots-signal-
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> Hi All,
> 
> 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.
> 
> [email-masked] Objet : [IANA #1181897] expert review for draft-ietf-dots-
> signal-call-home (service-names-port-numbers)
> 
> Dear Authors,
> 
> 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.
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.
> 
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.