Skip to main content

Last Call Review of draft-levine-rfb-
review-levine-rfb-secdir-lc-cain-2009-05-24-00

Request Review of draft-levine-rfb
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-05-12
Requested 2009-05-01
Authors Tristan Richardson , John R. Levine
I-D last updated 2009-05-24
Completed reviews Secdir Last Call review of -?? by Patrick Cain
Secdir Telechat review of -?? by Patrick Cain
Assignment Reviewer Patrick Cain
State Completed
Request Last Call review on draft-levine-rfb by Security Area Directorate Assigned
Completed 2009-05-24
review-levine-rfb-secdir-lc-cain-2009-05-24-00
Hi,

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 WG chairs should treat 
these comments just like any other last call comments.

This document defines a RFB ("remote framebuffer") protocol for remote 
access to graphical user interfaces.

The security considerations section adequately points out the lack of
security
in the protocol and suggests ways around this issue.

There are a few formatting issues (e.g., the references are not split
between normative and informative) that I expect the rfc editor review will
point out so I will not.

There seems to be lots of 'hidden implications' in this document, for
example there is a line that states "Other security types exist but are not
publicly documented." What happens when two of these non-public things
clash? Or if they are really used, maybe we should document them. :)
The IANA considerations asks for none, but then states that "IANA has
allocated port 5900 to the RFB protocol; the other port numbers have been
used informally and do not match IANA allocations." If only one port was
allocated (but has no reference) how can the 'other ports' not follow the
allocations? (There weren't any other allocations.)

Although it looks like this document is documenting a deployed protocol.
There seems to be a bunch of implementor data missing.

Pat Cain