Subject: RE: Attribute Name Length Bounds

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 17 Jul 2003 13:40:49 -0600

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" <[email-masked]> 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 case is already 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"

---

From: Ryan Moats <[email-masked]>
Date: Thu, 17 Jul 2003 15:08:03 -0500

On Thu, Jul 17, 2003 at 01:40:49PM -0600, Jim Sermersheim wrote:
| 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].

Speaking as a schema designer, this doesn't help me because it doesn't
address the fundamental issue of ensuring that the proposed schema works
on an implementation.  I don't see how a schema designer can have any
confidence that a schema will work unless there is a mandatory minimum.

Ryan Moats