Subject: [core] How to proxy coap->http

From: Jim Schaad <[email-masked]>
Date: Wed, 26 Jul 2017 03:49:36 -0700

I started to do something that I thought was reasonable and have just been
told that what I wanted to do is apparently not legal according to the
current specification.  As I think it is totally reasonable, I want to
verify that it is both reasonable and not permitted.  And then maybe start a
discussion about if it should be permitted.  It may be this was discussed
before I came into the group so a pointer to mailing list discussion would
be apricated as well.

The following is considered to be a valid URL when doing an HTTP to CoAP
proxy

http://example.com/http2coap/coap:://coap.example.com/hello

>From this, I made the assumption that the reverse URL would be equally
acceptable.  That is

coap://proxy.example.com/coap2http/http://hello.example.com/hello

When encoding this, you would end up with

GET coap://proxy.example.com/coap2http
   Proxy-Uri: http://hello.example.com/hello

However, RFC 7252 in section 5.10.2 appears to state that one cannot have
both a Proxy-Uri and a Uri-Path in the same message and be a legal message.

1)  Am I correct this would be a reasonable thing to do - that is allow the
proxy server to be a resource (and thus potentially supporting multiple
proxies on a single server with different security requirements).

2) Am I correct that this is not something that is currently a legal thing
to do?

3) Is there a reason why this is not supported.  I do not believe that this
maps to anything like an http CONNECT as there is no session that is
established.  It would map much closer to something that is just
transforming the request and responses. 

Jim

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 26 Jul 2017 14:02:12 +0200

Hi Jim!

> http://example.com/http2coap/coap:://coap.example.com/hello

(This would be encoded as:)

    GET /http2coap/coap:://coap.example.com/hello HTTP/1.1
    Host: example.com

>    Proxy-Uri: http://hello.example.com/hello

(With the current rules, it would be encoded as:)

    method: GET
    uri-host: "proxy.example.com"
    uri-path: "coap2http"
    uri-path: "http:"
    uri-path: ""
    uri-path: "hello.example.com"
    uri-path: "hello"

> both a Proxy-Uri and a Uri-Path in the same message and be a legal message.

When sending a request to a proxy, both CoAP and HTTP allow a client
specify an absolute-URI. In CoAP it is possible that this is an
http:// URI, but in HTTP putting a coap:// URI in the request-line
works only theoretically.

Works:

    method: GET
    proxy-uri: "http://hello.example.com/hello"

Works in theory but not in practice:

    GET coap://coap.example.com/hello HTTP/1.1

So in HTTP you need some workaround to submit a CoAP URI to a proxy.
Of course, you could apply the same workaround to CoAP, but the
intention was to keep it simple and have the workaround be the
exception, not the norm.

> proxies on a single server with different security requirements).

I can imagine that it would be reasonable to have proxies on a single
server with different security requirements, but currently in both the
CoAP architecture and HTTP architecture a proxy is a host and not a
resource (with the exception of the HTTP-to-CoAP workaround). I would
prefer to keep it this way. Can you tell more about the use case?

> 2) Am I correct that this is not something that is currently a legal thing

Yes, Proxy-URI and URI-* options are currently mutually exclusive.

> transforming the request and responses.

See above.

Klaus

---

From: Jim Schaad <[email-masked]>
Date: Wed, 26 Jul 2017 05:12:09 -0700

Thanks for the response.  The encoding that you have below using a schema as a Uri-Path element would never have occurred to me.  I will need to cogitate.

Jim

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Wednesday, July 26, 2017 5:02 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [core] How to proxy coap->http

Hi Jim!

Jim Schaad wrote:
> The following is considered to be a valid URL when doing an HTTP to 
> CoAP proxy
>

    method: GET

> However, RFC 7252 in section 5.10.2 appears to state that one cannot 
> have both a Proxy-Uri and a Uri-Path in the same message and be a legal message.

When sending a request to a proxy, both CoAP and HTTP allow a client specify an absolute-URI. In CoAP it is possible that this is an http:// URI, but in HTTP putting a coap:// URI in the request-line works only theoretically.

Works:

    method: GET

So in HTTP you need some workaround to submit a CoAP URI to a proxy.
Of course, you could apply the same workaround to CoAP, but the intention was to keep it simple and have the workaround be the exception, not the norm.

> 1)  Am I correct this would be a reasonable thing to do - that is 
> allow the proxy server to be a resource (and thus potentially 
> supporting multiple proxies on a single server with different security requirements).

I can imagine that it would be reasonable to have proxies on a single server with different security requirements, but currently in both the CoAP architecture and HTTP architecture a proxy is a host and not a resource (with the exception of the HTTP-to-CoAP workaround). I would prefer to keep it this way. Can you tell more about the use case?

> 2) Am I correct that this is not something that is currently a legal 
> thing to do?

> 3) Is there a reason why this is not supported.  I do not believe that 
> this maps to anything like an http CONNECT as there is no session that 
> is established.  It would map much closer to something that is just 

See above.

Klaus

---

From: Jim Schaad <[email-masked]>
Date: Wed, 26 Jul 2017 13:41:03 -0700

>     uri-path: "hello.example.com"

I recognize that with the encoding that I had above it would be a different world and not the current rules.  I understand how the current rules would reach the encoding that you provided.

> When sending a request to a proxy, both CoAP and HTTP allow a client specify
> an absolute-URI. In CoAP it is possible that this is an http:// URI, but in HTTP
> putting a coap:// URI in the request-line works only theoretically.
> 
> Works:
> 
>     method: GET

So, the only real reason that I can see for this not working is the fact that one cannot write a PAC file that would provide a proxy mapping and expect any current browser to make the function call.  As an aside, I do not know if the url passed into the function FindProxyForURL would actually include the schema or not, however I am sure that Firefox today would probably not make the function call for a coap schema.

> Of course, you could apply the same workaround to CoAP, but the intention
> was to keep it simple and have the workaround be the exception, not the
> norm.
> 
> I can imagine that it would be reasonable to have proxies on a single server
> with different security requirements, but currently in both the CoAP
> architecture and HTTP architecture a proxy is a host and not a resource (with
> the exception of the HTTP-to-CoAP workaround). I would prefer to keep it this
> way. Can you tell more about the use case?

I don't currently have a use case that I can give at this point in time because I don't have a real world problem to solve.  I am looking at getting the code working with my code base and am looking for the "easiest" way to do this with my current code base.

I do have a couple of things that will affect how the proxy server is going to operate.  Since I want to have the ability to support running coaps from the client to the proxy server, I fully expect that the well-known points associated with the ACE framework document are going to need to be supported.  This means that the proxy server is not just an implementation that is going to absorb everything at the root point, but will have other resources besides the proxy one sitting at the root.  From my point of view it seems odd that this is the way things are going to be laid out with root being the proxy server and other resources existing.  I would not expect a proxy server to support OSCOAP as that is designed for end-to-end security, DTLS is going to be needed which means that key configuration is going to be needed.  

I am not sure how security would be setup to allow access control for OSCOAP as it would imply some type of double encryption, but it would be easy to do for dtls and do enforcement on the host and port of the "final" destination point.

Jim

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Thu, 27 Jul 2017 23:07:20 +0000

Hi Jim,

On 24/07/2017, 13:31, "core on behalf of Jim Schaad" <[email-masked] on behalf of [email-masked]> wrote:
> Following a number of discussions at the F2F meeting, I decided that I
> really needed to look at the proxy code that I inherited/stole and see
> if what it does matches what was documented.  At this point in time I
> am still trying to trudge through the code (and I don't really expect
> any help there), however I have come up with a number of
> comments/questions that I would like to see if there are answers to.
> 
> 1.  Is there any real difference between the default mapping of
> section 5.3 and the simple form mapping of section 5.4.1 where the
> template is {+tu}.  I cannot see what the difference would be and am
> currently planning to implement just section 5.4 and ignore section
> 5.3

It is slightly different.  But because 5.4.1 is a superset of 5.3, if
you implement 5.4.1 you don't need to care about 5.3.

> 2.  In looking at example #2 of section 5.4.2.1, I think I got misled
> based on the example.  Is there any reason why
> 
> => https://p.example.com/hc/?s=coap&hp=s.example.com&p=/light
> 
> Is not a valid result?  That is why can I not omit the "&q=" if there
> is nothing there.

It is certainly a valid URI, but it is not a valid output of the URI
template instantiation because the template specifies '&q=' as a
literal, therefore '&q=' should be serialised even if the query part of
the Target CoAP URI is missing.

> 3.  I am not sure what the correct story would be for dealing with the
> following
> 
> GET coap://10.10.80.200/resource HTTP/1.1
> User-Agent: Mozilla/4.0 (compatible; MSIE 8.0)
> Host: 10.10.80.200
> Proxy-Connection: Keep-Alive  
> 
> I generated that based on an ftp over http example, so it could easily
> be completely strange and illegal.  However, what would this mean and
> is there a reason it was not covered?

The request is valid, so if the HC proxy receives it, it should forward
it to the CoAP node (if allowed by policy).  The reason why URI-mapping
exists in the first place though - as discussed at the beginning of
section 5 - is that user agents don't like generating coap(s) URI in
absolute-form.

> RFC 8132 --- PATCH/FETCH
> 
> This document did not define any text to help me do this mapping.
> This applies both to the methods and to the error codes.  From the
> text it appears that FETCH is a new concept while PATCH and iPATCH
> are/might have some support from HTTP and thus can be directly
> translated.  However, trying to find all of the errors and documents
> on this is somewhat painful and if the section on how to do it and
> what the error matching is would be helpful both now and in the next
> version of the docment.

I agree with you.

Cheers, t