Subject: [core] One UDP request, many replies

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Jan 2013 16:12:20 -0500

I have a protocol that I am working on called Omnibroker that is intended
to provide a one-stop-shopping type approach to all the third party trust
data that a client might need. This includes DNS, NTP, OCSP and reputation
services.

The protocol has two parts, the first manages establishing a connection to
the service provider, exchanging cryptographic session keys,
authanticating, yadda yadda.

One comment made on the protocol is that the connection part is completely
general. It could be applied to virtually any request/response type Web
Service as security at the transaction layer is always going to come down
to some sort of shared session key for integrity and confidentiality and
the option of digital signatures (plus a means of archiving them) in the
rare case we want non-repudiation.

90% of the Omnibroker protocol is packaging to establish the connection and
then apply it to a query/response protocol. So pretty much most of the
protocol is reusable. Since these are TRUST services it is vital that every
message be authenticated independently of any transport security.

Due to deployment constraints there are three planned transport protocols:
DNS (tunneling over TXT), Web Service and UDP.

Looking at the CoApp pec it looks like a pretty good basis for the UDP
version of the protocol. So if I layer Omnibroker on CoApp, the same set of
options could be used to support other protocols that needed application
layer authentication.

There is one area where CoApp does not meet my needs and that is the limit
to one UDP request/response packet. I think that is a little more
restrictive than necessary. I get that people want to use multicast and
requests need to be limited to a single packet. That is fine. The requests
are almost always small. Fitting the response into 1280 bytes is much more
limiting. I know that there needs to be a limit but I think we could make
it more than just one packet.

Most of my transactions would fit into one UDP request plus up to eight
response packets. If the response is any longer than eight packets then it
isn't going to be one of the latency sensistive use cases.

So I could hack the CoApp protocol up on a one off basis so that I sent one
response that had a flag saying 'more responses to come' and then send
those as unsolicited messages. But this might be something that would be
better done as a general CoApp capability.

-- 
Website: http://hallambaker.com/

---

From: Robert Quattlebaum <[email-masked]>
Date: Sat, 12 Jan 2013 10:26:25 -0800

While it is true that a single CoAP confirmable message should elicit only one direct ACK, there is no reason that you couldn't have more than one non-ACK response. Indeed, this is how draft-ietf-core-observe works. CoAP can also be used to transfer more than 1280 bytes by using draft-ietf-core-block.

On Jan 11, 2013, at 1:12 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> I have a protocol that I am working on called Omnibroker that is intended to provide a one-stop-shopping type approach to all the third party trust data that a client might need. This includes DNS, NTP, OCSP and reputation services.
> 
> The protocol has two parts, the first manages establishing a connection to the service provider, exchanging cryptographic session keys, authanticating, yadda yadda.
> 
> One comment made on the protocol is that the connection part is completely general. It could be applied to virtually any request/response type Web Service as security at the transaction layer is always going to come down to some sort of shared session key for integrity and confidentiality and the option of digital signatures (plus a means of archiving them) in the rare case we want non-repudiation.
> 
> 90% of the Omnibroker protocol is packaging to establish the connection and then apply it to a query/response protocol. So pretty much most of the protocol is reusable. Since these are TRUST services it is vital that every message be authenticated independently of any transport security. 
> 
> 
> Due to deployment constraints there are three planned transport protocols: DNS (tunneling over TXT), Web Service and UDP.
> 
> Looking at the CoApp pec it looks like a pretty good basis for the UDP version of the protocol. So if I layer Omnibroker on CoApp, the same set of options could be used to support other protocols that needed application layer authentication.
> 
> 
> There is one area where CoApp does not meet my needs and that is the limit to one UDP request/response packet. I think that is a little more restrictive than necessary. I get that people want to use multicast and requests need to be limited to a single packet. That is fine. The requests are almost always small. Fitting the response into 1280 bytes is much more limiting. I know that there needs to be a limit but I think we could make it more than just one packet.
> 
> Most of my transactions would fit into one UDP request plus up to eight response packets. If the response is any longer than eight packets then it isn't going to be one of the latency sensistive use cases.
> 
> So I could hack the CoApp protocol up on a one off basis so that I sent one response that had a flag saying 'more responses to come' and then send those as unsolicited messages. But this might be something that would be better done as a general CoApp capability.
> 
> 
> 
> -- 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core