Subject: [Dots] Review comments on draft-ietf-dots-signal-channel-23

From: Jim Schaad <[email-masked]>
Date: Thu, 23 Aug 2018 19:19:52 -0700

I read this document as part of a quick review to see how the -hops draft
was used and ended up with some comments.

* Section 3 - There is a requirement that under some circumstances that
address information is not to be included.  I am wondering if this same set
of recommendations should be placed in the HOP-TO document as well?

* Figure 5 - There are a couple of things about this example that slightly
baffle me
           ** I would probably omit the Uri-Host option on the assumption
that one would use the IP address and not the DNS name at this location.  If
this is being placed here for dealing with proxies, then that is not
correct.
           ** Are the cuid and mid items actually Uri-Path items or are they
Uri-Query items.  Given the presence of the '=' I would have expected these
to be query options. You might want to have some discussion on why one is
using the path and not the query option.
           ** Should the Uri-Path element for 'version' be 'v1'?

* Section 4.4.1 - I am unsure how a cuid is supposed to be determined as
coming from a specific client once a message has gone through a proxy of any
type.  Are cuid values allowed to be scoped by cdid values?

* Section 4.4.2.1 - If the client does an observe on a server, I am not sure
how one can say that the notification is unsolicited.  It may be async but
it was asked for.  Unless of course you plan to return responses for other
URLs as part of the observe

* Figure 14 - If-Match requires a value to match against.

* Section 4.5 - Should review with a CoAP expert what it means to do heart
beats in the presence of proxy servers.   The TLS ping-pong would only refer
to the TLS link and not be end-to-end if my understanding is correct.  

*  General - Can I make the assumption in the document that the only relay
agents that ever exist are Gateways and that all gateways are DOT gateways
or may there be other proxies in the system?  May need to make this
statement.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 27 Aug 2018 06:44:49 +0000

Hi Jim,

Thanks for taking time to review the draft. Please see inline

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Jim Schaad
> Sent: Friday, August 24, 2018 7:50 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Dots] Review comments on draft-ietf-dots-signal-channel-23
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> I read this document as part of a quick review to see how the -hops draft was
> used and ended up with some comments.
> 
> address information is not to be included.  I am wondering if this same set of
> recommendations should be placed in the HOP-TO document as well ?

Yes, will update hop-limit draft. 

> 
> * Figure 5 - There are a couple of things about this example that slightly baffle
> me
>            ** I would probably omit the Uri-Host option on the assumption that one
> would use the IP address and not the DNS name at this location.  If this is being
> placed here for dealing with proxies, then that is not correct.

RFC7252 at various places uses the DNS name or IP address in the Uri-Host option and Section 6.4 in RFC7252 explains using the DNS name in the Uri_Host Option from the URI. 

>            ** Are the cuid and mid items actually Uri-Path items or are they Uri-
> Query items.  Given the presence of the '=' I would have expected these to be
> query options. You might want to have some discussion on why one is using the
> path and not the query option.

It was discussed in the DOTS mailing list, please see https://mailarchive.ietf.org/arch/msg/dots/s48b5UNCR0ZityyHGQuYQ4Ur_G8 and 
slide 5 in https://datatracker.ietf.org/meeting/101/materials/slides-101-dots-signal-channel-00.  

>            ** Should the Uri-Path element for 'version' be 'v1'?

Yup, will fix. 

> type.  Are cuid values allowed to be scoped by cdid values?

Yes, cdid identifies the DOTS client domain identity and cuid the DOTS client identity.

> 
> * Section 4.4.2.1 - If the client does an observe on a server, I am not sure how
> one can say that the notification is unsolicited.  It may be async but it was asked
> for.  Unless of course you plan to return responses for other URLs as part of the
> observe

No plan to return responses for other URLs, will replace "unsolicited" with "asynchronous" messages. 

> * Figure 14 - If-Match requires a value to match against.

No, as per Section 5.10.8.1 in RFC 7252, An If-Match option with an empty value matches any existing representation (i.e., it places the precondition on the existence 
of any current representation for the target resource).

> to the TLS link and not be end-to-end if my understanding is correct.

Yes, heartbeats are only exchanged with the peer DOTS agent. 

> agents that ever exist are Gateways and that all gateways are DOT gateways or
> may there be other proxies in the system?  May need to make this statement.

Yes, all the gateways (or proxies) in the path between the DOTS client and server are DOTS gateways (see https://tools.ietf.org/html/draft-ietf-dots-architecture-06#section-2.2.3).

Cheers
-Tiru

> 
> 
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 28 Aug 2018 10:01:40 +0100

Hi Tiru/Jim,

See inline Jon>

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 27 August 2018 07:45
To: Jim Schaad; [email-masked]
Cc: [email-masked]
Subject: Re: [Dots] Review comments on draft-ietf-dots-signal-channel-23

Hi Jim,

> I read this document as part of a quick review to see how the -hops draft
was

> * Figure 5 - There are a couple of things about this example that slightly
baffle
>            ** I would probably omit the Uri-Host option on the assumption
that one
> placed here for dealing with proxies, then that is not correct.

RFC7252 at various places uses the DNS name or IP address in the Uri-Host
option and Section 6.4 in RFC7252 explains using the DNS name in the
Uri_Host Option from the URI. 

Jon> I agree with Jim that Uri-Host option is not needed and actually takes
up unnecessary space (in the same way that http://example.com/path
translates to make connection to host example.com and then issue "GET
/path").  If different domains are required to get supported on the same
hosting IP (not in the signal draft) , then that can be covered off by the
use of SNI during (D)TLS setup.

~Jon

> path and not the query option.

It was discussed in the DOTS mailing list, please see
https://mailarchive.ietf.org/arch/msg/dots/s48b5UNCR0ZityyHGQuYQ4Ur_G8 and 
slide 5 in
https://datatracker.ietf.org/meeting/101/materials/slides-101-dots-signal-ch
annel-00.  

Yup, will fix. 

> type.  Are cuid values allowed to be scoped by cdid values?

Yes, cdid identifies the DOTS client domain identity and cuid the DOTS
client identity.

> for.  Unless of course you plan to return responses for other URLs as part
of the

No plan to return responses for other URLs, will replace "unsolicited" with
"asynchronous" messages. 

> * Figure 14 - If-Match requires a value to match against.

No, as per Section 5.10.8.1 in RFC 7252, An If-Match option with an empty
value matches any existing representation (i.e., it places the precondition
on the existence 
of any current representation for the target resource).

> agents that ever exist are Gateways and that all gateways are DOT gateways
or
> may there be other proxies in the system?  May need to make this
statement.

Yes, all the gateways (or proxies) in the path between the DOTS client and
server are DOTS gateways (see
https://tools.ietf.org/html/draft-ietf-dots-architecture-06#section-2.2.3).

Cheers
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 28 Aug 2018 15:15:23 +0000

Hi Jon,

Please see inline

> From: Jon Shallow <[email-masked]>
> Sent: Tuesday, August 28, 2018 2:32 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> 'Jim Schaad' <[email-masked]>; [email-masked];
> [email-masked]
> Subject: RE: [Dots] Review comments on draft-ietf-dots-signal-channel-23
> 
> > This email originated from outside of the organization. Do not click
> > links
> or
> > open attachments unless you recognize the sender and know the content
> > is
> safe.
> >
> > * Section 3 - There is a requirement that under some circumstances
> > that address information is not to be included.  I am wondering if
> > this same
> set of
> > would use the IP address and not the DNS name at this location.  If
> > this
> is being
> option and Section 6.4 in RFC7252 explains using the DNS name in the Uri_Host
> Option from the URI.
> 
> Jon> I agree with Jim that Uri-Host option is not needed and actually
> Jon> takes
> translates to make connection to host example.com and then issue "GET /path").

I don't get it, RFC7252 does not discuss removing the host component of the URL. 

> If different domains are required to get supported on the same hosting IP (not
> in the signal draft) , then that can be covered off by the use of SNI during
> (D)TLS setup.

Usage of SNI is already covered in the signal channel draft.

-Tiru

> 
> ~Jon
> 
> >            ** Are the cuid and mid items actually Uri-Path items or
> > are
> they Uri-
> > Query items.  Given the presence of the '=' I would have expected
> > these to
> be
> > query options. You might want to have some discussion on why one is
> > using
> the
> https://mailarchive.ietf.org/arch/msg/dots/s48b5UNCR0ZityyHGQuYQ4Ur_G8
> and slide 5 in https://datatracker.ietf.org/meeting/101/materials/slides-101-
> dots-signal-ch
> annel-00.
> 
> > * Section 4.4.1 - I am unsure how a cuid is supposed to be determined
> > as coming from a specific client once a message has gone through a
> > proxy of
> any
> > * Section 4.4.2.1 - If the client does an observe on a server, I am
> > not
> sure how
> > one can say that the notification is unsolicited.  It may be async but
> > it
> was asked
> > for.  Unless of course you plan to return responses for other URLs as
> > part
> of the
> > observe
> 
> value matches any existing representation (i.e., it places the precondition on
> the existence of any current representation for the target resource).
> 
> >
> > *  General - Can I make the assumption in the document that the only
> > relay agents that ever exist are Gateways and that all gateways are
> > DOT gateways
> or
> server are DOTS gateways (see https://tools.ietf.org/html/draft-ietf-dots-
> architecture-06#section-2.2.3).
> 
> Cheers
> -Tiru
> 
> >
> >
> >
> >

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 28 Aug 2018 16:32:21 +0100

Hi Tiru,

There are references to default values, zero or more Uri-Host: etc.  Then
they can be explicitly defined - i.e.

5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query
...
   The default value of the Uri-Host Option is the IP literal
   representing the destination IP address of the request message.
   Likewise, the default value of the Uri-Port Option is the destination
   UDP port.  The default values for the Uri-Host and Uri-Port Options
   are sufficient for requests to most servers.  Explicit Uri-Host and
   Uri-Port Options are typically used when an endpoint hosts multiple
   virtual servers.

6.4 Decomposing URIs into Options
   The steps to parse a request's options from a string |url| are as
   follows.  These steps either result in zero or more of the Uri-Host,
   Uri-Port, Uri-Path, and Uri-Query Options being included in the
   request or they fail.
...
   5.  If the <host> component of |url| does not represent the request's
       destination IP address as an IP-literal or IPv4address, include a
       Uri-Host Option and let that option's value be the value of the
       <host> component of |url|, converted to ASCII lowercase, and then
       convert all percent-encodings ("%" followed by two hexadecimal
       digits) to the corresponding characters.

So, Uri-Host is not needed - if not there, it is the equivalent of the
destination IP address of the request message.

[My example of the http equivalent may have confused you - sorry].

Regards

Jon

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Konda,
Tirumaleswar Reddy
Sent: 28 August 2018 16:15
To: Jon Shallow; 'Jim Schaad'; [email-masked];
[email-masked]
Subject: Re: [Dots] Review comments on draft-ietf-dots-signal-channel-23

Hi Jon,

Please see inline

> option and Section 6.4 in RFC7252 explains using the DNS name in the
Uri_Host
> translates to make connection to host example.com and then issue "GET
/path").

I don't get it, RFC7252 does not discuss removing the host component of the
URL. 

-Tiru

> and slide 5 in
https://datatracker.ietf.org/meeting/101/materials/slides-101-
> Yes, cdid identifies the DOTS client domain identity and cuid the DOTS
client
> identity.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 28 Aug 2018 16:25:58 +0000

Thanks Jon for the clarification, will omit the Uri-Host Option.

-Tiru

> Sent: Tuesday, August 28, 2018 9:02 PM
> [email-masked]; [email-masked]; Jim Schaad
> <[email-masked]>
> There are references to default values, zero or more Uri-Host: etc.  Then they
> can be explicitly defined - i.e.
> 
> 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query ...
> So, Uri-Host is not needed - if not there, it is the equivalent of the destination IP
> address of the request message.
> 
> > > open attachments unless you recognize the sender and know the
> > > content is
> > safe.
> > >
> > RFC7252 at various places uses the DNS name or IP address in the
> > Uri-Host option and Section 6.4 in RFC7252 explains using the DNS name
> > in the
> Uri_Host
> > Option from the URI.
> >
> > If different domains are required to get supported on the same hosting
> > IP
> (not
> > > * Section 4.4.1 - I am unsure how a cuid is supposed to be
> > > determined as coming from a specific client once a message has gone
> > > through a proxy of
> > any
> > > one can say that the notification is unsolicited.  It may be async
> > > but it
> > was asked
> > > for.  Unless of course you plan to return responses for other URLs
> > > as part
> > of the
> > > observe
> >
> > No, as per Section 5.10.8.1 in RFC 7252, An If-Match option with an
> > empty value matches any existing representation (i.e., it places the
> precondition on
> > Yes, all the gateways (or proxies) in the path between the DOTS client
> > and server are DOTS gateways (see

---

From: Jim Schaad <[email-masked]>
Date: Tue, 28 Aug 2018 10:10:41 -0700

One of the questions that I would have is should there be a Proxy-Uri
option.  Does the client just know the address and name of the next
proxy/gateway up the chain or does it know the name of the ultimate server
and have an option about which one it is going to?

Jim

> From: Konda, Tirumaleswar Reddy <[email-masked]>
> Sent: Tuesday, August 28, 2018 9:26 AM
> To: Jon Shallow <[email-masked]>; [email-masked];
draft-ietf-dots-
> [email-masked]; Jim Schaad <[email-masked]>
> > links or open attachments unless you recognize the sender and know the
> content is safe.
> >
> > Hi Tiru,
> >
> > There are references to default values, zero or more Uri-Host: etc.
> > Then they can be explicitly defined - i.e.
> >
> > From: Dots [mailto:[email-masked]] On Behalf Of
> > Konda, Tirumaleswar Reddy
> > > > This email originated from outside of the organization. Do not
> > > > click links
> > > or
> > > > would use the IP address and not the DNS name at this location.
> > > > If this
> > > is being
> > > Uri-Host option and Section 6.4 in RFC7252 explains using the DNS
> > > name in the
> > Uri_Host
> > > Option from the URI.
> > >
> > > Jon> I agree with Jim that Uri-Host option is not needed and
> > > Jon> actually takes
> > > If different domains are required to get supported on the same
> > > hosting IP
> > (not
> > > in the signal draft) , then that can be covered off by the use of
> > > SNI
> > during
> > > (D)TLS setup.
> >
> > > >            ** Are the cuid and mid items actually Uri-Path items
> > > > or are
> > > they Uri-
> > > > query options. You might want to have some discussion on why one
> > > > is using
> > > the
> > > > determined as coming from a specific client once a message has
> > > > gone through a proxy of
> > > any
> > > > * Section 4.4.2.1 - If the client does an observe on a server, I
> > > > am not
> > > sure how
> > > > * Section 4.5 - Should review with a CoAP expert what it means to
> > > > do
> > heart
> > > > beats in the presence of proxy servers.   The TLS ping-pong would
only
> > > refer
> > > > *  General - Can I make the assumption in the document that the
> > > > only relay agents that ever exist are Gateways and that all
> > > > gateways are DOT gateways
> > > or
> > > Yes, all the gateways (or proxies) in the path between the DOTS
> > > client and server are DOTS gateways (see

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 28 Aug 2018 19:36:33 +0100

Hi Jim,

The DOTS gateway is a server/client combination, potentially acting as a
semi intelligent proxy, but the client and server stacks are deliberately
session separated.  The downstream client only knows about (is only
configured for) the immediate upstream server (which could be the server
component of the gateway) and no knowledge of anything further upstream.
The client component of the gateway knows only about its upstream server
(which could again be the server component of the gateway and so on.

See
https://tools.ietf.org/html/draft-ietf-dots-architecture-06#section-2.2.3
for a better write-up than I can do!

So, a client will never need to know that it is talking to a proxy server,
and hence never need to provide a Proxy-Uri in the DOTS environment.
However, we do need the Hop-Limit to break any potential or malicious
misconfiguration as traffic passes between multiple gateways.

Regards

Jon

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Jim
Schaad
Sent: 28 August 2018 18:11
To: 'Konda, Tirumaleswar Reddy'; 'Jon Shallow'; [email-masked];
[email-masked]
Subject: Re: [Dots] Review comments on draft-ietf-dots-signal-channel-23

Jim

draft-ietf-dots-
only