Allow application servers to be identified by domain name

[eric-murray]

What type of PR is this?

• enhancement/feature

What this PR does / why we need it:

Currently, application servers can only be identified by a contiguous set of IP addresses within a defined subnet. This PR allows application servers to be identified by a domain name that resolves (at least within the network operator's own DNS service) to a limited list of IPv4 and IPv6 addresses.

Which issue(s) this PR fixes:

Fixes #513

Special notes for reviewers:

None

Changelog input

 release-note
 - Allow application servers to be identified by domain name

Additional documentation

None

[ilya-smirnov-berlin]

I find this suggested extension reasonable but have one remark.

If an API consumer has the ability to resolve a given domain name into a list of IP addresses automatically on the provider side and apply all of them to QoS flows, then the API should also allow the consumer to create a session using such an IP address list for the application server, rather than being limited to a single single network segment (single IP in particular case). For example:

  "applicationServer": {
    "ipv4Addresses": [ "98.138.91.63", "72.30.3.157", "66.163.190.174" ]
  }

Also we could think about a limitation of number of addresses in this list but also now many addresses can be used in case of DNS resolution on service provider side. Current classical DNS implementation has a limitation of the record size but still can return up to 15 addresses.

As already mentioned, DNS resolution results may differ from the consumer’s own resolution, even when using the same DNS server, due to region-based responses and load balancing. This behavior should be explicitly documented as warning to consumers.

[tlohmar]

@ilya-smirnov-berlin

If an API consumer has the ability to resolve a given domain name into a list of IP addresses automatically ....

My understanding is that the API consumer CANNOT resolve the IP address(es). This is a common issue, when content is hosted within a CDN. The Application Client resolves the IP addresses using an FQDN. The API consumer only knows the FQDN, which is used by the Application Client (can be multiple). The API consumer and the Application Client belong to the same Application (same Application Service Provider).

@eric-murray please correct, when my understanding is wrong.

[hdamker]

@ilya-smirnov-berlin

If an API consumer has the ability to resolve a given domain name into a list of IP addresses automatically ....

My understanding is that the API consumer CANNOT resolve the IP address(es). This is a common issue, when content is hosted within a CDN. The Application Client resolves the IP addresses using an FQDN. The API consumer only knows the FQDN, which is used by the Application Client (can be multiple). The API consumer and the Application Client belong to the same Application (same Application Service Provider).

@eric-murray please correct, when my understanding is wrong.

@tlohmar the important word is here "also" ... when the API anyway allows to work with list of IP addresses (in the result), then it make sense to allow such a list also as input.

[tlohmar]

thx for the clarification. I misunderstood this. Could make sense to modify the ApplicationServer parameter, allowing a list of IPs.

[jlurien]

Some comments/considerations:

• Changing the input schema to a list (array) of IP adresses, as sugegsted by Ilya, would break compatibility, unless we define the input schema as a oneOf/anyOf individual IP or array of IPs. This is something to be considered.

• If several identifiers (hostname, IPv4/v6 address(es)) are provided, it is specified that the service is applied to all of them, even if they identify totally unrelated servers. In the current API version this could also happen using one IPv4 and one IPv6, but not sure if that was the original intention or just to allow dual IP stacks for the same server. It would be something to clarify as it may have implications (the consumer could use this to enhance 2 unrelated services with one request, or might have implications for error handling).

  • Additionally, if applicationServerPorts are specified, those ports would apply to all identified servers. If the servers are unrelated, this mapping might be limiting or overly broad.

• Regarding the DNS resolution lifecycle, the specification may need to clarify that the mapping from domainName to IP addresses occurs at session creation time (one-time resolution). It may be noted that any subsequent changes to the DNS records during the session's lifetime will not be reflected in the active QoS flow. For this API is not as relevant as it is for other APIs in the family (provisioning, booking), if we apply the enhancement there.

• Maybe we have to remark also that the applicationServer in the response must be the same indicated in the request, without explicit translation to the IP addresses.

[eric-murray]

the API should also allow the consumer to create a session using such an IP address list for the application server

Changing the input schema to a list (array) of IP addresses, as suggested by Ilya, would break compatibility, unless we define the input schema as a oneOf/anyOf individual IP or array of IPs

The original issue did indeed propose allowing the API consumer to pass a list (i.e. array) of IP addresses. See "Alternative Solution".

That would be a breaking change unless we kept the existing properties, so we would end up with four possible ways of specifying IP addresses, all of which could be used in a single request:

  ...
  "applicationServer": {
    "domainName": ...,
    "ipAddresses": [...],
    "ipv4Address": ...,
    "ipv6Address": ...
  },
  ...

My (i.e. Vodafone's) requirements would be met just by adding the additional domainName property, but I have no objection to adding the ipAddresses property as well.

Trying to restrict the schema to only allow ipAddresses if neither ipv4Address nor ipv6Address is provided (and vice versa) is possible but, I think, unnecessarily complex. Better just to deprecate the ipv4Address and ipv6Address properties, and then drop them in a later breaking release.

[eric-murray]

My understanding is that the API consumer CANNOT resolve the IP address(es)

The specific issue was that our (potential) API consumer did not know which IP address was actually in use by the application. Their SDK could call DNS and obtain the list of IP addresses, but that DNS call would likely return the IP addresses in a different order to that returned to the application. So they would not know which IP address from the list that the application was actually using.

So either the domainName or ipAddresses list would work, but it is expected that the API consumer would find the domainName approach more "intuitive`.

[eric-murray]

Additionally, if applicationServerPorts are specified, those ports would apply to all identified servers. If the servers are unrelated, this mapping might be limiting or overly broad.

So all specified applicationServerPorts would (or, at least, should) get applied to all specified applicationServers. I agree this could be overly broad, though likely it would just mean some application server IP / port combinations would get prioritised for flows that just did not exist.

Typically, the application server port will be 443. Indeed, this is Vodafone's "default" if applicationServerPorts is not specified at all. So that approach continues to work even as the number of ways of specifying IP addresses is expanded.

If someone has a use case where different application server ports must be prioritised for different application server IP addresses as part of the same QoS session, they might like to propose a scheme to link specific ports to specific application server IP addresses.

[eric-murray]

Maybe we have to remark also that the applicationServer in the response must be the same indicated in the request, without explicit translation to the IP addresses.

For this PR, yes - indeed, it will usually not be possible to express the IP addresses associated a domain name using the current schema based on a single IPv6 and/or IPv6 subnet.

But I will separately propose a breaking change whereby the session creation response includes a list (i.e. array) of all application server IP addresses included in the QoS session, rather than the current ip4Address and ipv6Address parameters. That can be discussed separately to this PR, as it can be an independent change.

[eric-murray]

I will separately propose a breaking change whereby the session creation response includes a list (i.e. array) of all application server IP addresses included in the QoS session, rather than the current ip4Address and ipv6Address parameters

I have now opened issue #529

[eric-murray]

I added ipAddresses as an additional application server identifier. My proposal is a list of up to 16 individual IPv4 and/or IPv6 addresses.

Some considerations for the sub-project:

• Should we have separate lists for IPv4 and IPv6 addresses (i.e. ipv4Addresses and ipv6Addresses), or is mixed list OK?
• Is a maximum of 16 addresses too few, or too many?
• Should we remove or deprecate the ability to specify subnets using ipv4Address and ipv6Address?
  • If we want to keep the ability to specify subnets, should we keep ipv4Address and ipv6Address, or extend ipAddresses to allow a list of subnets to be specified?

[jlurien]

The last proposal considers one single domain and/or a list of IPv4/v6 addresses which may include subnets. Would it make sense to allow also a list of domains?

[eric-murray]

The last proposal considers one single domain and/or a list of IPv4/v6 addresses which may include subnets. Would it make sense to allow also a list of domains?

I'm proposing to drop support for subnets - see my comment here

Regarding domains, my preference would be that separate domains require separate QoS sessions. Of course, separate domains could be implicitly specified in the list of IP addresses, but I would prefer not to add explicit support for this.

If there are reasons that other domains need to be included, maybe for "net neutrality" reasons or to prioritise other domains to which the device may be redirected when using the specified domain, I think it is for the API provider to implement that "behind the scenes" rather than requiring the API consumer to be explicitly aware they need to specify it.