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

From: "Sukanta Ganguly" <[email-masked]>
Date: Mon, 05 Jun 2000 11:53:35 -0600

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" <[email-masked]> 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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 05 Jun 2000 12:02:30 -0700

At 11:53 AM 6/5/00 -0600, Sukanta Ganguly wrote:
>Hi,
>  You folks state that IP fragmentation is not a issue with CLDAP.

It is an issue...  I argue that implementations should avoid
IP fragmentation but must be able to interoperate in the face
of IP fragmentation.

>Where would one have an implementation wherein the reliability
>that we expect from TCP could be taken care of?

Note that IP fragmentation occurs below TCP.  The IP deals with
the fragmentation/reassembly, not TCP.  TCP needs to be able to
retransmit lost whole IP datagrams.  It should, of course, avoid
IP fragmentation where possible.

Likewise, UDP doesn't see fragments.  It sees whole IP datagrams.
If the IP layer cannot reassemble, then the datagram is dropped
and UDP ignores it like it would any other dropped datagram.
CLDAP should avoid causing IP fragmentation and must deal with
lost, duplicated, and/or reordered of UDP datagrams.

>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.

The CLDAP specification must specify the behavior of implementations
in face of lost, duplicated, and/or reordered whole UDP datagrams
irregardless of whether this is to handled at or above
CLDAP.  The current spec needs work here... it's rev 0 afterall.

>  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.

Handling of such must be done by both peers, whether at, below, or
above the CLDAP layer.

> 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.

I can.  Data availability is not a constant.

>  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.

s/server/client and server/   It's a two way street.

I do concur that CLDAP specification is a significant undertaking.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 06 Jun 2000 16:41:55 +0200

> I'd rather make it
> 
> SEQUENCE {
>     controls SEQUENCE {
>          requestID INTEGER,
>          ...  -- note - "extensible" is a 97-ism
>     }
>     CHOICE {
>        [0] LDAPRequest
>        [1] LDAPResponse
>     }
> }
> if that's simpler.

Hmmm, and this is different from LDAPMessage how? I thought you wanted to 
compress sessions where multiple responses are returned by stuffing them
in one PDU. Is there a SEQUENCE missing from the above somewhere? Or are
you "only" looking at session management? In the latter case I also don't
see how this is based on 1789 which is _all_ about multiple PDUs (search-
results actually) in one datagram.

> 
> you mean give people rope enough to hang themselves in 15 different ways? :-)
> 

Absolutely :-) But seriously, some might actually learn not to. 

	Cheers Leif