[Tsvwg] Secdir review of draft-ietf-tsvwg-rsvp-user-error-spec-06

["Stephen Hanna" <[e-mail]>]

I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG.  These comments were written primarily for the benefit of the  
security area directors.  Document editors and others should treat  
these comments just like any other comments.

I should preface this security review by stating that I am not an
expert in RSVP. Please excuse any misunderstandings on that front.
And please excuse the lateness of my comments.

This document defines a standard for user-defined errors in RSVP.
It clearly defines the format and semantics for such errors as well
as the procedures to be followed in sending and processing the errors.
Backward compatibility is adequately considered.

The Security Considerations section of this document seems to
adequately address most of the security implications of this
specification. The only security-related suggestion that I have
regarding the document is that I think it might be good to add text
to section 4.2, warning recipients to carefully examine a received
USER_ERROR_SPEC object for malformed data or otherwise dangerous
before processing it. Otherwise, buffer overruns or injection
problems could arise. Here's a sample paragraph:

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.

While this warning will probably seem obvious to security-aware
readers, some readers may be naive about security issues so it's
good to include this sort of warning. If you agree that control
characters should not be included in the Error Description, you
might want to include a requirement that senders not include such
characters in the string. However, recipients cannot assume that
the sender will do so. It seems better to have the recipient remove
such characters from the string than for them to regard the message
as malformed.

I also noticed two typographical errors in the specification:

In section 3, "Criticial" should be "Critical".
In section 4.2, "display of logging" should be "display or logging".

As I stated above, the specification seems to be good overall.

Thanks,

Steve