>>>>> "Ray" == Ray Hunter <v6...@globis.net> writes:
Ray> Warning: post contains dumb questions.
good. That usually mean that the document says something dumb.
>>> Michael raised an interesting issue, and we have to analyze
>>> it. The consensus of the working group so far is that interface
>>> identifiers are private to the host, that any leakage outside
>>> the host should be prevented, and that a way to prevent that
>>> leakage is to ask proxies to erase them whenever they have an
>>> opportunity. Michael points that some servers take an opposite
I have a stupid question.
What does it mean to have an interface identifier go through an HTTP proxy?
Given that a proxy works by having the client send the entire URL on the
GET line, it means that my web browser would send something like:
GET http://[fe80::a%25en1]/printers/laserwrite
Host: [fe80::a%25en1]
to the proxy. Now, where is %en1 going to be interpreted?
On the proxy? How can the client have any idea what to send.
It can't mean anything on the client, because the entire URL
goes to the proxy.
Okay, so may this is a "transparent" proxy. (I.e. something that
violates end to end!) That means that the host made a request to
fe80::a on interface en1, and it turned out that to get there, some
device intercepted packets which were not supposed to leave the local
link, and well, I guess did something else to the data.
My take is that in this situation this device is doing something outside
of our entire architecture, and therefore that device is really the end
point, and it had better rewrite URLs appropriately.
>> Some background: HTTP and IPP services in printers include
>> absolute URIs in the content they return. For IPP this can be
>> http/https URLs to the printer's web page, ICC profiles, and
>> other resources, along with the ipp/ipps URIs that the printer
>> supports. For HTTP the most common are https URLs for "secure"
>> areas of the printer's web interface. Because a printer is often
>> known by multiple names and addresses ("printer.local.",
>> "printer.example.com.", 192.168.0.100, fe80::1234, etc.), the
We have an existing problem in CUPS at least, that the certificates
generated for the https do not have all the valid names, nor can they.
>> All of this falls apart with link-local addresses and RFC 6874.
>> Because the client is required to remove the zoneid from the
>> outgoing request, the URIs it gets back from the server are no
>> longer "reachable".
I think that part of the bug is the return of absolute URLs. I question
whether that is truly necessary.. Why aren't relative URLs (rooted at /)
useable?
Ray> If the other party learns nothing, and the originating node just needs
Ray> to hear an echo of it's own information for it's own use, what's wrong
Ray> with using a cookie (server originated), or a hidden variable (client
Ray> originated), to transport this interface information along with the
Ray> request/reply?
That's new behaviour at a high-level.
Even so, I don't know how that could be done without some javascript or
something to do translation, which completely runs afoul of RESTful
interfaces, I think.
Ray> What if both the server AND the client have multiple interfaces: how do
Ray> they both know which local interface on their own node is mutually
Ray> connected and to be used for communication? There's only one single
Ray> zoneid in the URI, so presumably one of the nodes is lacking some
Ray> information.
The server never needs to specify it's link local address.
>> What I propose is that we change the wording to allow the zoneid
>> in the Host header but not in the Request-URI. HTTP proxies
>> would be required to strip any zoneid information in the Host
>> header. HTTP servers would be required to ignore any zoneid
>> information for purposes of address validation but include it for
>> any absolute URIs to the server they generate.
This seems nonsensical to me.
If the zoneid is not in the Request-URI, then how can the proxy do
anything with it? What address is in the Host: header that has a
meaningful zoneid?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
pgpPXVYz5KZmC.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
