Subject: #444: Flushing Alt-Svc Cache

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Apr 2014 10:34:18 +1000

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Apr 2014 21:26:33 -0700

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.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Apr 2014 14:29:31 +1000

Agreed; we could mention that with a MAY...

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 25 Apr 2014 07:28:24 -0700

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 <[email-masked]> wrote:

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Apr 2014 09:24:18 -0700

On 25 April 2014 07:28, Ryan Hamilton <[email-masked]> wrote:
> I would be inclined to suggest that we modify Alt-Svc to explain the policy
> to the client.

That suggests a flag: when set it means that this alternative is
global and does not need to be flushed when network environments
change.  Load shifting and other use cases wouldn't need to set the
flag.

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 25 Apr 2014 09:58:51 -0700

> change.  Load shifting and other use cases wouldn't need to set the

​A flag could work. Alternately, the server could send a IP range and as
long as the client is in the range it could continue to use the mapping.
Perhaps that's overly complicated, though.

Cheers,

Ryan​

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Apr 2014 10:01:30 -0700

On 25 April 2014 09:58, Ryan Hamilton <[email-masked]> wrote:
> A flag could work. Alternately, the server could send a IP range and as long
> as the client is in the range it could continue to use the mapping. Perhaps
> that's overly complicated, though.

That couldn't possibly go wrong.</sarcasm>

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 26 Apr 2014 10:45:59 +1000

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,

> On 26 Apr 2014, at 12:28 am, Ryan Hamilton <[email-masked]> 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.
> 
> 
>

---

From: Erik Nygren <[email-masked]>
Date: Fri, 25 Apr 2014 21:13:50 -0400

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 <[email-masked]> 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,
>
> --