Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt

["Sukanta Ganguly" <SGANGULY@novell.com>]

Hi,
  You folks state that IP fragmentation is not a issue with CLDAP. Where would one have an implementation wherein the reliability that we expect from TCP could be taken care of? I guess I am having a difficult time understanding as to where would the UDP packet retransmissions in case of losses would be handled? There are many more to the related issue like packet re-ordering etc.
  If we do not have this in the Network layer (i.e. layer 3) then either the application needs to handle them, which would be another overhead that the LDAP server needs to handle/manage or the application clearly would not care for it. I can't imagine the case where in LDAP applications are ignorant to the fact that some of the data they send and receive may not actually come to them. LDAP which is a application level protocol is very order sensitive and users would be really pissed if they do not get the data which they have stored within the speicific Directory (and I am not even mentioning the uncertiaties due to the lossely consistent replication models).
  I think there needs to be serious effort in addressing them as the CLDAP server implementors would have a great deal of heart burn implementing them.
  

SG

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 06/05/00 10:29AM >>>
At 05:41 PM 6/5/00 +0200, Leif Johansson wrote:
>> Section 2:
>> > Encoded packets must be small enough to fit inside a datagram
>> > no bigger than the size of the MTU of the transport mechanism."
>> 
>> Why the MUST?  Would the protocol not work if the MTU was
>> exceeded?  I would think SHOULD would sufficient... with a
>> statement as to why (ip fragmentation?).
>
>Handling fragmentation would (imho) make the protocol too complicated
>to bother with as an alternative to tcp.

CLDAP is not complicated by IP fragmentation.  IP implementations
must support IP fragmentations and applications protocols should
care less of fragmentation occurs or not.  There should be no
interoperability issue.

I concur that fragmentation is expensive, but this fact alone
is insufficient justification for the MUST.

The SHOULD would be sufficient, I suggest something on the
lines of:
  Implementations SHOULD avoid sending PDUs which require
  fragmentation at lower levels as reassembly is expensive.
  Implementations MAY use path MTU discovery or other means
  for determining an MTU restriction.  Implementations
  MUST be capable of accepting and generating PDU of size X.

The latter requirement necessary to ensure an implementation
can respond to a critical (simple) request.  Not sure what
value X should take.

>Do you know the reason why sasl is only specified for
>connection-oriented protocols? Would this be "fixable" by amending sasl or
>is there some "real" reason behind keeping sasl connection-oriented only.

SASL requires connection-oriented, reliable transport by design.
It cannot be easily amended to support connection-less, unreliable
transports.

>In anyway specifying IPSEC would seem to be the "right" thing to do.

Yes, and we'd need to define a secure authentication mechanism
for CLDAP.  I would suggest adding an authentication choice
external [4] which would use lower level credentials exchanged
at lower level to establish CLDAP session level authentication
(and authorization).  That is, it would work like SASL "External",
but be SASL-less.