Re: #444: Flushing Alt-Svc Cache

It's not just security.  There is also the issue that some AltSvc responses
may be network context specific and may no longer be applicable when the
network changes.  (For example, they could reference rfc1918 space for an
intranet/vpn setup, or reference a server local to a mobile network, or
reference an IPv6-only AltSvc.  All of these might become inapplicable when
the network changes.  But Ryan has a good point that other use-cases may
not have this issue.  A flag might be valuable to indicate this, as
suggested.   (That's not to say we shouldn't also consider the security
aspect as well.)

       Erik



On Fri, Apr 25, 2014 at 8:45 PM, Mark Nottingham <mnot@mnot.net> wrote:

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