ExcludeRegions/LimitRegions Client Supplier Null/Empty Region Specification

[acioc]

We should have a clear specification around the behavior of the ExcludeRegions/ LimitRegions client suppliers and ensure this behavior is matched by all ESDK's. Although most/all ESDKs interpret the definitions of these client suppliers in similar ways, the behavior of handling null/empty regions could be different.

Specifically..

1. How does the LimitRegions client supplier handle null/ no regions? If no region is passed in, should the client supplier GetClient fail? Proposal: Yes, it should fail, since there's no way to know if the default region (which will be host dependent) is part of the limited regions to get clients for.
2. How does the ExcludeRegions client supplier handle null/ no regions? If no region is passed in, should the client supplier GetClient fail? Proposal: Yes, it should fail, since there's no way to know if the default region (which will be host dependent) is part of the regions to avoid.

I believe that, currently, some ESDKs just check region in regions or !(region in regions) but this behavior (and the handling of nulls) could be language specific.

[seebees]

The question is does this happen before or after the call to the underlying supplier. If it happens before then I assert that you should put in whatever value will be used to denote "Let the SDK work out the region"

[mattsb42-aws]

The way I interpret the two is:

• AllowRegion
  • This client supplier MUST accept one or more region name values.
  • This client supplier MUST block any requests for values not in that list.
• DenyRegion
  • This client supplier MUST accept one or more region name values.
  • This client supplier MUST block any requests for values in that list.

Carrying on from that, as @seebees stated, one valid value for "region name value" is "whatever indicates to a client supplier that the desired region is unknown".

[lavaleri]

I feel like letting the user specify "idk" in the region list could be very easy to misunderstand if not documented properly. (and maybe even if documented properly...)

e.g.

For excludeRegionsClientSupplier, it would be very easy for a user to make the assumption that, if region A is in that list of excluded regions, that means I can assume that this client supplier will never pass me a client from region A. In order to make these assumptions, a user will have to make sure they configure that list with "idk".

For a limitRegionsClientSupplier, it would be very easy for a user to make the assumption that, because region A is not in that list of allowed regions, that means I can assume that this client supplier will never pass me a client from region A. In order to make any such assumption, they will need to make sure "idk" is not in that list.

If we want to allow this value in the exclude/limitRegionList, then I would want to make it explicitly clear to users that these suppliers aren't making promises about the clients they deliver, they are only making promises about whether they make requests on certain inputs.

[acioc]

I support @lavaleri 's view on this. It seems disingenuous to have an exclude supplier that says "exclude us-west-2" but since my host defaults to "us-west-2", and I call GetClient with no region, I can still get back a "us-west-2" client.

It seems a lot safer to prevent this and allow customers to implement their own client suppliers if they're okay with this behavior as opposed to allowing this open for interpretation.

[seebees]

There is a check before/check after problem, that I would leave to the implementation. It is not that I disagree that limit(A, B, C (r) => r === '' ? A : r ) is a difficult case. But the behavior for these two functions is backwards.

As the problem is described, limit has an intuitive behavior in the case of '' being excluded. Where as exclude only has this intuitive behavior in the case where I include ''.

Again, checking the region again after the client is created completely removes this problem.

[acioc]

Is there a good way to get the region after the client is created in all ESDK implementations? It sounds like the proposal here is to get a client, but then check the region before actually returning it (as opposed to not constructing it at all if it's not necessary).

[mattsb42-aws]

nit: We would want to check both before and after client generation.

Is there a good way to get the region after the client is created in all ESDK implementations?

I can't speak with certainty for all, but I think it would probably be a reasonable assumption that there is.

• Java
• Python

[mattsb42-aws]

Updating from offline discussions, I think we're in agreement on the following:

For brevity, I will be referring to both the allow regions and deny regions client suppliers collectively as "region filtering client suppliers".

• Region filtering client suppliers MAY accept the "unknown region" identifier in their filtering input.
  • If supplied, this value MUST be filtered the same as any known region name.
• Region filtering client suppliers MUST filter before obtaining a client.
• Region filtering client suppliers SHOULD filter after obtaining a client.
  • This is to account for the case where the "unknown region" identifier is not blocked, a request comes in with that value, and when the client resolves that to a region, the resulting region is intended to be blocked.
  • This is a SHOULD rather than a MUST because we are not certain that there is an effective way to check the region of a client instance. If we determine that there is, we will update this to a MUST.

[acioc]

Closing in favor of https://github.com/awslabs/aws-encryption-sdk-specification/issues/165