Usage of IP Address to identify a Device in Traffic Influence API

[gunjald]

The FlowInfo parameter usage is described as "Identifies IP packet filters. To be used when a the Application needs a traffic flow towards a specific EAS interface".

If the FlowInfo parameter is optional then IP flow is expected to be identified by the UE Identity type as the IPAddress. In that case the userId of type IPAddress is typically specified as "IPv4 address and the Port" parameter. If the PORT parameter is not provided then the IPAddress may be assumed to be applied to all traffic flows originating from UE with the IP address provided in UE Identity.

The issue is that the TI API does not mention the expectation on the values the userId should carry if the identity type is IPAddress.
types_UEIdentity:
description: Identifier value for User Equipment. The type of identifier is defined by the 'UEIdentityType' parameter.

If the intent of the API when the userId is of type IPAddress is to apply traffic influence to only a specific IP flow then it should specify the reference to port number as well. Such a notion is followed in some of the other APIs e.g., "The public IP allocated to the device. If an IPv4 address is specified, the public port must also be specified".

So the suggestion is to make the description more clear in terms of the values to be used for userId parameter when the UE identity type is IPAddress.

[babunkj]

In the API, the UE Identity identifies the user/device to be influenced and traffic filters/flowInfo identifies the service to be influenced. In order to apply traffic influence on a specific IP flow, I suppose it is sufficient to identify the User using an IP Address (or MSISDN, GPSI etc in case the PDU session has not yet been established), and the specific ip flow information by coding it appropriately in the traffic filter.

[gunjald]

using

In general with other APIs as well, the public IP address of the device used for the user identification alone is not unique in my opinion. Typically the mobile networks uses a CGNAT device to assign public IP:Port pair to the outbound traffic which is NATed or mapped to internal IP and port for that traffic within the mobile network.

Hence in my opinion while other parameters like MSISDN, GPSI etc. still uniquely identify a user the public IP address along may not be sufficient to indicate a particular user unless an associated Port is also available.

Also, as a side note I think the API user should be able to use the MSISDN, GPSI or IP address equally without trying to determine if there is PDU Session for the user exists or not. Else it will make the API complex to use in my opinion.

[babunkj]

Since IP Address is assigned in most cases only after a PDU Session is created, IP Address has to be treated differently from the identifiers like MSISDN/External Identifier.
The developer may be aware of the IP Address depending on whether the IP session is already established or not. For example, if the session is established and the app client is connected to the Application server, the application is aware of the IP Address. The application may use the IP address to indicate specifically the device session to be influenced.
However, if the application provides only MSISDN/External Identifier, the OP can apply its intelligence to identify the session and act accordingly. It is a choice left to the developer.
Agree that for NAT'd scenarios for IPV4, either Public port should be available or allocated (local) IP Address of the device should be known.

[FabrizioMoggio]

@gunjald is this still an issue?

The issue, in my understanding, is if it is possible to identify a device via IP address. According to my understanding this is how also QoD identifies Devices (also Location Retrieval uses Device in the same way) and it is a possible general issue for any API that needs to identify a Device. If the issue still exists.

[gunjald]

As an example lets take an hypothetical case and say there are two users attached to same data plane and trying to access the same application i.e. "appID" (e.g., a gaming application) which maps the these users with same Public IP (NATed) but with different ports.
If such an IP address is received in the TI API which user will become the target of the API?
I see another parameter in the API : "trafficFilters": [
"TCP 5060"
]

If the understanding is that tuple ipv4Address, trafficFilters will resolve to a unique key then i would assume the API will not resolve to multiple targets.

[FabrizioMoggio]

@gunjald can this be the solution? #230

[gunjald]

If the understanding is that tuple ipv4Address, trafficFilters will resolve to a unique key then i would assume the API will not resolve to multiple targets.

I think if we agree with the understanding that the tuple "ipv4Address, trafficFilters" e.g. "82.129. XX.YY 5060 TCP" will resolve to a unique key then i would assume the issue of multiple targets will be resolved and we can close this issue.

[FabrizioMoggio]

@gunjald that is my understanding. @babunkj what do you think about?

[babunkj]

The device ipv4Address along with trafficFilters will uniquely identify a device along with the traffic that connects the device to a specific application server identified by the server address and port (given in the trafficFilter). However, let me mention two variants that comes in regarding device port handling. Let me put them down here for clarity:

Scenario 1: Device port required to identify a specific flow from the UE that needs to be influenced. An example is when the device supports distinct ports for different traffic and the traffic influence is to be applied only to one of them. Example, a device which provides low resolution and high-resolution video traffic using two different ports and only the high-resolution traffic is to be influenced.

For this scenario, @FabrizioMoggio had already suggested use of the solution discussed in #230 . Here, a Device Source IP Port can be introduced to identify the specific flow.

Scenario 2: Device port required to identify the device itself in case of natted scenarios. Here the public IP and port is required to uniquely identify the device.

This scenario is related to traffic being influenced from external EAS/Application servers. I suppose handling external IP address will be covered when we consider external EAS requirement.

[gunjald]

@babunkj can you please help how do you suggesting associate these three terms on Device Source IP Port, Device port and public IP and port to the device itself? Specifically w.r.t the API parameters
The trafficFilters to me seems to be containing only the port and protocol that points to the EAS or the application and not the device.
The device itself is identified with multiple parameters including the ipv4Address but then how the ipv4Address should be interpreted w.r.t Device Source IP or public IP should be agreed to reduce ambiguity.

To me as of now it seems the ipv4Address is for the device itself and the Port contained in the trafficFilters points to the Application(EAS). That indicate API does not have the device port(s) and the Application(EAS) IP parameters in it to derive unique keys based on IP:Port combination for either device or for EAS.

If this is true then we need to see if any of these should be considered to make room for either more granularity of traffic flow identification or to make the meaning of given parameters more clear.
But this is just my opinion as I understand from ongoing discussions and would like to know how can we bring in more clarity terms of the parameters usage by app developers.

[babunkj]

@gunjald
a) We could use three terms uniformly as given in Camara Commonalities:

• Public address and Public port (IPv4) of the device. They are the ones observed by the application server.
• Private address (Ipv4) of the device. This is the address allocated to the device.
  I am not sure if the fourth one that we are talking about - the device port, is used or referenced in any other APIs. Device port as discussed in the Traffic Influence case refers to the private / local port on which a specific traffic from the device is associated. This can, perhaps, be called private port of the device.

b) My understanding is that the current API does not support public address and port as device identifier. @FabrizioMoggio could confirm the same. These are required when the application server or EAS is external and there is NAT in between.

c) As you mentioned, the trafficFilters contain only the port and protocol that points to the EAS or the application server and not the device. The API description explains how to get the other components of the traffic filters. As we discussed in #230 , it may be required to add a private port of device to get the IP:port combination of the device and extend to a few more use cases. These need to be discussed.

[FabrizioMoggio]

what about: #230 (comment)

[gunjald]

I was checking the QoD API and the definition for device identification is now,
"ipv4Address": {
"publicAddress": "203.0.113.0",
"publicPort": 59765
},

I think this makes the device uniquely identifiable. The other identities like phoneNumber, networkAccessIdentifier are supposed to be unique and defining the ipv4Address as above will solve the problem. Here whatever stream of traffic we pick and use as "publicAddress : publicPort" in place of ipv4Address it will map to the same device. With this change the TI API should also be aligned with the usage of Device object defined for the other APIs like QoD.

And we can keep the trafficFilters definitions separate from the device identity issue so the other proposal from Fabrizio can be evolved independently of identity issue.

[FabrizioMoggio]

Implemented with: #249

[FabrizioMoggio]

merged Rel 0.9.5

[FabrizioMoggio]

I was checking the QoD API and the definition for device identification is now, "ipv4Address": { "publicAddress": "203.0.113.0", "publicPort": 59765 },

I think this makes the device uniquely identifiable. The other identities like phoneNumber, networkAccessIdentifier are supposed to be unique and defining the ipv4Address as above will solve the problem. Here whatever stream of traffic we pick and use as "publicAddress : publicPort" in place of ipv4Address it will map to the same device. With this change the TI API should also be aligned with the usage of Device object defined for the other APIs like QoD.

And we can keep the trafficFilters definitions separate from the device identity issue so the other proposal from Fabrizio can be evolved independently of identity issue.

@gunjald About the above comment, I need to verify with you If I got you right. I actually understood to be compliant with Device as defined in Commonalities (CAMARA_common.yaml), this also because QoD uses Device as defined in Commonalities. Was my understanding correct? I'm saying this because your example:

"ipv4Address": { "publicAddress": "203.0.113.0", "publicPort": 59765 },

differs from what Commonalities has defined: ipv4Address also contains privateAddress.

I have implemented in Rel 0.9.5 Device according to CAMARA_common.yaml. Is this fine with you?

[gunjald]

@FabrizioMoggio I picked up the example from the QoD API but i did not actually went to the commonality CAMARA_common.yaml. Hence my thinking was aligned to the usage of publicAddress, publicPort as those will be unique outside of the telco network too.

With private IP I am not sure how the uniqueness will be guaranteed as they may be used in overlapped ranges and very hard to say if the private IP ranges will have the uniqueness property in a telco network. Unless we handle the uniqueness part in context to private IP i think it will need to be discussed with other members in group on their opinion and way forward.

[babunkj]

@FabrizioMoggio @gunjald I would also suggest keeping the Device attribute compliant with the Commonalities as already given in version 0.9.5-wip. The interpretation of privateAddress, publicAddress and publicPort will be common across the APIs.

When there is no NAT, both publicAddress and privateAddress will be the same anyway.

I think the privateAddress can be unique at a given moment in the network, but not over time.

[gunjald]

@FabrizioMoggio @gunjald I would also suggest keeping the Device attribute compliant with the Commonalities as already given in version 0.9.5-wip. The interpretation of privateAddress, publicAddress and publicPort will be common across the APIs.

When there is no NAT, both publicAddress and privateAddress will be the same anyway.

I think the privateAddress can be unique at a given moment in the network, but not over time.

Thanks babu for your feedback. However I still have one observation for private addresses that considering the scenarios where we imagine the cloud based applications as the TI API invoker will be hosted on public IP itself and will see any IP packets from UE only with public IP address as UE source IP which I suppose will invariably via a NAT by the telco. A private IP will not be routable to external public networks hence NAT will be there in telco network. Unless say device client applications retrieve the private IP from device and provide in the application message body most of the time such external application will only see NATed public IP of the UE.
For this reason I still have doubts on the private IP usage in the API unless the deployment is e.g, private 5G and not for internet based applications say in industrial kind of use cases where the private IP can still work as the consumer applications may also be in the private IP networks.

So either the documentation is clear on such aspects on how to use the device IP and there is no gap which can lead to mapping an IP to multiple devices due to overlapped ranges of private IP. Just that there should not be any ambiguity in usage.

[babunkj]

Yes @gunjald . since NATing will generally be there, the application will mostly see only the publicAddress and publicPort. However, as you mentioned in situations like private networks, app clients sharing the privateAddress to the application servers directly or when the AFs are in operator's domain, the applications can be aware of the privateAddress. We can make some good documentation about these aspects so that user will be clear about the choices to make.

[FabrizioMoggio]

thank you all for the good comments. If we where an independent API developers I will define a Device attribute that perfectly fits our API. Because we are in a different situation, being part of CAMARA, unless we have very valuable reasons, I suggest to stick with Commonalities. With a good documentation, It is anyway a decision of the Developer which attribute to use among the one defined into Device. The point is that, that are all good to us if correctly used. Anyway the common scenario for the TI API foresees a Smartphone in mobility as source of the flow. In this scenario the PRIVATE IP is the one assigned by the CN and it is the one to be configured in the UPF.

[FabrizioMoggio]

proposal:

• update Device as defined in Commonalities
• update the documentation about Device (e.g. about external identifier) as defined in Commonalities
• https://github.com/camaraproject/Commonalities/pull/233/files#diff-8618fb9486dac0cc874d888f01c7fcf24a057e5fbe336e456f889059044f8f64

[babunkj]

Agree

[FabrizioMoggio]

one further comment:

to follow the Guidelines we also need to have Device as optional and we need to provide the documentation on how to get the phone number from the 3Legs process:

https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#appendix-a-infodescription-template-for-device-identification-from-access-token

I'm going to open a specific issue on this topic

[FabrizioMoggio]

#284