|
I also see that we could just add "or exceed server limits" to the end of the phrase "or the encoding structures or lengths of data fields are found to be incorrect" in the first paragraph. But I'm not sure...
This section talks about data that is either malformed or cannot be/is not recognized, so it seems like a good fit. It splits the problems into two classes (those that cause the connection to terminate, and those that simply return protocolError).
Adding the change above causes a connection termination. The change Bob suggests allows one to differentiate between something that looks like an attack (say some size is 20gb), and something that simply exceeds a small limit, and act accordingly.
Which seems more correct to others (and do both seem incorrect to anyone)?
While I think this is a good fix to add, does it fix the problem? After reading http://www.openldap.org/lists/ietf-ldapbis/200306/msg00065.html the answer is "Yes". Then when I read http://www.openldap.org/lists/ietf-ldapbis/200306/msg00071.html, it seems to say "Not really".
Does requiring the server to return an error when it can't handle a too-big attribute name solve this particular problem? If not--and we still want to talk about mandatory minimums for schema names, we need to do it in the context of [Models].
As a side note, I also wonder if these two paragraphs belong in Section 4 rather than 4.1.1.
Jim
>>> "RL 'Bob' Morgan" <rlmorgan@washington.edu> 7/17/03 11:15:53 AM >>> On Wed, 16 Jul 2003, Jim Sermersheim wrote: > At this point it seems clear that it would be a good thing to make a > clarification to [Protocols]. That clarification would state something > like: all octets of a ber-encoded LDAP PDU are significant. No octets > may be ignored unless they are part of extended elements that are > themselves ignored. It seems to me that the point is to give implementors advice about what to do when any protocol elements exceed implementation-specific length boundaries. I agree with Ron that the significance of "all octets are significant" isn't necessarily clear ... I was going to recommend that this advice be added as another bullet in the "Implementation Guidelines" section (since it applies to both server and client, maybe adding a "general" 6.x section would be the clearest). But then I read again these paragraphs from section 4.1.1 of protocol-16: If the server receives a PDU from the client in which the LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot be parsed, the tag of the protocolOp is not recognized as a request, or the encoding structures or lengths of data fields are found to be incorrect, then the server MAY return the Notice of Disconnection described in section 4.4.1, with the resultCode set to protocolError, and MUST immediately close the connection. In other cases where the client or server cannot parse a PDU, it SHOULD abruptly close the connection where further communication (including providing notice) would be pernicious. Otherwise, server implementations MUST return an appropriate response to the request, with the resultCode set to protocolError. I would think that not being able to fit a PDU element into your implementation's data slots would be an instance of "cannot parse". If so, then this cas! e is alr eady covered by the above text (where we should still probably add something like: "including not being able to store a PDU element in implementation-specific data structure" to the above). Whether the above text is actually correct may be another question ... If PDU-element-too-big-to-fit is not an instance of "cannot parse", then I think adding advice in section 6 would be the right thing to do. - RL "Bob" |