Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

From: "Mark Brown (REDMOND)" <[email-masked]>
Date: Tue, 13 Feb 2001 18:38:13 -0800

So sorry -- I missed those changes when the -06 version came out.

Shortening my suggested addition seems like a good idea.

But the intent of my suggestion was to set a clear requirement for
LDUP's ability to provide interoperability. That way, as other LDUP
drafts progress, we'll be able to tell if they are meeting the goal
set in the requirements.

Since we are doing this work in the IETF, interoperability should be
one of the primary concerns of the work.

But the proposed text

:   Interoperability of replicas between directory servers may be
limited
:   by servers that implement semantics that go beyond what the LDAP
:   access protocol defines.  Examples (not an exhaustive list) of such
:   semantics include: (1) replication among directory servers with
:   different access control systems/semantics may compromise directory
:   security, and (2) replication among directory servers with different
:   application trigger semantics may compromise directory data
:   integrity.

does not set a clear requirement for LDUP's ability to provide
interoperability. It says that when we are done designing LDUP, it is
OK that certain directory servers will not be able to replicate. It
does not say that for the LDUP design to be considered a viable IETF
standard, it is necessary that there is some pair of directory
servers (not from the same code base) that LDUP enables to replicate.

Of course, we don't want to state such a goal in terms like "LDUP will
enable OpenLDAP and the Siemens DS to replicate," we want to state the
goal in terms of the functional characteristics of a pair of systems
that
are able to replicate. That's what my suggested text tried to do.

How about this:

: The goal of LDUP is to support replication between directory servers
: that each implements a passive store fully described by its LDAP
interface.
: "Passive store" means that the servers are limited to storing entries
that
: come in via LDAP and retrieving those identical entries later in
response
: to LDAP requests. The entire semantics of such a store is defined by
its
: LDAP interface. Any restrictions on what the server can store must be
: expressed in the server's schema, and any restrictions on the access
that
: clients have to the store must be expressed in terms of a standardized
: LDAP access control scheme.
:
: LDUP is not required to support replication between directory
: servers that each implements an active store extending LDAP
: semantics with non-standard access control rules or with triggers.
: Examples of triggers include password length/complexity policies and
: automatic storage of secure password hashes instead of passwords.

--mark

-----Original Message-----
From: Richard V Huber [mailto:[email-masked]]
Sent: Tuesday, February 06, 2001 12:52 PM
To: [email-masked]; [email-masked]; Mark Brown (REDMOND)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

We addressed these issues in version -06, though we cut down the text.

Here is the summary that was included when I sent version -06 to the
list.  I haven't seen any comments on it since it was posted.

: Internet Drafts Editor -
: 
: Please publish the draft below as draft-ietf-ldup-replica-req-06.txt
: It replaces the -05 draft from November.
: 
: LDUP Mailing list -
: 
: The attached version of the draft incorporates changes to address the
: comments from San Diego.  We trimmed Mark's proposed changes since we
: were concerned that they went into too much detail that wasn't really
: LDUP related.
: 
: Our specific changes are:
: 
: Insert the following as the last paragraph in Section 3:
: 
:   Interoperability of replicas between directory servers may be
limited
:   by servers that implement semantics that go beyond what the LDAP
:   access protocol defines.  Examples (not an exhaustive list) of such
:   semantics include: (1) replication among directory servers with
:   different access control systems/semantics may compromise directory
:   security, and (2) replication among directory servers with different
:   application trigger semantics may compromise directory data
:   integrity.
: 
: Add the following at the end of the Security Considerations Section:
: 
:   As noted in Section 3, security may be impacted when replicating
:   among servers that implement non-standard extensions to basic LDAP
:   semantics.  Access control is one common case which affects
security;
:   work to address this issue is documented in RFC 2820 [RFC2820].
: 
: Add the new reference to the References:
: 
:   [RFC2820]  E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access
:   Control Requirements for LDAP", RFC 2820, May 2000.
: 
: Change the draft number and the publication and expiration dates.
: 
: As always, please send comments to the list.

Rick Huber

--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
: Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
: Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D
: Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ
: From: "Mark Brown (REDMOND)" <[email-masked]>
: To: "John Strassner" <[email-masked]>, <[email-masked]>
: Cc: "Chris Apple" <[email-masked]>,
:         =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
: Sender: [email-masked]
: 
: The LDAPv3 Directory Replication Requirements I-D document does
: not address the interoperability limits issue that we discussed
: in December-January.
: 
: I append the most recent message on the topic.
: 
: --mark
: 
: -----Original Message-----
: From: Mark Brown (REDMOND)
: Sent: Thursday, January 11, 2001 7:41 PM
: To: Ellen Stokes; Kurt D. Zeilenga
: Cc: [email-masked]
: Subject: RE: interoperability limits: proposed addition to
: draft-ietf-ldup-replica-req-05.txt
: 
: Oops, I left off the examples. Let's try again:
: 
: I suggest inserting the following material right after
: the first paragraph of Section 3 ("The Models") of the
: requirements draft (just before the sentence "There are five
: data consistency models.")
: 
: --mark
: 
: * * * * *
: 
: The objective is limited to replication between directory servers
: that implement a passive store fully described by its LDAP
: interface. "Passive store" means that the servers are limited to
: storing entries that come in via LDAP and retrieving those entries
: later in response to LDAP requests. The entire semantics of
: the passive store is defined by its LDAP interface. Any
: restrictions on what the server can store must be
: expressed in the server's schema, and any restrictions on the
: access that clients have to the store must be expressed in terms
: of a standardized LDAP access control scheme. This is in
: contrast to an "active store" that implements triggers
: or other rules that extend the semantics of entries beyond
: what's implied by LDAP. Replication between such active
: stores should be specified in extensions to LDUP.
: 
: Here are some examples of ways in which directory servers
: implement semantics that go beyond what the LDAP access
: protocol defines:
: 
: * Access control. LDAP does not currently define an access
:   control scheme. (The ldapext WG is working to extend LDAP
:   with an access control scheme.) Most directory servers
:   implement an access control scheme.
: 
:   Replication between directory servers with different
:   access control schemes would compromise directory security,
:   so such replication is not supported by LDUP.
: 
: * Password policy. Some directory servers restrict changes
:   to password attributes, requiring that the new password
:   value conform to a specific security policy (e.g. the value
:   is sufficiently long and complex.) Doing so reduces the
:   security risk associated with passwords that are easy to
:   attack.
: 
:   Replication between directory servers with different
:   password policies (e.g. one server implements a password
:   policy and a second server implements no policy) would
:   compromise directory security, so such replication is not
:   supported by LDUP.
: 
: * Password hashing. Some directory servers don't store a user's
:   password directly, but instead store one or more secure
:   hashes of the password. Doing so makes it less likely that
:   anyone (even an administrator) can discover the password.
: 
:   Replication between a directory server that stores passwords
:   and a directory server that stores only hashes will compromise
:   directory integrity, causing authentications to fail
:   unexpectedly, so such replication is not supported by LDUP.
: 
: * * * * *
: 
: -----Original Message-----
: From: Mark Brown (REDMOND) 
: Sent: Thursday, January 11, 2001 3:10 PM
: To: Ellen Stokes; 'Kurt D. Zeilenga'
: Cc: [email-masked]
: Subject: RE: interoperability limits: proposed addition to
: draft-ietf-ldup-replica-req-05.txt
: 
: 
: We appear to be in total agreement.
: 
: So I suggest inserting the following paragraph right after
: the first paragraph of Section 3 ("The Models") of the
: requirements draft (just before the sentence "There are five
: data consistency models.")
: 
: --mark
: 
: * * * * *
: 
: The objective is limited to replication between directory servers
: that implement a passive store fully described by its LDAP
: interface. "Passive store" means that the servers are limited to
: storing entries that come in via LDAP and retrieving those entries
: later in response to LDAP requests. The entire semantics of
: the passive store is defined by its LDAP interface. Any
: restrictions on what the server can store must be
: expressed in the server's schema, and any restrictions on the
: access that clients have to the store must be expressed in terms
: of a standardized LDAP access control scheme. This is in
: contrast to an "active store" that implements triggers
: or other rules that extend the semantics of entries beyond
: what's implied by LDAP. Replication between such active
: stores should be specified in extensions to LDUP.
: 
: * * * * *
: 
: --mark
: 
: -----Original Message-----
: From: Kurt D. Zeilenga [mailto:[email-masked]]
: Sent: Tuesday, January 09, 2001 4:54 PM
: To: Mark Brown (REDMOND)
: Cc: Ellen Stokes; [email-masked]
: Subject: RE: interoperability limits: proposed addition to
: draft-ietf-ldup-replica-req-05.txt
: 
: 
: Mark,
: 
: Replication in the face of triggers or any other LDAP extension
: should be specified in extensions to the LDUP.
: 
: LDUP should assume 'passive' servers as this, I believe, is the
: LDAP/X.500 data model.  That is, servers should not muck with
: user data.
: 
: Kurt

---

From: "Ryan Moats" <[email-masked]>
Date: Fri, 16 Feb 2001 14:40:28 -0600

See <rm>...</rm> below... Ryan

-----Original Message-----
From: Mark Brown (REDMOND) [mailto:[email-masked]]
Sent: Tuesday, February 13, 2001 8:38 PM
To: Richard V Huber; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];

<rm>Good</rm>

<rm>I personally am willing to do the following text adjustment,
(the other authors still get to comment)...

  ... A standard mechanism for directory replication in a
  multi-vendor environment is critical to the continued
  success of LDAP in the market place. This document sets
  out the requirements for replication between multiple
  standard-conformant LDAP servers. ...
  ^^^^^^^^^^^^^^^^^^^ <- new text

Beyond this, I disagree that LDUP requirements need to be stated
to cover items that don't have an LDAP standard yet.  Any new LDAP
standard should cover the impact of replication on that standard,
not the other way around.</rm>

But the proposed text

How about this:

--mark

-----Original Message-----
From: Richard V Huber [mailto:[email-masked]]
Sent: Tuesday, February 06, 2001 12:52 PM
To: [email-masked]; [email-masked]; Mark Brown (REDMOND)
Cc: [email-masked]; [email-masked]; [email-masked];

Rick Huber

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 20 Feb 2001 14:43:42 +1100

Folks,

Some comments on draft-ietf-ldup-replica-req-06.txt .

> 2  Terminology

> Replica - A collection of entries in the DIT, defined by a naming
> context, and including all or some of the depending entries contained
> therein, which divides directory data into a discrete partition whose
> propagation behavior may be independently configured from other
> partitions.  Replicas may overlap or be nested.

The use of "discrete" seems to be at odds with "overlap" and "nested".

The term "replica" is inconsistently used. Sometimes it is used to mean
a portion of the DIT, i.e. roughly synonymous with area of replication,
while at other times it refers to one of the servers holding a copy of a
particular area of replication.

> Replica-Ring - The servers that hold a particular replica.  A server
> may be part of several replica-rings.

Here "replica" means a particular area of replication whereas elsewhere
the servers in the replica-ring are referred to as separate replicas.

I suggest using area of replication to refer to the portion of the DIT
and defining "replica" to mean one instance or copy of that area of
replication held in a directory server.

> Replication Initiation Conflict - In multi-master replication, a
> Replication Initiation Conflict is a situation where two masters want
> to update the same replica at the same time.

It isn't just master replicas that can have such a conflict. Read-only
replicas can be forwarding updates from a master upstream. A Replication
Initiation Conflict is a situation where two replicas want to initiate
replication sessions with a third replica at the same time.

> 3  The Models

> Consistency models 1, 2 and 3 involve the use of prearranged
> replication agreements among servers.  The added complexity of the
> distributed 2-phase commit required for Model 1 is significant;
> therefor, model 1 will not be considered at this time.  Models 4 and 5
> involve unregistered replicas that "pull" updates from another
> directory server without that server's knowledge.  These models violate
> a directory's security policies.

It seems to me that any of the five models could violate, or preserve,
a directory's security policies. It all depends on whether the consumer
of the replicated data receives and honours the security information.

> M3.  A value shared between replicas in a replica ring must eventually
> converge to the same value on all of its constituent replicas.

A shared value is almost by definition the same everywhere, otherwise in
what sense can it be said to be shared ? This requirement is really trying
to say that an attribute in an entry must eventually converge to the same
set of values in every replica holding that entry, and is just duplicating
MM6 anyway.

> P2.  The supplier MUST track updates sent to the consumer and not
> resend already acknowledged ones, even in the event of recovery from a
> failed replica cycle.

Not resending acknowledged updates to a consumer requires something like
two-phase commit for the replication session between the supplier and
consumer, which isn't part of the current protocol proposal, and doesn't
need to be since URP absorbs any duplicates. Also, with the Update Vector,
it is the consumer that keeps track of the updates that have been received
rather than the supplier keeping track of the updates that have been sent.

I imagine there are two things this requirement might really be trying to
say:

1) The replication architecture SHOULD avoid sending to a consumer an
update that the consumer has already seen.

2) An update received by a consumer more than once MUST NOT produce a
different outcome than if the update were received exactly once.

> P7.  The protocol SHOULD NOT preclude support of Transactional
> Consistency (model 1).

I think this should be more general than just the protocol.
The replication architecture SHOULD NOT preclude ...

> AM6.  Access control information (ACI) associated with sensitive data
> MUST be deleted after or simultaneously with the deletion of the
> sensitive data.  Likewise, during Adds, ACI MUST be added first or
> simultaneously with the addition of that data.

This is a requirement on LDAP users rather than the replication
architecture.
The requirement for replication would be that where there are updates
to sensitive data and the ACIs controlling access to those data, the updates
SHOULD/MUST be applied at other replicas in the same order.

> A.6. Consumer Initiated Replication
>
> Again a single mastered replication topology, but the replica initiates
                                                        ^^^^^^^ slave
> the replication exchange rather than the master. An example of this is
> a replica that resides on a laptop computer that may run disconnected
> for a period of time.

> A.10.      Enterprise Directory Replication Mesh
>
> A Corporation builds a mesh of directory servers within the enterprise
> utilizing LDAP servers from various vendors. Five servers are holding
> the same area of replication. The predetermined replication
> agreement(s) for the enterprise mesh are under a single management, and
> the security domain allows a single predetermined replication agreement
> to manage the 5 servers replication.
>
> The requirements that follow from this scenario are:
> . Predefined replication agreements that manage more than a single area
>   of replication that is held on numerous servers.

The preceding paragraph suggests there is exactly one area of replication.

> B.5.3. Locking Based on Atomicity of ModifyRequest
>
> There is an entry with distinguished name DN that contains attributes
> X, Y, and Z.  The value of X is 1.  On replica A, a ModifyRequest is
> processed which includes modifications to change that value of X from 1
> to 0 and to set the value of Y to "USER1".  At the same time, replica B
> process a ModifyRequest which includes modifications to change the
  ^^^^^^^ processes

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 20 Feb 2001 16:21:51 -0800

>of the replicated data receives and honours the security information.

... in the same way.  That is, you can have two servers implementing
the same Standard Track ACM but still have significant differences
in how each applies the same access control information.  One doesn't
have to go far to find a SHOULD or MAY in the TS which impacts
access control processing.

>The replication architecture SHOULD NOT preclude ...

Yes, please.

>SHOULD/MUST be applied at other replicas in the same order.

I concur.

---

From: Richard Huber <[email-masked]>
Date: Thu, 22 Feb 2001 11:11:23 -0500

Comments are inserted in the text below; look for the lines that are not
quoted.  The comments represent consensus of the authors.

Rick Huber

> The use of "discrete" seems to be at odds with "overlap" and "nested".

Agreed.  Proposed new text is given as part of our response to the next comment.

> particular area of replication.

Our intent was the latter (a copy held on one of the servers).  We will take a
pass over the document to fix this, but if you have pointers to places where the
term is not used in this sense they would be helpful.

As a result of addressing the first two comments, we propose to reword the
definitions of "area of replication: and "replica" as follows:

   Replica - A instance of an area of replication on a server

   Area of replication - A whole or portion of a Directory Information
   Tree (DIT) that makes up a distinct unit of data to be replicated.
   An area of replication is defined by a naming context and includes
   all or some of the depending entries contained therein.  It divides
   directory data into partitions whose propagation behavior may be
   independently configured from other partitions.  Areas of
   replication may overlap or be nested.  Areas of replication may also
   be known as "units of replication".

> replication held in a directory server.

Agreed - see new definitions above.

> replication sessions with a third replica at the same time.

OK.  We'll remove references to masters  in the definition.

> of the replicated data receives and honours the security information.

We feel we have already addressed this with changes to sections 3 and 5 going
from draft 05 to 06.  We don't feel any additional changes are needed.

> set of values in every replica holding that entry, and is just duplicating

It looks like we agree on what the requirement is saying.  We don't feel it is
duplicating MM6 since MM6 also addresses particular concerns that can arise in
multi-master.

> different outcome than if the update were received exactly once.

It is trying to say both things.  We will replace P2 with Steven's two
requirements.

> The replication architecture SHOULD NOT preclude ...

Agreed.  We'll move it to the "General" section.

> SHOULD/MUST be applied at other replicas in the same order.

Agreed.

> > a replica that resides on a laptop computer that may run disconnected

Agreed.

> The preceding paragraph suggests there is exactly one area of replication.

The text is in Appendix A, which contains examples of use.  Examples are
typically specific versions of more general principles, so we don't see a
problem here.  The definition of "area of replication" as rewritten above makes
it clear that multiple areas of replication are supported.

> > process a ModifyRequest which includes modifications to change the

OK.

>
> Regards,
> Steven
>
>   ------------------------------------------------------------------------
>                   Name: winmail.dat
>    winmail.dat    Type: application/ms-tnef
>               Encoding: base64

---

From: Jim Willeke <[email-masked]>
Date: Thu, 22 Feb 2001 15:07:26 -0500

I do not understand the useage of the term "Replica-Ring"
A ring would imply there is some order of going from one to the next on 
the ring.
Would a "replica Group" not be more appropriate?
-jim

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 23 Feb 2001 12:00:49 +1100

Rick,

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Richard Huber
> Sent: Friday, 23 February 2001 3:11
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Comments on draft-ietf-ldup-replica-req-06.txt
>
>

> term is not used in this sense they would be helpful.

I found these places.

| Naming Context - Suffix of a sub-tree of entries held in a single
| server [X.500].  For replication, this is the vertex of a replica.
                                                            ^^^^^^^

| Replica-Ring - The servers that hold a particular replica.  A server
                                                    ^^^^^^^

| G5.  The LDAP replication standard SHOULD NOT limit the size of a
| replica.
  ^^^^^^^ maybe

| M8.  The replication agreements SHOULD accommodate multiple servers
| receiving the same replica under a single predefined agreement.
                     ^^^^^^^

> duplicating MM6 since MM6 also addresses particular concerns

Okay. Are you going to rephrase M3 though ?

> it clear that multiple areas of replication are supported.

The point I was making was that the first paragraph says "Five servers are
holding the SAME area of replication" while the requirement says
"agreements that manage MORE THAN A SINGLE area of replication", which
doesn't
"follow from this scenario". Is it one, or more than one ? A.10 needs to be
internally consistent.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Feb 2001 20:21:18 -0800

I find the introduction of LDUP specific terminology quite
confusing due to redefinition of many existing LDAP/X.500
terms.  I would very much like to see existing LDAP/X.500
terminology where ever possible.  In particular, much of the
terminology defined in X.525 is directly applicable.  If
new terms are needed, that's fine... but please don't redefine
existing terms.

Kurt