Skip to content

Persistence of alternates across network changes #71

Closed

Description

@MikeBishop

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.

Activity

  1. martinthomson commented on May 28, 2015

    @martinthomson
    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).

  2. mnot commented on May 31, 2015

    @mnot
    Member

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

  3. mnot commented on Jul 21, 2015

    @mnot
    Member

    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions