Re: New Version Notification for draft-nottingham-structured-headers-00.txt

On Fri, Nov 03, 2017 at 10:51:02AM +1100, Mark Nottingham wrote:
> > As you have stated, each endpoint will have their own limits, and they
> > would not be able to handle values above that. So I basically agree
> > with you that having a limit does not improve interoperability, while
> > making things complicated.
> 
> I think I'm going to push back on that. 
> 
> Having a limit defined in structured headers means that a header defined
> using them is guaranteed that receiving implementations will be able to
> handle a known set of values. If the recipient doesn't, it isn't properly
> implementing structured headers, so the only thing it can do is ignore the
> header -- the correct behaviour for any header that isn't implemented.
> 
> We *could* specify a minimum bar (e.g., "all implementations must be able to
> handle integers at least as big as 2**32"), but then larger integers would
> work with some implementations, while not work with others -- which is an
> interoperability problem.
> 
> A header that might use those larger values would then need to specify how to
> handle that error. Since the whole point of structured headers is to take as
> much of that work off of the shoulders of header authors as possible, that
> doesn't seem good.

I'd rather proceed differently :
  - indicate a limit for sent values which serves as a minimum size for
    received value *to be compliant*. Eg: "if you send values no greater
    than 2^32-1, and can parse values as large as 2^32-1, you are expected
    to be interoperable with any compliant implementation

  - indicate how to safely detect overflows and how to deal with them

  - recommend to support larger values on receipt based on the fact that
    most machines where performance matters support 64 bits nowadays, so
    that you can be mostly compliant with non-compliant implementations

Then remains the problem of intermediaries which forward stuff they don't
have to analyse but it's not that much of a problem.

A possible solution derivating from the suggestions above could simply be
to define a few profiles for Structured Headers :
  - SH0 : the lowest level, implementations do not support receiving as
    large values as specified in next level (eg: my alarm clock's ESP8266
    possibly)

  - SH1 : sends and receives up to 2^32-1

  - SH1+: sends up to 2^32-1, receives up to 2^63-1

  - SH2 : sends and receives up to 2^63-1

This way we know that implementations within a same profile are interoperable,
that SH1 and SH1+ are interoperable, and that SH1+ and SH2 are as well. SH1
and SH2 are not, and SH0 is "good luck" (giving incentive to at least reach
SH1).

> If an intermediary finds an integer greater than 2**64 in a value, you're
> saying that it is required to forward it? What if it's e.g., 2**2048?
> 2**16384?

As long as it doesn't *need* it, yes. It's just passing the data as-is
without analyzing it.

> Intermediaries inspect header values all the time, and they need to be able
> to refuse to forward a message for any reason. E.g., Web Application
> Firewalls.

I disagree, intermediaries inspect almost nothing except what they need for
their own use. A WAF would need to have a rule to inspect that header, and
as such it becomes a recipient for that value and must parse it correctly.
If it fails to parse it, it cannot find the value and has to reject it. But
as long as it has no rule for that header, it has no reason for being
affected at all, that's just opaque data.

For me interoperability is really defined by who *consumes* the data, not
all those possibly on the path. Similarly the data flows through your router
and the router doesn't care about the contents in the TCP segments which
compose the IP packets it routes.

Willy

Received on Friday, 3 November 2017 05:54:12 UTC