Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Uri-Path and Uri-Query of Server URI #230

Closed
kFYatek opened this issue Oct 9, 2017 · 5 comments
Closed

Uri-Path and Uri-Query of Server URI #230

kFYatek opened this issue Oct 9, 2017 · 5 comments
Assignees
@hannestschofenig

Comments

@kFYatek
Copy link

kFYatek commented Oct 9, 2017

Up until the second-to-last pre-1.0 draft, the LwM2M Server URI Resource in Section E.1 (LwM2M Object: LwM2M Security) read:

Uniquely identifies the LwM2M Server or LwM2M Bootstrap-Server, and is in the form:
"coaps://host:port", where host is an IP address or FQDN, and port is the UDP port of the Server.

However, it has been changed in 2017-0051R02-CR_security_object_bugfix_uri_format, and in all current versions, including the 1.0 and 1.0.1 approved versions, it reads:

Uniquely identifies the LwM2M Server or LwM2M Bootstrap-Server. The format of the CoAP URI is defined in Section 6 of RFC 7252.

Allowing all URIs that are valid as per RFC suggests that things like paths and query-strings are now allowed, so that e.g. coaps://example.com:1234/some/crazy/path?and=more&craziness now seems a valid LwM2M Server URI.

However, other parts of the spec do not seem to be prepared for such URIs; for example, section 8.2.4 mentions that Register shall be sent on the "/rd" URI and also that "The LwM2M Server MUST return a location under the /rd path segment" in Location-Path Options. It might be interpreted as requiring an absolute "/rd" path, essentially discarding any Uri-Path present in the Server URI.

There are more unresolved questions if the configured Server URI includes a query string. Shall these values be reproduced when sending Register or Bootstrap-Request? What if the configured URI already contains some query-string arguments that are meaningful for LwM2M, such as ep? Also, what about Update?

All in all:

  • Is it legal for LwM2M Server URI to contain a non-empty path segment, e.g. coaps://example.com:1234/some/path?
    • If so, what are the semantics?
      • Shall it precede the /rd path of a Register URI or /bs path of a Bootstrap Request URI?
      • Or shall it be ignored, with absolute /rd and /bs paths always used?
    • If it is allowed and meaningful, shall the Location-Path returned in response to Register contain an absolute path or a path relative to the Server URI?
  • Is it legal for LwM2M Server URI to contain a query, e.g. coaps://example.com:1234?some=query?
    • If so, what are the semantics?
      • Shall it be included in Register or Bootstrap Request URIs?
      • Or shall it be ignored?
      • Shall it also be included in Update URIs? (note that Update URI is dynamically built when performing the Register operation)
    • If it is allowed and meaningful, what happens if it includes options meaningful for LwM2M messages? For example what happens when the Server URI is coaps://example.com:1234?ep=iamcrazy? What will be the Register URI?
      • Shall it replace the ep attribute with Endpoint Client Name?
      • Shall it include another ep attribute? In what order?
@kFYatek kFYatek mentioned this issue Nov 3, 2017
Closed
@kFYatek
Copy link
Author

kFYatek commented Nov 3, 2017

Another interpretation that didn't occur to me while originally writing this ticket is that the Server URI written to the data model should actually include the /rd or /bs path.

So another question is: if Uri-Path in the Server URI resource is allowed and meaningful

  • should the path on which the client sends the Register request, be "{Uri-Path from the Server URI}/rd", or
  • should it be just "{Uri-Path from the Server URI}", and the /rd segment is supposed to be included in the value of the resource?

@kFYatek
Copy link
Author

kFYatek commented Nov 3, 2017 •
edited
Loading

Also, just noting that on-site input from @hannestschofenig during the meeting of the Working Group with TestFest Warsaw participants on Wednesday seemed to suggest that:

  • Both Uri-Path and Uri-Query is allowed
  • /rd or /bs shall be appended to the Uri-Path present in the Server URI resource
  • Uri-Query parameters as required by the Register operation shall be appended to those present in the Server URI resource; if there are query key duplicates (e.g. the Server URI contains ep=... query), both values shall be passed in the resulting URI

As for me, I think this would be a perfectly suitable conclusion.

krwc pushed a commit to AVSystem/Anjay that referenced this issue Nov 20, 2017
Anjay 1.5.0
14fda85 
Features:
- Extracted Firmware Update logic to a separate module so that the end user
  have to implement device-specific firmware updating logic only
- Implemented API for firmware update resumption
- Implemented stub of the portfolio object (in demo client) required for the
  OMA TestFest 2017
- Added support for DTLS session resumption as well as register-after-reconnect
  semantics
- Added object versioning support
- Added support for LwM2M Server URIs with Uri-Path and Uri-Query

Bugfixes:
- Fixed travis builds on macOS
- Fixed a few misleading statements in the documentation
- Fixed anjay_codegen.py handling of Multiple Instance Resources
- Fixed Content-Format for responses on Bootstrap Discover request
- Fixed Write (replace) on Device object instance in demo client

Improvements:
- Added more tests covering OMA TestFest 2017 test cases
- Allowed configuring Security/Server IIDs from command line in demo
- Allowed Bootstrap Delete on "/"
- Added support for re-bootstrapping after failed registrations
- Added anjay_server/security_object_is_modified simiar to
  anjay_attr_storage_is_modified
- Updated porting guide
- Replaced Internal Server Error responses with more specific error
  codes in a few places

Other:
- Relaxed validator of Update location path, due to specification being
  unclear (see: OpenMobileAlliance/OMA_LwM2M_for_Developers#230)
@hannestschofenig hannestschofenig self-assigned this Nov 20, 2017
@hannestschofenig
Copy link

From a related issue:

  • OMA-TS-LightweightM2M-V1_0_1-20170704-A
  • section: E.1

Allow to include uri-path and any uri-query in a resource of LwM2M server URI (/0/0/0).
This will enable passing extra information (like tenancy) to LwM2M server.

For example:
coaps://example.com:5684/my-creazy-rd?parameter=value
then client registers:
POST coaps://example.com:5684/my-creazy-rd?parameter=value&ep=device0123

@hannestschofenig
Copy link

For v1.1 we have to clarify the security processing that relates to the comparison between the content of a certificate (such as the string contained in the CN field of a cert) with the LwM2M Server URI resource value. A dedicated resource carrying the Server Name Indication (SNI) has been defined already.

@hannestschofenig
Copy link

If this issue is still valid, please re-issue it against the LwM2M v1.1 release.

@versatildefuy versatildefuy mentioned this issue Oct 18, 2019
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hannestschofenig hannestschofenig

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hannestschofenig @kFYatek