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

multiplicity of remotes? #19

Open
britram opened this Issue Sep 13, 2017 · 12 comments

Comments

Projects
None yet
5 participants
@britram
Contributor

britram commented Sep 13, 2017

Sometimes you know that you want to try to build an association to multiple remote addresses (probably with the same security parameters, maybe with different ones) at initiation time -- kind of like the SCTP multihoming/multipath API. Since a Remote is a single endpoint (and I think it should stay that way), this means that everywhere we pass in a remote, we might want to pass in multiple ones...?

Related: Remotes resolve recursively. Sometimes you're going to want to multipath to multiple addresses all of which are associated by IN A or IN AAAA records to the same name (or are you...?). So the result of resolving a Remote is zero to many Remotes.

Yay.

@britram britram added the question label Sep 13, 2017

@mirjak

This comment has been minimized.

Show comment
Hide comment
@mirjak

mirjak Sep 13, 2017

Contributor

I guess you can also have multiple local you want to use for the same MP-connection, e.g. when you have multiple IP addresses or interfaces

Contributor

mirjak commented Sep 13, 2017

I guess you can also have multiple local you want to use for the same MP-connection, e.g. when you have multiple IP addresses or interfaces

@chris-wood

This comment has been minimized.

Show comment
Hide comment
@chris-wood

chris-wood Sep 15, 2017

Contributor

Could we coalesce a collection of Remotes for the same Association to a single type, e.g., Peer? (Unless I overlooked something, we use the term peer to describe this sort of relationship informally, yet never officially promote it as one of the main types.) Peer seems (to me) to capture the notion of a collection of related Remotes coupled with the same Association. Especially if the security parameters are shared.

Contributor

chris-wood commented Sep 15, 2017

Could we coalesce a collection of Remotes for the same Association to a single type, e.g., Peer? (Unless I overlooked something, we use the term peer to describe this sort of relationship informally, yet never officially promote it as one of the main types.) Peer seems (to me) to capture the notion of a collection of related Remotes coupled with the same Association. Especially if the security parameters are shared.

@mirjak

This comment has been minimized.

Show comment
Hide comment
@mirjak

mirjak Sep 18, 2017

Contributor

Not sure if we need that because that's probably what we have the association for.

Contributor

mirjak commented Sep 18, 2017

Not sure if we need that because that's probably what we have the association for.

@chris-wood

This comment has been minimized.

Show comment
Hide comment
@chris-wood

chris-wood Sep 18, 2017

Contributor

Hmm... possibly. I see the Association doing much more. It binds Locals and Remotes together, stores trust model information, crypto state, etc. The idea above would collate multiple related Remotes and fit in the same Association.

Contributor

chris-wood commented Sep 18, 2017

Hmm... possibly. I see the Association doing much more. It binds Locals and Remotes together, stores trust model information, crypto state, etc. The idea above would collate multiple related Remotes and fit in the same Association.

@britram

This comment has been minimized.

Show comment
Hide comment
@britram

britram Sep 19, 2017

Contributor

so these are two different things, and I'm pretty sure we want to keep them separate:

  1. Remotes not yet, er, associated with an Association. Remotes are multiresoultion; that is, a Remote may represent just a name, or a name and address, or in a magical future with working DNSSEC+DANE or RAINS, even a full pinned certificate. Crucial here is that a remote contains no information that an endpoint must connect or preconnect to derive.

  2. Remotes associated with an Association. I think all the Remote-scoped information that an endpoint gets from a connection or preconnection attempt ("certificates I've already seen") belongs either in the Path (since we don't know whether or not the Local from which we connect will affect the peer's behavior or the behavior of path elements between us and the peer) or in something like the proposed Peer.

Contributor

britram commented Sep 19, 2017

so these are two different things, and I'm pretty sure we want to keep them separate:

  1. Remotes not yet, er, associated with an Association. Remotes are multiresoultion; that is, a Remote may represent just a name, or a name and address, or in a magical future with working DNSSEC+DANE or RAINS, even a full pinned certificate. Crucial here is that a remote contains no information that an endpoint must connect or preconnect to derive.

  2. Remotes associated with an Association. I think all the Remote-scoped information that an endpoint gets from a connection or preconnection attempt ("certificates I've already seen") belongs either in the Path (since we don't know whether or not the Local from which we connect will affect the peer's behavior or the behavior of path elements between us and the peer) or in something like the proposed Peer.

@chris-wood

This comment has been minimized.

Show comment
Hide comment
@chris-wood

chris-wood Sep 19, 2017

Contributor

Ah, yes! Good point. I'm speaking specifically about the second variant. I don't want to cause confusion with yet another type. However, it seems strange that we'd overload Path to contain certain information that's scoped to a Remote, yet unrelated to the more transport-y elements of a Path.

Contributor

chris-wood commented Sep 19, 2017

Ah, yes! Good point. I'm speaking specifically about the second variant. I don't want to cause confusion with yet another type. However, it seems strange that we'd overload Path to contain certain information that's scoped to a Remote, yet unrelated to the more transport-y elements of a Path.

@tfpauly

This comment has been minimized.

Show comment
Hide comment
@tfpauly

tfpauly Sep 22, 2017

Contributor

We've had explicit requests in our stack to add support for an array of Remotes when creating a connection/Carrier. I pushed back on these, and we instead allowed the creation of custom Remotes that can have overrides for how they resolve. That way, there is always still one remote object handle that can be associated with the Carrier or Association to represent the grouping of possible resolved endpoints.

Contributor

tfpauly commented Sep 22, 2017

We've had explicit requests in our stack to add support for an array of Remotes when creating a connection/Carrier. I pushed back on these, and we instead allowed the creation of custom Remotes that can have overrides for how they resolve. That way, there is always still one remote object handle that can be associated with the Carrier or Association to represent the grouping of possible resolved endpoints.

@chris-wood

This comment has been minimized.

Show comment
Hide comment
@chris-wood

chris-wood Sep 22, 2017

Contributor

(Now going to Brian's first variant.) Would it then be correct to say that a Remote is not a single endpoint -- it's a single logical endpoint with possibly different resolution strategies. The discrepancy Brian describes in the multihoming/multipath case is exactly this.

Contributor

chris-wood commented Sep 22, 2017

(Now going to Brian's first variant.) Would it then be correct to say that a Remote is not a single endpoint -- it's a single logical endpoint with possibly different resolution strategies. The discrepancy Brian describes in the multihoming/multipath case is exactly this.

@britram

This comment has been minimized.

Show comment
Hide comment
@britram

britram Oct 12, 2017

Contributor

To discuss in Singapore: what are the different ways that Remotes can be related to each other, and how are these discovered?

Contributor

britram commented Oct 12, 2017

To discuss in Singapore: what are the different ways that Remotes can be related to each other, and how are these discovered?

@britram britram added the discuss label Nov 8, 2017

@britram

This comment has been minimized.

Show comment
Hide comment
@britram

britram Nov 16, 2017

Contributor

I think the Remote looks something like this:

type Remote interface {
    // Get zero or more Remotes at the next level of resolution
    []Remote Resolve() error
}

If an application wants to determine how, specifically, it wants resolution to happen, it can override this interface. How an implementation's resolution works in a way to allow applications to do something useful here is probably implementation dependent...

There needs to be some way to get information of a given type out of a Remote. This might be implementation-dependent.

Remote resolution descent yields a DAG, not necessarily a tree.

Contributor

britram commented Nov 16, 2017

I think the Remote looks something like this:

type Remote interface {
    // Get zero or more Remotes at the next level of resolution
    []Remote Resolve() error
}

If an application wants to determine how, specifically, it wants resolution to happen, it can override this interface. How an implementation's resolution works in a way to allow applications to do something useful here is probably implementation dependent...

There needs to be some way to get information of a given type out of a Remote. This might be implementation-dependent.

Remote resolution descent yields a DAG, not necessarily a tree.

@britram

This comment has been minimized.

Show comment
Hide comment
@britram

britram Nov 16, 2017

Contributor

Locals are discussed in another issues...

Contributor

britram commented Nov 16, 2017

Locals are discussed in another issues...

@britram britram changed the title from multiplicity of remotes and locals? to multiplicity of remotes? Nov 16, 2017

@csperkins

This comment has been minimized.

Show comment
Hide comment
@csperkins

csperkins Nov 16, 2017

Contributor

Does this become?

type Remote interface {
    // Get zero or more Remotes at the next level of resolution
    []Remote Resolve(Local) error
}

Local specified so we know the pvd to resolve from

Contributor

csperkins commented Nov 16, 2017

Does this become?

type Remote interface {
    // Get zero or more Remotes at the next level of resolution
    []Remote Resolve(Local) error
}

Local specified so we know the pvd to resolve from

@britram britram added writeme and removed discuss question labels Nov 16, 2017

@britram britram self-assigned this Nov 16, 2017

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