Re: HTTP/2.0 -04 candidate

Assuming that the IPs are mostly in the RRSET, so long as any IP from the
resolution (which is actually hostname -> RRSET, as opposed to hostname ->
IP as many (including me normally) forget), this may be a smaller problem
than you think.

Of course, that all depends on how stable the RRSETs are, and I don't know
about Akamai's RRSET stability!
-=R


On Tue, Jul 2, 2013 at 12:28 PM, Ludin, Stephen <sludin@akamai.com> wrote:

>
>
> 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
>
>
>
>
>
>
>
>