Re: #444: Flushing Alt-Svc Cache

Hi Ryan,

This requirement was put into alt svc to address a security concern; a mitm could inject an alt svc to interpose an intermediary of their choice, and have the interposition persist beyond the local network. 

I think such a flag could work, as long as the alternative service were discovered on a secure channel (with hand waving about what "secure" means TBD - need to consider things like TLS mitm, chains of alt svc). 

Cheers,

--
Mark Nottingham  http://www.mnot.net/

> On 26 Apr 2014, at 12:28 am, Ryan Hamilton <rch@google.com> wrote:
> 
> I'm concerned about this requirement. With QUIC, we rely on Alternate-Protocol (the intellectual equivalent of Alt-Svc) to discover QUIC. When the alternate service is unknown, the first request goes over the traditional transport. Once the response is received, a new transport can be spun up, but since this might not succeed, we generally end up sending the second request over the existing established connection, while the alternate connection is established. Eventually requests finally start flowing over the alternate connection. But this is quite unfortunate. The performance benefits of the alternate service can be severely impacted.
> 
> If we think that the alternate services advertised by some servers will be network specific, then I would be inclined to suggest that we modify Alt-Svc to explain the policy to the client. This would allow other servers which do not serve network-specific alternate services to permit client to continue using alternate services across network changes.
> 
> With the increasing prevalence of mobile devices, the issue of changing networks will become increasingly common. If every time a mobile device changes IP it has to stop using alternate services, this would be a real performance hit.
> 
> 
> 
>> On Thu, Apr 24, 2014 at 9:29 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> Agreed; we could mention that with a MAY...
>> 
>> 
>> On 25 Apr 2014, at 2:26 pm, Martin Thomson <martin.thomson@gmail.com> wrote:
>> 
>> > I think that's workable.  The cost is that certain classes of device
>> > will perform discovery a lot.  Those devices could maintain
>> > per-network caches for alt-svc, I suppose.
>> >
>> > For example, my phone goes from home, to a mobile network, to the
>> > office quite often, it would be nice if alt-svc for my home were able
>> > to be reused when I return in the evening, subject to the TTL, of
>> > course.
>> >
>> > On 24 April 2014 17:34, Mark Nottingham <mnot@mnot.net> wrote:
>> >> <https://github.com/http2/http2-spec/issues/444>
>> >>
>> >>> For the load balancing use case, it's necessary for clients to always flush altsvc cache upon a network change, but right now they're only required to examine the cache for suspicious entries. We should discuss whether this should be upgraded to always flush.
>> >>
>> >> I think the logical proposal would be to change <http://http2.github.io/http2-spec/alt-svc.html#caching>
>> >>
>> >> """
>> >> To mitigate risks associated with caching compromised values (see Section 7.2 for details), user agents should examine cached alternative services when they detect a change in network configuration, and remove any that could be compromised (for example, those whose association with the trust root is questionable). UAs that do not have a means of detecting network changes should place an upper bound on their lifetime.
>> >> """
>> >>
>> >> to read:
>> >>
>> >> """
>> >> To mitigate risks associated with caching compromised values (see Section 7.2 for details), user agents should remove all cached alternative services when they detect a change in network configuration. UAs that do not have a means of detecting network changes should place an upper bound on their lifetime.
>> >> """
>> >>
>> >> Thoughts?
>> >>
>> >>
>> >> Cheers,
>> >>
>> >> --
>> >> Mark Nottingham   http://www.mnot.net/
>> >>
>> >>
>> >>
>> >>
>> 
>> --
>> Mark Nottingham   http://www.mnot.net/
>