Subject: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 27 Sep 2016 15:29:39 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-core-http-mapping-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is going to be a Yes position after we talk, of course ...

Someone can tell me to relax, but I found this text

   When found in a Hosting HTTP URI, the scheme (i.e., "coap" or
   "coaps"), the scheme component delimiter (":"), and the double slash
   ("//") preceding the authority MAY be omitted.  In such case, a local
   default - not defined by this document - applies.

   So, http://p.example.com/hc/s.coap.example.com/foo could either
   represent the target coap://s.coap.example.com/foo or
   coaps://s.coap.example.com/foo depending on application specific
   presets.
   
worrisome - is it saying that if you leave off the scheme, you don't know
whether the resulting mapped URI is coap:// or coaps://? If so, how
critical is it that this isn't deterministic? 

Can the HTTP client tell whether the result used coaps://?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In this text from the Abstract,

   This document
   covers the Reverse, Forward and Interception cross-protocol proxy
   cases.
   
are Reverse, Forward, and Interception proxys so well understood that the
average reader would know what you're talking about? Do I understand that
they're defined directly in this document, not referencing some other
draft?

Further in the document, I see this text,

   Note that the guidelines apply to all forms of an HC proxy (i.e.,
   Reverse, Forward, Intercepting) unless explicitly otherwise noted.
   
which makes me wonder if you need to mention the various forms of HC
proxy in the Abstract at all ...

This text,

   Note that a Reverse Proxy appears to an HTTP client as an origin
   server while a Forward Proxy does not.  So, when communicating with a
   Reverse Proxy a client may be unaware it is communicating with a
   proxy at all.
   
would be clearer if it followed the definition of Reverse Proxy. In the
current document, Reverse Proxy is defined, then Interception Proxy is
defined, and then this note refers back to the Reverse Proxy definition.
Confusingly, aren't clients unaware they're communicating with an
Interception Proxy, as well?

It's easy for me to read this text,

   See Figure 1 for an example deployment scenario.  Here a HC proxy is
   located at the boundary of the Constrained Network domain, to avoid
   sending any HTTP traffic into the Constrained Network and to avoid
   any (unsecured) CoAP multicast traffic outside the Constrained
   Network.  
   
as saying that secured CoAP multicast traffic might be sent outside the
Constrained Network. Is that what you meant?

In this text,

   The HC proxy is furthermore
   configured to only pass through GET requests in order to protect the
   constrained network.
   
did you mean "GET requests and their corresponding responses"?

In this text,

   The default URI mapping function SHOULD be implemented and activated
   by default in a HC proxy, unless there are valid reasons, e.g.,
   application specific, to use a different mapping function.
   
I found myself wondering if you could point to a valid use of a different
mapping function. That would have been helpful to me.

In this text,

   However, it should be noted that in certain cases, transcoding can
   lose information in a non-obvious manner.  For example, encoding an
   XML document using schema-informed EXI encoding leads to a loss of
   information when the destination does not know the exact schema
   version used by the encoder, which means that whenever the HC proxy
   transcodes an application/XML to application/EXI in-band metadata
   could be lost.  Therefore, the implementer should always carefully
   verify such lossy payload transformations before triggering the
   transcoding.
   
I didn't understand how you "verify" payload transformations. Is that a
well-understood term of art for the community?

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Thu, 29 Sep 2016 23:51:51 +0000

Hi Spencer,

Thanks very much for your review and sorry for my late reply.

On 27/09/2016 23:29, "core on behalf of Spencer Dawkins"
<[email-masked] on behalf of [email-masked]> wrote:
>whether the resulting mapped URI is coap:// or coaps://?

That's right -- for the "simple form".  However, the choice to omit the
scheme is either taken unilaterally by the client (and therefore it is
going to get what it deserves, most probably a 4xx error straight from the
proxy), or it's agreed upon between the HC proxy and the client out of
band.  The latter is the way one vendor implemented it, and what the text
documents.  (The OOB agreement could be such that coaps URIs are anchored
to hc-proxy.example.com/secure whereas coap URIs are sent to
hc-proxy.example.com/plain-text.)

>If so, how critical is it that this isn't deterministic?

For the reasons given above, it doesn't look that dodgy to me.

>Can the HTTP client tell whether the result used coaps://?

No, if it's using the simple form and there is no OOB agreement.  So, I
guess the question is: do you think it'd be better to spell this out
explicitly?  If so, we could say that a Target CoAP URI without the scheme
is not allowed unless there is an OOB agreement between client and HC
proxy (client MUST NOT emit / proxy MUST return 4xx on receipt).  Or do
you have something different in mind?

>average reader would know what you're talking about?

I'd hope so, but case [s]?he isn't, in section 2 we provide succinct
definitions for each of the proxy types plus references to RFC 7230, 7252
and 3040.

>Do I understand that they're defined directly in this document, not
>referencing some other draft?

See above.

>proxy in the Abstract at all ...

Sorry, I don't understand the issue :-(

>would be clearer if it followed the definition of Reverse Proxy.

Yes, it's probably better as you suggest.  Will move the block.

>Interception Proxy, as well?

mmm, clients aren't "communicating" with an Interception Proxy, it's just
a middle-box.

>Constrained Network. Is that what you meant?

No, it's not what we meant.  We'll remove "(unsecured)".

>did you mean "GET requests and their corresponding responses"?

Yes, yes.  I'm not sure adding that explicitly makes it clearer though.

>mapping function. That would have been helpful to me.

I guess a non-default mapping would be handy if the proxy needs more
freedom when setting up its URI namespace.

>well-understood term of art for the community?

I'm leaving it for later as I need to check it with my co-authors.

Thanks again, cheers,
t

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 30 Sep 2016 10:07:30 -0500

Hi, Thomas,

> hc-proxy.example.com/plain-text.)

I didn't get that from "local default". Your explanation was extremely
helpful.

> you have something different in mind?

 That's exactly what i had in mind. It seems much less likely to result in
someone making the wrong assumption.

> definitions for each of the proxy types plus references to RFC 7230, 7252

Right, but our theory is that Abstracts make sense without reading the
document itself. We're told there are people who publish Abstracts without
providing the RFC text itself, so the definition isn't readily available.

See above.

Unless there are other types of proxies, just saying "This document covers
all forms of proxies." would solve that problem.

> mmm, clients aren't "communicating" with an Interception Proxy, it's just

Ah, now I understand. But since you moved the text block forward, it's
clear what you mean.

> No, it's not what we meant.  We'll remove "(unsecured)".

Thanks.

> Yes, yes.  I'm not sure adding that explicitly makes it clearer though.

You may be right :-)

> freedom when setting up its URI namespace.

Right. I'm asking (at the non-blocking comment level) if you could give an
example of why it might need more freedom.

The point of a SHOULD for me is "unless you understand the consequences". A
SHOULD with no explanation leaves the implementer to try to understand
whether the implementer is doing something the specification writer
anticipated.

> I'm leaving it for later as I need to check it with my co-authors.

Sure, and thanks for checking.

Spencer

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 30 Sep 2016 16:26:16 +0000

Hi Spencer,

 That's exactly what i had in mind. It seems much less likely to result in someone making the wrong assumption.

Great!  Please see whether this suits you:

   When found in a Hosting HTTP URI, the scheme (i.e., "coap" or
   "coaps"), the scheme component delimiter (":"), and the double slash
   ("//") preceding the authority MAY be omitted if a local default -
   not defined by this document - applies.  If no prior mutual agreement
   exists between the client and the HC proxy, then a Target CoAP URI
   without the scheme component is syntactically incorrect, and
   therefore:
   o  it MUST NOT be emitted by clients;
   o  it MUST elicit a suitable client error status (i.e., 4xx) by the HC proxy

Right, but our theory is that Abstracts make sense without reading the document itself. We're told there are people who publish Abstracts without providing the RFC text itself, so the definition isn't readily available.

Ah OK!  Now I understand what you meant :-)

Unless there are other types of proxies, just saying "This document covers all forms of proxies." would solve that problem.

I think I could even get rid of the whole sentence and let the details for later…

Ah, now I understand. But since you moved the text block forward, it's clear what you mean.

OK

Thanks.

You may be right :-)

:-)

Right. I'm asking (at the non-blocking comment level) if you could give an example of why it might need more freedom.

The point of a SHOULD for me is "unless you understand the consequences". A SHOULD with no explanation leaves the implementer to try to understand whether the implementer is doing something the specification writer anticipated.

I think part of the confusion here is due to the fact that the SHOULDs are actually two:

  1.  It SHOULD implement the default mapping;
  2.  It SHOULD have the default mapping configured as the default.

So that:

  *   It's always possible to replace box from vendor A with box from vendor B, and
  *   The reconfiguration needed when deploying B in lieu of A is minimal (possibly zero).

What about:

   The default URI mapping function SHOULD be implemented and SHOULD be
   activated by default in a HC proxy, unless there are valid reasons,
   e.g., application specific, to use a different mapping function.

?

So, after internal consultations we came up with this (which also covers one of Stephen's comments):

   […]
   However, there are at least two important factors to keep in mind
   when implementing and enabling a transcoding function:

   1.  Maliciously crafted inputs coming from the HTTP side might
       inflate in size (see for example Section 4.2 of [RFC7049]),
       therefore creating a security threat for both the HC proxy and
       the target resource;

   2.  Transcoding can lose information in non-obvious ways.  For
       example, encoding a XML document using schema-informed EXI
       encoding leads to a loss of information when the destination does
       not know the exact schema version used by the encoder, which
       means that whenever the HC proxy transcodes an application/XML to
       application/EXI in-band metadata could be lost.

   It is crucial that these risks are well understood and carefully
   weighed against the actual benefits before deploying the transcoding
   function.

What do you think?

Cheers, t

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 30 Sep 2016 20:49:14 +0300

Hi Thomas,

> you have something different in mind?

An alternative is to always require coaps in this case. Might not work for your type of document though.