Subject: Re: [Dots] WGLC on draft-ietf-dots-signal-call-home-06

From: "Jon Shallow" <[email-masked]>
Date: Wed, 6 Nov 2019 17:12:34 -0000

Hi All,

I have done a preliminary working implementation of DOTS Call-Home  - there
is still some little used functionality to finish off.

*** Issue # 1 - TCP TLS sessions

https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-06#section-3.1

" If UDP transport is used, the Call Home DOTS server begins by
initiating a DTLS connection to the Call Home DOTS client."

This works as expected where the UDP + DTLS layer roles are switched.

" If TCP is used, the Call Home DOTS server begins by initiating a
TCP connection to the Call Home DOTS client.  Using this TCP
connection, the Call Home DOTS server initiates a TLS connection
to the Call Home DOTS client."

With the current libcoap implementation, I am unable to create a CoAP
session using TLS on an existing TCP connection - so the DOTS Client is
unable to accept an incoming TCP session and then initiate TLS integrated
with the CoAP session.  I agree that RFC8071 only switches the TCP layer
roles.  However all works if the TCP + TLS layer roles are switched - in the
same way that UDP + DTLS work.

Enhancing the libcoap code to support only the TCP layer being switched is
doable - but have no idea as to whether other CoAP implementations can
handle this specific requirement.

*** Not (yet) Implemented #1 - Redirected Signalling

https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-06#section-3.2.
2

I do not see any issues here.

*** Not (yet) implemented #2 - New Conflict Cause 4

I do not see any issues here.

*** Not (yet) Implemented #3 - Address sharing considerations

https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-06#section-3.3.
2

I do not see any issues here - just need to interface with the translators
to get the appropriate information.

Regards

Jon

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Valery
> Smyslov
> Sent: 23 October 2019 08:36
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Dots] WGLC on draft-ietf-dots-signal-call-home-06
> 
> Hi,
> 
> this message starts a Work Group Last Call (WGLC) for
draft-ietf-dots-signal-
> call-home-06.
> The version to be reviewed is here:
https://www.ietf.org/id/draft-ietf-dots-
> signal-call-home-06.txt
> 
> The WGLC will last for two weeks and will end on November the 7th.
> Please send your comments to the list before this date.
> 
> Regards,
> Frank & Valery.
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Thu, 7 Nov 2019 07:11:54 +0000

Hi Jon, 

Thank you for sharing this cool news. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Jon Shallow
> Envoyé : mercredi 6 novembre 2019 18:13
> À : 'Valery Smyslov'; [email-masked]; [email-masked]
> Objet : Re: [Dots] WGLC on draft-ietf-dots-signal-call-home-06
> 
> Hi All,
> 
> with the CoAP session. 

[Med] Why the client would initiate the TLS session? Do you want to test a RFC8071-like approach?   

 I agree that RFC8071 only switches the TCP layer
> roles.  

[Med] Yes. 

However all works if the TCP + TLS layer roles are switched - in
> the

[Med] Great. We went for this approach because we preserve the same role for both DTLS and TLS:

              +-----------+                        +-----------+
              | Call Home |                        | Call Home |
              |    DOTS   |                        |    DOTS   |
              |   server  |                        |   client  |
              +-----+-----+                        +-----+-----+
              (D)TLS client                        (D)TLS server  

> handle this specific requirement.

[Med] Do we really need to do that?

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 7 Nov 2019 08:57:39 -0000

Hi Med,

See inline.

Regards

Jon

> From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
> Sent: 07 November 2019 07:12
> To: Jon Shallow; 'Valery Smyslov'; [email-masked]; [email-masked]
> Subject: Re: [Dots] WGLC on draft-ietf-dots-signal-call-home-06
> 
> Hi Jon,
> 
> > https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-06#section-
> 3..1
> >

Jon> Yesterday was one of those days - word blindness  translated "the Call
Home DOTS server initiates a TLS connection to the Call Home DOTS client."
as a separate action to  "the Call Home DOTS client initiates a TLS
connection to the Call Home DOTS server.".  The actual text is correct.

> [Med] Great. We went for this approach because we preserve the same role

Jon> No.  It was my mis-reading of the text that caused this confusion.

---

From: <[email-masked]>
Date: Thu, 7 Nov 2019 09:33:45 +0000

Re-,

Thank you, Jon. 

BTW, I don't see any issue about HE and HBs for the call home. I assume that no problem was encountered to implement it. 

Cheers,
Med
> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : jeudi 7 novembre 2019 09:58
> À : BOUCADAIR Mohamed TGI/OLN; 'Valery Smyslov'; [email-masked]; dots-
> [email-masked]
> Objet : RE: [Dots] WGLC on draft-ietf-dots-signal-call-home-06
> 
> Hi Med,
> 
> See inline.
> 
> Regards
> 
> Jon
> 
> > [Med] Why the client would initiate the TLS session? Do you want to test
> a
> > RFC8071-like approach?
> 
> > > 3.2.
> > > 3.3.

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 7 Nov 2019 10:39:18 -0000

Hi Med,

Happy Eyeballs worked fine with me with the Call Home DOTS server initiating
the DTLS and TLS sessions.

Heartbeats work, but I have not tested them under stress / loss conditions.
I will try to get that tested tomorrow.

In terms of the text I mis-read, perhaps it could be partially re-written

OLD

NEW

" If TCP is used, the Call Home DOTS server begins by initiating a
TCP connection to the Call Home DOTS client.  Once connected,  the Call Home
DOTS server continues to initiate a TLS connection
to the Call Home DOTS client."

Regards

Jon

> Sent: 07 November 2019 09:34
> BTW, I don't see any issue about HE and HBs for the call home. I assume
that
> no problem was encountered to implement it.
> 
> Cheers,
> Med
> > > > I have done a preliminary working implementation of DOTS Call-Home
> -
> > > there
> > > [Med] Great. We went for this approach because we preserve the same
> role
> > > for both DTLS and TLS:
> > >
> > > > Enhancing the libcoap code to support only the TCP layer being
> switched
> > is

---

From: <[email-masked]>
Date: Thu, 7 Nov 2019 12:15:49 +0000

Re-,

The NEW wording works for me. 

Thank you. 

Cheers,
Med

> Envoyé : jeudi 7 novembre 2019 11:39
> > > > > session using TLS on an existing TCP connection - so the DOTS
> Client
> is
> > > > > > From: Dots [mailto:[email-masked]] On Behalf
> Of
> > > > Valery
> > > > > > Smyslov

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 8 Nov 2019 13:53:01 -0000

Hi Med et al,

I have gone back over the heartbeat call home and have a couple of comments

In
https://tools.ietf.org/html/draft-ietf-dots-signal-channel-38#section-4.5.1 

OLD

   Figure 18 shows how to obtain acceptable configuration parameters for
   the DOTS server.

NEW

   Figure 18 shows how to obtain acceptable configuration parameters for
   the DOTS client.

or NEW

   Figure 18 shows how to obtain acceptable configuration parameters from
   the DOTS server.

With Call Home, the GET Config will still tell the Call Home DOTS Client
what are the acceptable values (which will cover keeping any NAT bindings
"warm"), and then the Call Home DOTS client can optionally do a PUT for
tweaking within the allowed bounds.

As the "saturated" direction will most likely continue to be from the (Call
Home) DOTS server to the (Call Home) DOTS client all the signal draft
recovery / continuing mechanisms still stand which the call home draft just
re-emphasises.

I have not had a chance to separately test this Call Home variant, but
everything is using the same code logic at this point as per the signal
draft.

Regards

Jon

> From: Dots [mailto:[email-masked]] On Behalf Of ietf-
> [email-masked]
> Sent: 07 November 2019 12:16
> > > > > [Med] Why the client would initiate the TLS session? Do you want
to
> > test
> > > > a
> > > > > RFC8071-like approach?
> > > >
> > > > Jon> Yesterday was one of those days - word blindness  translated
"the
> > > Call
> > > > > > doable - but have no idea as to whether other CoAP
> implementations
> > > can

---

From: <[email-masked]>
Date: Fri, 8 Nov 2019 14:21:24 +0000

Hi Jon,

Thank you for the feedback. 

Please see inline.

Cheers,
Med

> Envoyé : vendredi 8 novembre 2019 14:53

[Med] "for" is used in reference to "acceptable" from the perspective of the server. Sure, the information will be retrieved from the server.  

> "warm"),

[Med] Yes, and especilay for twekaing heartbeat-interval.

 and then the Call Home DOTS client can optionally do a PUT for
> tweaking within the allowed bounds.

[Med] Not sure to follow you here. Which PUT are you referring to?

> recovery / continuing mechanisms still stand which the call home draft just

[Med] There are some diffs: e.g., the Call Home Clint can't initiate a new (D)TLS session.

> > > > > > > " If TCP is used, the Call Home DOTS server begins by
> initiating
> a
> > > > > > > With the current libcoap implementation, I am unable to create
> a
> > > CoAP

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 8 Nov 2019 15:43:29 -0000

Hi Med,

See inline.

Regards

Jon

> From: Dots [mailto: [email-masked]] On Behalf Of
> Sent: 08 November 2019 14:21
> > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-38#section-
> 4.5..1
> >
> > OLD
> >
> [Med] "for" is used in reference to "acceptable" from the perspective of
the
> server. Sure, the information will be retrieved from the server.

Jon> OK
> [Med] Not sure to follow you here. Which PUT are you referring to?

Jon> PUT /config to change the current values.

> [Med] There are some diffs: e.g., the Call Home Clint can't initiate a new

Jon> Agreed.  My DOTS client when configured to be in Call Home mode is not
allowed to initiate any new (D)TLS sessions, but continues to listen on port
4647.

Jon> That said, I have not (yet) implemented the Call Home DOTS server
initiating a new connection if the heartbeats have expired.

~Jon

> > > > TCP connection to the Call Home DOTS client.  Once connected,  the
> Call
> > > > Home
> > > > > > > > I have done a preliminary working implementation of DOTS
Call-
> > > Home
https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-
> > > > > > 06#section-
> > > > > > > > unable to accept an incoming TCP session and then initiate
TLS
> > > > > > integrated
> > > > > > Home DOTS server initiates a TLS connection to the Call Home
DOTS
> > > > > client."
> > > > > > >               |    DOTS   |                        |    DOTS
|
> > > > > > >               |   server  |                        |   client
|
> > > > > > > > *** Not (yet) Implemented #1 - Redirected Signalling
https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-
> > > > > > 06#section-
https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-
> > > > > > 06#section-
> > > > > > > > 3.3.
> > > > > > > > 2
> > > > > > > >
> > > > > > > > I do not see any issues here - just need to interface with
the
> > > > > > translators
> > > > > > > > > The WGLC will last for two weeks and will end on November
> the
> > > > 7th.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 11 Nov 2019 10:06:05 -0800

On Fri, Nov 08, 2019 at 02:21:24PM +0000, [email-masked] wrote:
> > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-38#section-4.5..1
> > 
> > OLD
> > 

perhaps "how to obtain configuration parameters that the DOTS server will
find acceptable", then?

-Ben

---

From: <[email-masked]>
Date: Tue, 12 Nov 2019 06:42:20 +0000

Hi Ben, 

That's better. Thanks. 

Cheers,
Med

> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : lundi 11 novembre 2019 19:06
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Jon Shallow; 'Valery Smyslov'; [email-masked]; [email-masked]
> the server. Sure, the information will be retrieved from the server.
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 12 Nov 2019 10:32:06 +0300

Hi again,

the WGLC period is over. We received no objections for publication of this
document.
There were few comments from WG participants suggesting minor
clarifications, 
so a new version of the draft is needed. Once it is published (when the
submission
window opens), I'll start preparing shepherd write-up.

Regards,
Valery.

draft-ietf-dots-signal-

---

From: <[email-masked]>
Date: Mon, 18 Nov 2019 09:22:11 +0000

Re-,

The version that integrates the comments received during the WGLC is available at: https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-07. 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Valery Smyslov
> Envoyé : mardi 12 novembre 2019 08:32
> À : [email-masked]
> Cc : [email-masked]