New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persistence of alternates across network changes #71

Closed
MikeBishop opened this Issue May 28, 2015 · 3 comments

Comments

Projects
None yet
4 participants
@MikeBishop
Contributor

MikeBishop commented May 28, 2015

Alternates provided because of location (seattle.edge.net vs. sfc.edge.net) need to be cleared on network changes. (They’re probably direct pointers to individual nodes/datacenters.) Alternates provided because of capabilities (sni.edge.net as alternate of legacy.edge.net) shouldn’t be cleared on network changes, because they’re not location-dependent. (The names probably resolve to different IPs based on location at the DNS level, or they resolve to anycast addresses.)

Should there be a hint to the client that a particular alternate does/doesn’t need to be flushed on changes? Might impact the issues described in 9.2, but TLS should still mitigate without the flushing.

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson May 28, 2015

Contributor

I think that flushing is the always-safe option. We can define extensions later if this turns out to be especially problematic (or the optimization that retention affords is especially attractive).

Contributor

martinthomson commented May 28, 2015

I think that flushing is the always-safe option. We can define extensions later if this turns out to be especially problematic (or the optimization that retention affords is especially attractive).

@reschke reschke added the alt-svc label May 30, 2015

@mnot mnot added the design label May 31, 2015

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot May 31, 2015

Member

See also #2. It's not clear that flushing a alt-svc used for oppsec is the safest thing.

Member

mnot commented May 31, 2015

See also #2. It's not clear that flushing a alt-svc used for oppsec is the safest thing.

@mnot

This comment has been minimized.

Show comment
Hide comment
@mnot

mnot Jul 21, 2015

Member

Discussed in Prague; add a parameter to do this now.

Member

mnot commented Jul 21, 2015

Discussed in Prague; add a parameter to do this now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment