[Teep] draft-ietf-teep-otrp-over-http-06

[Hannes Tschofenig <[e-mail]>]

Hi Dave, Hi all,



I read through https://tools.ietf.org/html/draft-ietf-teep-otrp-over-http-06 and have a few high level comments.



I wonder whether there is room for simplification in these two figures below.



IMHO the middle layer is not needed in this figure. We have two layers, namely the TEEP protocol layer and the HTTP transport.



      +------------------+           TEEP           +------------------+

      |    TEEP Agent    | <----------------------> |        TAM       |

      +------------------+                          +------------------+

               |                                              |

      +------------------+      TEEP-over-HTTP      +------------------+

      | TEEP/HTTP Client | <----------------------> | TEEP/HTTP Server |

      +------------------+                          +------------------+

               |                                              |

      +------------------+           HTTP           +------------------+

      |    HTTP Client   | <----------------------> |    HTTP Server   |

      +------------------+                          +------------------+



                   Figure 1: Agent-to-TAM Communication



The same is true for the next figure in the document. I would remove the TEEP/HTTP implementation part and the figure is already substantially simpler to understand.

Furthermore, I am wondering whether Section 3 shouldn't go to the architecture draft because this is not really about the HTTP transport. Replace HTTP with CoAP, MQTT, etc. and the design aspect would still be the same. Furthermore, we have decided in the architecture that we want to provide application layer security independent of the transport and hence the question about where various pieces should go is less about security anymore. We could have made the design differently but we followed the OTrP approach.


                           Model:    A      B      C     ...

                                    TEE    TEE    TEE
        +----------------+           |      |      |
        |      TEEP      |     Agent |      |      | Agent
        | implementation |           |      |      |
        +----------------+           v      |      |
                 |                          |      |
        +----------------+           ^      |      |
        |    TEEP/HTTP   |    Broker |      |      |
        | implementation |           |      |      |
        +----------------+           |      v      |
                 |                   |             |
        +----------------+           |      ^      |
        |      HTTP      |           |      |      |
        | implementation |           |      |      |
        +----------------+           |      |      v
                 |                   |      |
        +----------------+           |      |      ^
        |   TCP or QUIC  |           |      |      | Broker
        | implementation |           |      |      |
        +----------------+           |      |      |
                                    REE    REE    REE

                       Figure 2: TEEP Broker Models



Minor aspects:



The content type has to change. Currently it talks about JSON.



Reference https://tools.ietf.org/html/rfc6125 Instead of RFC 2818<https://tools.ietf.org/html/rfc6125%20Instead%20of%20RFC%202818>.



In terms of HTTP transport aspects I believe the important aspects are



  *   Does it use the HTTP ports (80/443)?  (Yes, in our case)
  *   Does it use the HTTP URI scheme? (Yes, in our case)
  *   What HTTP messages are being used? (POST only in our case)
  *   What URIs are we sending the requests to? (I don't think we talk about this but we should.)
  *   What header fields does the client and the server use? (*)
  *   Are we using Cookies? (I would say that we don't. Currently not discussed.)
  *   The use of status codes **
  *   Server Push***
  *   HTTP authentication ****
  *   Redirect handling *****



*) The text says that the client uses the Accept header but I don't see any normative language there.

The headers the server uses are listed but my understanding of those is that they are only relevant for co-existence with web browsing. Clearly, the communication we are describing isn't useful for web browsing scenarios.


IMHO the following statement should be enough:
"
   The "Cache-control" header SHOULD be set to disable caching of any TEEP protocol
   messages by HTTP intermediaries.  Otherwise, there
   is the risk of stale TEEP messages.

"

To me, the following three headers shown in the draft are an overkill:


       X-Content-Type-Options: nosniff
       Content-Security-Policy: default-src 'none'
       Referrer-Policy: no-referrer



I would also add the following sentence:

"
   If the TAM does not receive the appropriate Content-Type and Accept header fields, the
   TAM SHOULD fail the request, returning a 406 (not acceptable)
   response.  TAM responses MUST include a Content-Length header.

"



**) The example gives me the impression that the protocol end indication is the 204 No Content. While I never saw it that way we should describe it more clearly if that's indeed the case. (FWIW the note that the TEEP Agent can start with a QueryResponse if it has the TAM public key is IMHO incorrect.)



***) I don't see any use for it.



****) I don't see a need to use HTTP-based client authentication



*****) The text is currently very fuzzy. It says "Redirects MAY be automatically followed." Based on what decision should a developer decide whether it wants to follow the redirect?



Ciao

Hannes







IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.