Re: I-D Action: draft-ietf-6man-rfc6874bis-03.txt

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> wrote:
    >> Brian E Carpenter <[e-mail]> wrote:
    >> > Noted that zone IDs have no length limit.
    >> I'm thinking about whether this is a hassle for IoT devices or not.
    >> What if we said they SHOULD NOT be longer than 1024?
    >> (or that, servers are allowed to return 500 error and give up at 1024 bytes
    >> of zone ID)
    >> Your text says:
    >> An implementation SHOULD apply a
    >> reasonable length limit in order to minimize the risk of a buffer
    >> overrun.
    >> An implementation of a *server*, or of a web browser?

    > Or even an o/s kernel, which is where these things are created. IMNSHO
    > RFC 4007 should have imposed a limit, but fixing that would need a different
    > draft. In the context of *this* draft I suppose it's the browser.

The browser is going to take whatever the OS gives it, and unless we write
down some limit, it has no idea what the server is going to accept.  Also
browsers tend to be much richer in their memory environment.

While the IoT devices with super-limited HTTP(S) interfaces are not so priviledged.

    >> What does a server do if it's too long?

    > What it does for any too-long URI, I guess.

Well, the set of URLs that the device needs to accept is mostly driven by the
architecture of the web interface of the device.  I can easily design my web
interface to deal with single-character /Z URLs if I want, and then I could,
dispatch off the first letter of the URI while parsing, and if it's invalid,
stop there.

The zoneID, however, I need to copy into a buffer, and then I think that I
need to annotate any full URLs that I emit with the zoneID.
(I think that 95% of the time, I can emit only relative URLs, but there may
be situations, such as password resets, that I need a full URLs)

    >> Would it be okay if we Updates RFC4007 here and set a huge upper limit?

    > I'm not sure it needs to be huge: the longest I've seen are things like
    > %enxc872efc170a9. We could do that, but is this draft the best place to
    > do it?

Well, 6man is at least the right place to have the conversation.
There seems to be some push back against this document on the basis that if
browser vendors do nothing, then what's the point?  Well, at least, limiting
the length of zoneIDs would be some small point.

Over in IOTOPS, and at the IoTSF ManySecured WG, we have been discussing how
to build Secure Useable Intranet Browser (SUIB).  This essentially amounts to
how can we do HTTPS (or some equivalent: OSCORE over CoAP [over BTLE?] is possible),
with IoT devices, given that it's really hard to give them public names.
One answer is that we will wind up with an Intranet focused browser as a new
executable.  Such a browser would definitely need to implement zoneIDs
properly.
(How to fund such an effort on an ongoing fashion is an open question)


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-