User-Defined Errors for RSVP
Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 07 and is now closed.
( Ron Bonica ) Yes
( Chris Newman ) (was No Objection, No Record, Discuss) Yes
Comment (2008-06-26 for -08)
For AUTH48: The new text has a number of typos, like "strngs" and "Descriprion".
( David Ward ) Yes
( Magnus Westerlund ) Yes
Jari Arkko (was Discuss) No Objection
( Ross Callon ) No Objection
( Lisa Dusseault ) No Objection
( Lars Eggert ) No Objection
( Pasi Eronen ) No Objection
Comment (2008-05-05 for -)
Based on Stephen Hanna's SecDir review: especially since RSVP packets don't usually contain ASCII strings, it might be a good idea to say in security considerations that the received string must be processed carefully (as it could contain e.g. control characters, printf format strings, SQL injection, or whatever). Stephen's suggested text: Like any other data received from a partially trusted party, the recipient MUST carefully check the USER_ERROR_SPEC object and its contents to make sure that it does not contain any malformed or illegal values and will not cause any buffer overruns or other processing errors that could cause reliability or security problems. The Error Description should be examined especially carefully if it is to be logged or displayed since it may eventually be processed by other code with poor error handling. Any control characters (bytes with values 0-31 and 127 decimal) or non-ASCII characters (128-255 decimal) MUST be removed. Other characters may need to be removed from the string, depending on the logging system in use and the range of characters that it can accept. If the logging or display system has escaping or another post-processing step that could give special meaning to the characters in the string, protection against injection attacks SHOULD be included in the RSVP code. Typos: In section 3, "Criticial" should be "Critical". In section 4.2, "display of logging" should be "display or logging".