Update UeId definition in qod-api.yaml #123
Conversation
eric-murray
commented
Feb 24, 2023
eric-murray
commented
- Separate fields introduced for private or public UE IP address in UeId object
- Require port to be additionally specified if UE is identified by its public IP address
- Require public IP address to be additionally specified if UE is identified by its private IP address
- Clean up of example error messages for 400 errors and introduction of additional error examples
- Separate fields introduced for private or public UE IP address in UeId object - Require port to be additionally specified if UE is identified by its public IP address - Require public IP address to be additionally specified if UE is identified by its private IP address - Clean up of example error messages for 400 errors and introduction of additional error examples
eric-murray
requested review from
hdamker and
shilpa-padgaonkar
as code owners
hdamker
requested review from
akoshunyadi,
jlurien,
patrice-conil and
sfnuser
|
@jlurien @patrice-conil @sfnuser Would be great if you can review this PR from your point of view. |
| } | ||
| PrivateIpv4Addr: | ||
| description: | | ||
| Private (non-routable) source IP address directly allocated to the device, and the public (routable) source IP seen by and identifying the device to the application server. If the device does not have a public IP address, then the public_address value should be specified as the private address as well to indicate this. |
There was a problem hiding this comment.
| Private (non-routable) source IP address directly allocated to the device, and the public (routable) source IP seen by and identifying the device to the application server. If the device does not have a public IP address, then the public_address value should be specified as the private address as well to indicate this. | |
| Private (non-routable) source IP address directly allocated to the device, and the public (routable) source IP seen by and identifying the device to the application server. If the device does have a public IP address, then the public_address value should be specified as the private address as well to indicate this. |
Is my understanding correct? If the device has a public address, then copy the value as a private address as well. With private addresses only it is not always possible to identify the device. For this scenario the name private_ipv4_addr would be misleading. IMO device_ipv4_addr or local_ipv4_addr would cover better both situations.
There was a problem hiding this comment.
No, that is not how I intended this to work.
It works as follows:
Identify device by private IP address
IF the device has been directly allocated a private IP address
AND the API caller wishes to identify the UE by that private address
THEN the API caller uses the private_ipv4_addr field of ueId to pass both private and public (CGNATed) IP addresses
If the private IP address has NOT been NATed to a public address (this will not be the normal case), then the private address is copied to the public_address field to indicate this. This is the exception documented in the description for PrivateIpv4Addr.
So the text is correct
Identify device by public IP address
IF the device has been directly allocated a private IP address which has been CGNATed to a public address OR the device has been directly allocated a public IP address (this would be unusual)
AND the API caller wishes to identify the device by its public address
THEN the API caller uses the public_ipv4_addr field of ueId to indicate both the public_address and port allocated to the device (the port being required to uniquely identify the device in the case of CGNATing)
There was a problem hiding this comment.
Thanks Eric for the detailed clarification. This type of explanations would be useful also to be added to the API doc.
Then, for:
If the private IP address has NOT been NATed to a public address (this will not be the normal case), then the private address is copied to the public_address field to indicate this. This is the exception documented in the description for PrivateIpv4Addr.
In which scenarios can this happen? Private networks where both device and application server are in the same network? And every device is allocated a distinct private address?
There was a problem hiding this comment.
Yes, this scenario would be for private or test networks where the private address allocated to the device is unique (within that network).
So the private address is sufficient to identify the device in this case, but I think making public_address required is better because this information will indeed be required for the normal case. Unfortunately, OAS does not support making fields conditionally mandatory - they are either required or optional.
There was a problem hiding this comment.
If we consider the term routable as ip address that is routable in the internet, then the existing text itself seems to be fine. This means private addr (non-routable) and public addr (routable). With that, my understanding is as below:
- UE behind NAT with a private addr & want to identify using public ip addr -> use
PublicIPv4Addrobject - UE behind NAT with a private addr & want to identify using private ip addr-> use
PrivateIpv4Addrobject withpublic_addressandprivate_addressassigned with respective ip addrs. - UE in a private n/w with a private addr & want to identify using private ip addr itself -> use
PrivateIpv4Addrobject withpublic_addressandprivate_addressbeing the same private addr - UE is assigned a public addr (unusual case) & want to identify using public ip addr ->I thought we still be using the
PrivateIpv4Addrobject withpublic_addressandprivate_addressbeing the same public ip addr. This is one anomaly to the 'routable' term and as this is an unusual case, I tend to ignore it. (However, @eric-murray reply above 'Identify device by public IP address' indicates the use ofPublicIpv4Addrobject for this case -> not sure what should be the value ofpublic_portwould be in this case? This needs clarification)
From an AppServer implementation perspective, it uses the PublicIpv4Addr if populated. If not, it uses the PrivateIpv4Addr object to identify the device. Seems OK to me (pending the clarification requested above).
There was a problem hiding this comment.
UE is assigned a public addr (unusual case) & want to identify using public ip addr ->I thought we still be using the PrivateIpv4Addr object with public_address and private_address being the same public ip addr. This is one anomaly to the 'routable' term and as this is an unusual case, I tend to ignore it. (However, @eric-murray reply above 'Identify device by public IP address' indicates the use of PublicIpv4Addr object for this case -> not sure what should be the value of public_port would be in this case? This needs clarification)
My thought was that, if a public address is allocated directly to the device, then it will not have a private address at all, and so expecting the API caller to use the private_ipv4_addr field to identify the device is somewhat counterintuitive.
On your specific point about also specifying the public_port, for this scenario it is indeed not strictly required. Not because the device does not have a public source port, but because it has been allocated ALL public source ports. So any port could be specified. This is different to requiring the private_address, as such a device definitely does not have a private address (at least, not one that the mobile network would know about).
Given that public_port most definitely is required for the CGNAT case, I decided to make that parameter mandatory. Allowing the API caller not to specify it will cause more problems than it solves. Ultimately, there are three parameters that may be required for IPv4 address - public address, private address and public port. The question is what combination of options do we allow the API caller in specifying these parameters.
My expectation is that allocating public IPv4 addresses directly to the device is an entirely hypothetical scenario. If anyone is aware of commercial networks that still do this, I'd be interested in details of those.
There was a problem hiding this comment.
My expectation is that allocating public IPv4 addresses directly to the device is an entirely hypothetical scenario. If anyone is aware of commercial networks that still do this, I'd be interested in details of those.
I agree. We have captured the use case and thought out options here anyways. If this do not suffice, a new issue shall be created at that point and discussed. We do not want to overcomplicate now.
|
When we talk about UE IP address, 'private' or 'public' sometimes are confusing. First of all, 3GPP NEF AsSessionWithQos API accepts UE IP address assigned by 3GPP Core Network, it may be private or public, depends on NAT is deployed or not. The Application Server communicates with the UE can observe the UE IP address and port from an IP connection (e.g., a TCP connection). The observed UE IP address shall be public (routable). When there is not NAT, the assigned IP address and the observed IP address will be the same, and both of them are public. We suggest using the terms as below inside UE ID:
|
|
@emil-cheung Either way, it would have been useful to have that discussion within Issue #34 (open since August 5th 2022) rather than waiting until the PR is submitted. To me, the definition of "private" address is clear. It is an address from the ranges defined within IETF RFC 1918 "Address Allocation for Private Internets". So if the API caller has an address for the device that is from within those ranges, then they are looking to identify the device using the The advantage of having separate fields is that is reduces the number of parameters that the API caller needs to provide. However, I accept that giving the API caller choices can also be confusing. It would be good to have the opinion of those developers that might use this API. If we cannot agree on whether that choice should be "public" / "private" or "device assigned" / "device observed", then my immediate thought is simply to mandate the specification of all three parameters when devices are to be identified by IPv4 address. |
|
There is a discussion paper from @emil-cheung for the topic, currently in #127. Let's have the discussion tomorrow in our regular call. |
|
I think the discussion here is getting too complicated for a PR, so I'm closing this one and moving the discussion back to Issue #34. I have made an alternative proposal there. Once we have agreement in the issue, I will open a new PR - hopefully for approval and not as an invitation to re-open the discussion. |
