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.

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

Classes of Error messages. #74

Closed
emanjon opened this issue Feb 21, 2021 · 7 comments
Closed

Classes of Error messages. #74

emanjon opened this issue Feb 21, 2021 · 7 comments

Comments

@emanjon
Copy link
Collaborator

@emanjon emanjon commented Feb 21, 2021

At the last interim there was a suggestion to standardize classes of error messages and to ask the IoT groups in IETF about what classes of error messages that should be standardized.

  • The error message should then be augmented with a error message class. int? array of int?
  • Shoudl the optional text string remain. That cannot be used for any automation. But might be useful for loggging for later reading by a human. The initial classes or error message might not provide much info, e.g. "authentication error"
@gselander
Copy link
Collaborator

@gselander gselander commented Feb 21, 2021

@gselander
Copy link
Collaborator

@gselander gselander commented Mar 2, 2021

Proposal after discussion in Hackathon:

error = (
  ? C_x : bstr_identifier,
    DIAG_MSG : tstr,
    ERR_CODE : int / 2* int,
  ? SUITES_R : [ supported : 2* suite ] / suite,
)

Top-level ERR_CODEs:

(0. Success)

  1. Message field error (syntax error or incorrect protocol field of expected message)
  2. Selected cipher suite not supported (include SUITES_R in message)
  3. Credential/context error (error related to establish certificate/raw public key context for processing message, including certificate expired, revoked, unsupported, corrupt, unknown CA, or other issue in processing the credential)
  4. Decrypt error (a cryptographic operation failed, including being unable to correctly verify a signature or a MAC in the protocol message)
  5. Auxiliary data error (unsupported or missing auxiliary data)
  6. Access denied (credential valid but peer not allowed access)
  7. Internal error (error not related to the protocol or the peer)

Selected comments during Hackathon:

  • Relation to errors on other layer, e.g. CoAP errors or error in application.
    • EDHOC does not require CoAP so could have use for specified own errors.
    • Does "5. AD error" belong to EDHOC? Perhaps, auxiliary data provides means for security applications to reuse EDHOC and this would be a channel to send errors in those applications. [Not sure if this helps but, alternatively, errors could be encoded as auxiliary data, which may require an AD-field in the error message]
    • Does "6. Access denied" belong to EDHOC? Perhaps, it provides a suitable error to the requirement "Verify that the identity of the Responder is an allowed identity for this connection"

Further comments are welcome. Happy to make the list shorter if possible.

@gselander
Copy link
Collaborator

@gselander gselander commented Mar 2, 2021

Other thoughts:

  • We can put some of these error classes into an "x. unspecified error" bucket if we don't think they are not meaningful to act upon individually.

  • We can define a class of errors "y. general error" and allow implementations to use class y for any error, including those properly belonging to some class above. This would allow implementations to only support some of the specified errors above, potentially listed in the applicability statement. (That would render the list of classes above just a RECOMMENDATION.)

gselander added a commit that referenced this issue Apr 6, 2021
@emanjon
Copy link
Collaborator Author

@emanjon emanjon commented Apr 21, 2021

Many OSs, shells, and programming languages (e.g. C) use 0 for success and everthing non-zero (negative or positive) is considered an error. HTTP and Coap use postive numbers only where 2. or 2xx is considered success.

I think we should probably follow one of these convensions instead of making a new one.

The specification should also probably define that everything else than whatever we decide for success is considered an error.

@emanjon
Copy link
Collaborator Author

@emanjon emanjon commented May 5, 2021

I made a PR #113 addressing all known issues regarding this.

@gselander
Copy link
Collaborator

@gselander gselander commented May 7, 2021

This is ready to merge unless there are any objections.

@emanjon
Copy link
Collaborator Author

@emanjon emanjon commented May 21, 2021

The PR has been discussed and merged. Closing

@emanjon emanjon closed this May 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants