- From: Ludin, Stephen <sludin@akamai.com>
- Date: Tue, 2 Jul 2013 13:28:45 -0600
- To: HTTP Working Group <ietf-http-wg@w3.org>
On 7/2/13 12:12 PM, "David Morris" <dwm@xpasc.com> wrote:
>> > If we feel there is a security requirement here, it should be along
>> > the lines of:
>> >
>> > The host name specified in a PUSH_PROMISE must have a DNS entry
>> > which includes the IP address of server sending the PUSH_PROMISE.
>>
>> This would allow one domain on a VPS serve content for any other domain
>> on a VPS.
>
>Exactly what happens with HTTP/1.1 virtual hosts. The TCP connection is
>shared to serve data from multiple virtual hosts.
>
>I don't see this as a problem that needs to be prevented. If the
>PUSH_PROMISE doesn't make the offer, all that will happen is that
>the client will notice the common IP and make the request itself.
>All to negate the advantage of the PUSH methodology.
We also have to consider cases where load balancers and mapping systems
will provide ever rotating DNS resolutions and the resolution of a DNS
name to a set of IPs does not necessarily mean there are not other valid
IPs for that domain. It seems like the suggestion is:
CLIENT:
- Resolves domain1.com to ip set {1,2,3} ( for eg. )
- Sends request
SERVER
- Receives request for :host domain1.com
- Sends PUSH_PROMISE for :host domain2.com
CLIENT
- Receive PUSH_PROMISE for domain2.com
- Resolves domain2.com
- If resolution of domain2.com is not in set {1,2,3} reset the stream
Do I have that correct? If so, then I think we will run into a lot of
problems around matching the resolution of domain2.com to the IP set for
domain1.com. This is not an uncommon scenario for Akamai at least. All
this means is coming up with a security requirement that leaves the
feature useful is going to be tricky.
-stephen
Received on Tuesday, 2 July 2013 19:29:31 UTC