Subject: [radext] Fragmentation draft(s)

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Mar 2013 10:00:30 -0400

This message is to correct misconceptions I heard at the RADEXT mike
yesterday.  They seem to be rooted in the confusion between what is
*allowed* and what is *required*.

  Peter's draft *requires* re-assembly at every intermediate node.

  Alejandro's draft *allows* re-assembly at every intermediate node.

  Peter's draft *forbids* existing proxies from using fragmentation.

  Alejandro's draft *allows* existing proxies to use fragmentation.

  To me, the more flexible approach is better on a number of fronts.
First, it works with existing systems, which is (for me) a hard
requirement.  Second, it allows systems to be *gradually* upgraded.

  The gradual upgrade path means that Alejandro's draft can be deployed
today, and fixed over time.  The "fork-lift ugrade" required by Peter's
draft means that everyone has to upgrade for anyone to see any benefit.

  The IETF has sufficient proof that fork-lift upgrades rarely work.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Mar 2013 10:07:11 -0400

Alan, I agree with you that we should support Alejandro's draft.
However, I think we're early enough in the deployment of RADSEC and
RADIUS over TCP that having a better approach for fragmenting over those
technologies is desirable.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Mar 2013 10:08:12 -0400

> technologies is desirable.

  Absolutely.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Wed, 13 Mar 2013 09:01:35 -0700 (Pacific Daylight Time)

> *allowed* and what is *required*.

Hi Alan,

I think my discussion with Sam was more in regards to flights of packets.

I hope there is no confusion left on this topic as I have gone out of my 
way to stress the differences on the list.  Last slide of my presentation 
spoke to this question.

>  The IETF has sufficient proof that fork-lift upgrades rarely work.

Another way to look at the situation from the perspective of only subset 
of systems which do not implement the specifications is that existing 
systems are seeing different information when Alex's approach is switched 
on.

Unless these proxy systems are expected to do little else than forward 
messages based on User-Name realm you are likely to cause breakage with 
unknowable consequences.

I have a preference for not working at all over breaking existing things 
especially when "things" are of sort authentication or authorization.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Mar 2013 13:32:36 -0400

> I think my discussion with Sam was more in regards to flights of packets.

  I was referring to Sams comments about fragility of the Alejandro
draft, and that reassembly was preferred.

> way to stress the differences on the list.  Last slide of my
> presentation spoke to this question.

  Yes.  It's why I mentioned the fork-lift upgrade.

> systems are seeing different information when Alex's approach is
> switched on.

  I'm not sure how to parse that sentence.

> messages based on User-Name realm you are likely to cause breakage with

  Vague predictions of disaster aren't helpful.

  There are already many proxies that do *not* re-write packet contents.
 Most of the proxies in Eduroam, for example.  That serves as proof it
*can* work without breakage.

  For servers which need to re-write packet contents, the answer is the
same as for your proposal: upgrade.  So this proposal is in some cases
better, but no worse than your proposal.

> especially when "things" are of sort authentication or authorization.

  Please describe *what* will break, and *how* it will break.  We've had
this conversation repeatedly.  Doom and gloom aren't good protocol
design.  Facts and evidence are.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Wed, 13 Mar 2013 11:23:52 -0700 (Pacific Daylight Time)

> draft, and that reassembly was preferred.

Yes, this was about movement of packets thru the system rather than 
compatibility.

> *can* work without breakage.

Changing contents is only a small half of the equation.  The other half is 
making decisions based upon the same content.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Mar 2013 14:38:28 -0400

Peter Deacon wrote:
> Changing contents is only a small half of the equation.  The other half
> is making decisions based upon the same content.

  Sure.  Which is why the draft says that User-Name is included in each
fragment.

  The requirements for fragmentation come from abfab (among others).
All of the known use-cases are for proxy federations, where User-Name is
used for proxying.

  If you have other use-cases, please explain.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Wed, 13 Mar 2013 12:02:49 -0700 (Pacific Daylight Time)

> All of the known use-cases are for proxy federations, where User-Name is

Hu? What requirements?

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Mar 2013 15:30:45 -0400

>> All of the known use-cases are for proxy federations, where User-Name is

  The use-cases were discussed on this list, on the abfab list, and in
the face to face meetings.  The requirements are to satisfy the use-cases.

  Why, exactly, are you unfamiliar with them?

>>   If you have other use-cases, please explain.

  Since you didn't respond, I can only assume you have no use-cases for
the solution you're proposing.  As such, it is a solution in search of a
problem, and isn't relevant to this working group.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Wed, 13 Mar 2013 23:45:09 -0700 (Pacific Daylight Time)

> the face to face meetings.  The requirements are to satisfy the use-cases.

I recall Alex indicating a desire to provide a generally applicable 
solution.  Is this still the case or is his draft intended only to address 
specific needs of specific groups?

If offered as a general solution I would assume there would be parity in 
consideration of possible implications to more than specific groups.

regards,
Peter

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 14 Mar 2013 14:41:47 +0100

El 14/03/13 07:45, Peter Deacon escribió:
> solution.  Is this still the case or is his draft intended only to 
> address specific needs of specific groups?

Hello Peter,

initially it was intented to be generic. However, after recent 
discussions (please, refer to Alan's mail 08/Mar/13), we come out with 
the conlusion that fragmentation does not make much sense out of sending 
authorization-related data, as it does not seem a good idea to interfere 
with authentication flows. Other flows like accounting are alraedy 
discussed in the draft.

That's why we are considering updating the draft's name.

Regards,
Alejandro

>
> If offered as a general solution I would assume there would be parity 
> in consideration of possible implications to more than specific groups.
>
> regards,
> Peter
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Mar 2013 10:06:04 -0400

> address specific needs of specific groups?

  Alejandro's comments apply here.

> consideration of possible implications to more than specific groups.

  What real-world problem is solved by *generalized* fragmentation
support?  Accounting?  CoA?  Disconnect?

  Please explain.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 14 Mar 2013 22:11:31 -0700 (Pacific Daylight Time)

> discussions (please, refer to Alan's mail 08/Mar/13), we come out with

Hi Alex,

Drilling down from the question of command code coverage do you intend 
this to be a generally applicable solution or something only to meet the 
needs of specific groups and specific technologies?

If it is only for specific technologies or groups I would just ask to try 
and clarify this point.

For example if I wanted to push a configuration file in an authorization 
message using one of these newfangled "long attributes" would your draft 
be something I could use to do that?

If it is to be generally applicable albeit with the limited command code 
coverage then I would assume there would be some parity in consideration 
of implications to the general audience rather than relying on inside 
operational knowledge of specific groups to reason about implications.

For example we have operators with production use of processing and proxy 
based on attributes other than User-Name.

> with authentication flows. Other flows like accounting are alraedy 

See this text from RFC 6158 section 3.1:

"In the case of RADIUS accounting, transporting large amounts of data 
would require a sequence of Accounting-Request packets.  This is a 
nontrivial change to RADIUS, since RADIUS accounting clients would need 
to be modified to split the attribute stream across multiple 
Accounting-Requests, and billing servers would need to be modified to 
reassemble and interpret the attribute stream."

draft-perez-radext-radius-fragmentation-05 section 3.4.1

"There is no need to fragment accounting packets.  While the accounting 
process can send large amounts of data, that data is typically composed of 
many small updates.  That is, there is no demonstrated need to send 
indivisible blocks of more than 4K of data. The need to send large amounts 
of data per user session often originates from the need for flow-based 
accounting.  In this use- case, the client may send accounting data for
many thousands of flows, where all those flows are tied to one user 
session.  The existing Acct-Multi-Session-Id attribute defined in 
[RFC2866] Section 5.11 has been proven to work here."

With regards to CoA (Section 3.4.2) this scheme is less than ideal due to 
additional round trips, lack of feedback, lack of ability to implement 
fallback mechanisms and lack of separation of admission from session 
management.  We have separate systems (Not RADIUS servers) managing 
aspects of dynamic authorization.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Thu, 14 Mar 2013 22:22:23 -0700 (Pacific Daylight Time)

> support?  Accounting?  CoA?  Disconnect?

What real-world problem do "long attributes" solve if you can't 
practically make use of them?

If I want to push a cert, subscriber configuration file or filter list I 
have nothing but hacks for options if any of these items exceed 4096 
bytes.

regards,
Peter

---

From: Gabriel López <[email-masked]>
Date: Fri, 15 Mar 2013 08:30:17 +0100

Hi,

El 15/03/13 06:11, Peter Deacon escribió:
> this to be a generally applicable solution or something only to meet
> the needs of specific groups and specific technologies?
>
> If it is only for specific technologies or groups I would just ask to
> try and clarify this point.
>
I'm really confused. There are three or four last emails where Alan and
Alex say it is for Authorization.
> For example if I wanted to push a configuration file in an
> authorization message using one of these newfangled "long attributes"
> would your draft be something I could use to do that?
I suppose you want to push configuration data, so yes
>
> If it is to be generally applicable albeit with the limited command
> code coverage then I would assume there would be some parity in
> consideration of implications to the general audience rather than
> relying on inside operational knowledge of specific groups to reason
> about implications.
>
> For example we have operators with production use of processing and
> proxy based on attributes other than User-Name.
>
>> the conlusion that fragmentation does not make much sense out of
>> sending authorization-related data, as it does not seem a good idea
>> to interfere with authentication flows. Other flows like accounting
>> are alraedy discussed in the draft.
>
> nontrivial change to RADIUS, since RADIUS accounting clients would
> need to be modified to split the attribute stream across multiple
> process can send large amounts of data, that data is typically
> composed of many small updates. That is, there is no demonstrated need
> to send indivisible blocks of more than 4K of data. The need to send
> large amounts of data per user session often originates from the need
> for flow-based accounting. In this use- case, the client may send
> accounting data for
> With regards to CoA (Section 3.4.2) this scheme is less than ideal due
> to additional round trips, lack of feedback, lack of ability to
> implement fallback mechanisms and lack of separation of admission from
> session management. We have separate systems (Not RADIUS servers)
> managing aspects of dynamic authorization.
>
> regards,
> Peter

-- 
----------------------------------------------------------------
Gabriel Lpez Milln
Departamento de Ingeniera de la Informacin y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Gabriel López <[email-masked]>
Date: Fri, 15 Mar 2013 08:31:56 +0100

> practically make use of them?
Do we have not mention before ABFAB?

regards, Gabi.
>
> If I want to push a cert, subscriber configuration file or filter list
> I have nothing but hacks for options if any of these items exceed 4096
> bytes.
>
> regards,
> Peter

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 15 Mar 2013 09:07:35 +0100

> the needs of specific groups and specific technologies?

It is intended for the exchange of authorization data. It does not mean 
that it is constrained to any particular group. Anyone could use it.

> would your draft be something I could use to do that?

Sure you could. I don't see anything precluding you to do that.

> proxy based on attributes other than User-Name.

Which attributes? Why is the Proxy assuming they are there? Does the NAS 
intentionally include them to allow proxying? Do they have other utility 
on the AS other than being used for proxying? Those are important 
questions.

> "There is no need to fragment accounting packets.  While the 
> accounting process can send large amounts of data, that data is 
> typically composed of many small updates.  That is, there is no 
> demonstrated need to send indivisible blocks of more than 4K of data. 
> The need to send large amounts of data per user session often 
> originates from the need for flow-based accounting.  In this use- 
> case, the client may send accounting data for

---

From: Alan DeKok <[email-masked]>
Date: Fri, 15 Mar 2013 10:14:11 -0400

> On Thu, 14 Mar 2013, Alan DeKok wrote:
...
> practically make use of them?

  I'll take that as you don't have an answer to my question.

> have nothing but hacks for options if any of these items exceed 4096 bytes.

  We could allow RADIUS over TCP to have 64K packets.  That would
involve minimal changes to existing systems.  It's not a "hack" by any
stretch of the imagination.

  Fragmentation is only required for (a) UDP, and (b) authorization.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Fri, 15 Mar 2013 08:08:46 -0700 (Pacific Daylight Time)

>  I'll take that as you don't have an answer to my question.

Any justification I make will be thrown back at me with workarounds.

If I want to send a CoA to change a configuration file or filter list I 
sent during authentication then I should use a workaround described in 
3.4.2 which require infrastructure changes and does NOT meet my needs.

If I want to send detailed accounting messages in an accounting flow then 
I should arbitrarily partition a single transaction and come up with some 
unknown mechanism to understand if the full message has been received.

If I want to send certificates during an access request then I should use 
a URL.

I still don't understand why SAML can't be compressed, packed or 
referenced externally.  It might be an operational headache but it can be 
done.  For me it is not about what can be done it is about what is the 
most effective solution.  I don't want a series of workarounds I want one 
solution.

We have a new concept for long attributes allowing vendors to send large 
blocks of data in the command code of their choosing but there is no 
serious way to utilize this facility without running into the packet 
limit.

> stretch of the imagination.

And you could use Diameter.  Its not a "hack" by any stretch of the 
imagination.  I suspect you'll find more client vendors currently 
supporting Diameter than RADIUS over TCP.

>From Alex's presentation even ABFAB has requirements for sending data 
prior to authentication.

"Satisfy ABFAB requirements on supporting chunked data transfer prior to 
the authentication flow"

regards,
Peter

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 15 Mar 2013 17:32:22 +0100

El 15/03/13 16:08, Peter Deacon escribió:
> If I want to send a CoA to change a configuration file or filter list 
> I sent during authentication then I should use a workaround described 
> in 3.4.2 which require infrastructure changes and does NOT meet my needs.
>
> If I want to send detailed accounting messages in an accounting flow 
> then I should arbitrarily partition a single transaction and come up 
> with some unknown mechanism to understand if the full message has been 
> received.
>
> If I want to send certificates during an access request then I should 
> use a URL.
>
> referenced externally.  It might be an operational headache but it can 
> be done.  For me it is not about what can be done it is about what is 
> the most effective solution.  I don't want a series of workarounds I 
> want one solution.
>
> We have a new concept for long attributes allowing vendors to send 
> large blocks of data in the command code of their choosing but there 
> is no serious way to utilize this facility without running into the 
> packet limit.
>
> "Satisfy ABFAB requirements on supporting chunked data transfer prior 
> to the authentication flow"
>

Yes, but those are related to authorization.

---

From: Peter Deacon <[email-masked]>
Date: Fri, 15 Mar 2013 09:42:36 -0700 (Pacific Daylight Time)

On Fri, 15 Mar 2013, Alejandro Perez Mendez wrote:

>> From Alex's presentation even ABFAB has requirements for sending data prior 
>> to authentication.

Hi Alex,

Thanks, I will wait for the draft.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Fri, 15 Mar 2013 13:33:30 -0400

> Any justification I make will be thrown back at me with workarounds.

  Protocol design involves peer review and trade-offs between costs and
benefits.  There shouldn't be a problem discussing those trade-offs, and
responding to peer review.

  For me, the "workarounds" you talk about are no worse, and in many
cases better, than the ones you propose for your draft.

> 3.4.2 which require infrastructure changes and does NOT meet my needs.

Q: How does CoA handle large filter lists today?
A: It doesn't.

Q: How do we handle it with your draft?
A: With infrastructure changes

Q: How do we handle it with Alejandro's draft?
A: With infrastructure changes

Q: Why does your draft "meet your needs", and Alejandro's draft doesn't?
A: You're not saying.

> with some unknown mechanism to understand if the full message has been

Q: How are multiple flows for one session handled today?
A: With Acct-Multi-Session-Id.  (as has been pointed out repeatedly)

Q: How do we handle it with your draft?
A: With duplicate functionality, and infrastructure changes.

Q: Why are you preferring infrastructure changes to re-using functionality?
A: You're not saying.

> If I want to send certificates during an access request then I should

Q: How is this handled today?
A: RFC 5904 defines a similar method, which isn't general.

Q: Does sending a URL fulfill the requirements?
A: No, as pointed out earlier on this list.

Q: Was this point already addressed on the list?
A: Yes.  Multiple times.

Q: Why are you ignoring those explanations?
A: You're not saying.

> referenced externally.

Q: Why are you ignoring previous explanations of this topic?
A: You're not saying.

> It might be an operational headache but it can

Q: Is there a need for a series of workarounds?
A: No, as explained repeatedly here, and in the draft.

> serious way to utilize this facility without running into the packet limit.

Q: Are the long attributes useful without fragmentation?
A: Yes. RFC 5904 (among others) could have used them.

> supporting Diameter than RADIUS over TCP.

Q: Why is Diameter not acceptable for RADIUS infrastructure?
A1: Because it's not supported by vendor NAS equipment.
A2: Because proxy maintainers don't have $$ for commercial Diameter
    solutions.

> From Alex's presentation even ABFAB has requirements for sending data

Q: Have I said that already?
A: Yes, in previous emails to this list.

  And we're back to the same sticking point.  There is a serious
communication problem here.  I'm explaining my position, and you're not
explaining yours.  You're also pretending I haven't explained my
position.  It doesn't give me confidence in the utility of this
conversation.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Fri, 15 Mar 2013 11:21:06 -0700 (Pacific Daylight Time)

> A: With infrastructure changes

By infrastructure change I was referring to the idea of separability of 
dynamic authorization from RADIUS.  The two systems need not overlap. 
For example RADIUS does not necessarily need visibility into a system 
dedicated to managing active sessions.

Forcing them to overlap means you have to change systems, data flows, 
operational considerations..etc.

With Fragment-Data or TCP or equivalent it is a low level detail handled 
by what amounts to transport layer, with no implications propagated up the 
stack.

> Q: Why does your draft "meet your needs", and Alejandro's draft doesn't?

I explained my reasons in response to Alex.

"With regards to CoA (Section 3.4.2) this scheme is less than ideal due to 
additional round trips, lack of feedback, lack of ability to implement 
fallback mechanisms and lack of separation of admission from session 
management.  We have separate systems (Not RADIUS servers) managing 
aspects of dynamic authorization."

> A: With Acct-Multi-Session-Id.  (as has been pointed out repeatedly)

I explained why this is insufficient repeatedly.  Oddly enough RFC 6158 
section 3.1 also echo's some of the same concern.

> A: With duplicate functionality, and infrastructure changes.

The problem is I have to invent something (sessions) that do not exist. 
Even if I invented random session id's to make the transport layer happy I 
still need to invent a way of reasoning on whether the whole transaction 
is complete.

> Q: Why are you preferring infrastructure changes to re-using functionality?

Installing a new version that upgrades transport details which have no 
effect up the stack is vastly different than updating backend 
infrastructure necessary to deal with this.

> Q: Why are you ignoring previous explanations of this topic?

I understand the reasons but they do not make this impossible to overcome. 
It is just operationally inconvenient which is how I would also classify 
your suggestions.

> A: No, as explained repeatedly here, and in the draft.

Not my question.

>> large blocks of data in the command code of their choosing but there is 
>> no serious way to utilize this facility without running into the packet 
>> limit.

> A: Yes. RFC 5904 (among others) could have used them.

Not my question.

> A1: Because it's not supported by vendor NAS equipment.

Neither is RADIUS/TCP as near as I can tell.

> A2: Because proxy maintainers don't have $$ for commercial Diameter

:)

> A: Yes, in previous emails to this list.

I get confused easily with the revisions.  I was under the impression 
sending fragmented data to the server was being resurrected in the 
upcoming draft.  I'm sorry for my misunderstanding of this point.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Fri, 15 Mar 2013 15:05:58 -0400

> dynamic authorization from RADIUS.  The two systems need not overlap.

  Sure.  But if it's not RADIUS, then it's not up for discussion here.

> dedicated to managing active sessions.

  But it can use it... as with CoA.

> operational considerations..etc.

  I'm not sure what you mean.  You seem to be saying that because some
systems don't do CoA via RADIUS, we should prevent other systems from
doing CoA via RADIUS.

> "With regards to CoA (Section 3.4.2) this scheme is less than ideal due
> managing aspects of dynamic authorization."

  Any fragmentation method has additional round trips over just using
CoA-Request and CoA-Ack.  I'm not sure what you mean by "lack of
feedback", or "fallback mechanisms".  And again, if you have non-RADIUS
servers managing dynamic authorization, that is NOT a reason to limit
other peoples implementation of RADIUS.

  This is a problem I've run into time and again.  I'm OK with you using
non-RADIUS systems.  You're not OK with me using RADIUS systems.  So
you're trying to prevent a solution which works for RADIUS, because you
don't want to use it.

  The only response I have then is "Why are you here?"  If you're not
using RADIUS, you shouldn't care what RADIUS people do.

> section 3.1 also echo's some of the same concern.

  Well... no.  The text in RFC 6158 says that splitting attributes
across multiple Accounting-Request packets is wrong and unnecessary.
Alejandro's draft points out that we are already doing accounting for
multiple flows in RADIUS.

  There has been no demonstrated need to send more than 4K of *tightly
related* data in accounting.  RADIUS can do accounting for multiple
streams in one session, via widely deployed and standardized methods.

  In contrast, the Abfab people want to send >4K blocks of data (SAML
assertions), which cannot be split up into independent pieces.

> Even if I invented random session id's to make the transport layer happy
> I still need to invent a way of reasoning on whether the whole
> transaction is complete.

  i.e. you're saying that existing use of Acct-Multi-Session-Id is
impossible, and won't work.

  Well... reality disagrees with you.

> I understand the reasons but they do not make this impossible to
> overcome. It is just operationally inconvenient which is how I would
> also classify your suggestions.

  We use RADIUS because it's inconvenient to use IPv4 over carrier
pigeon.  Operation convenience is absolutely part of protocol design.

>> A: No, as explained repeatedly here, and in the draft.

  Then you're attacking a straw man.

> Neither is RADIUS/TCP as near as I can tell.

  Good point.  So... which is easier to implement for the NAS vendors?
RADIUS over TCP, or Diameter?

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Fri, 15 Mar 2013 12:55:00 -0700 (Pacific Daylight Time)

> systems don't do CoA via RADIUS, we should prevent other systems from

With 3.4.2 approach RFC 5176 compliant RADIUS clients would be prevented 
from doing CoA containing large packets using RADIUS protocol without 
forced synchronization with RADIUS server infrastructure.

> feedback", or "fallback mechanisms".  And again, if you have non-RADIUS

lack of feedback = Error-Cause
fallback mechanism = Responding to Error-Cause

> other peoples implementation of RADIUS.

This is backwards.  3.4.2 would limit dynamic authorization client 
autonomy.  Nothing is preventing RADIUS servers from issuing dynamic 
authorization requests.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Fri, 15 Mar 2013 16:19:45 -0400

> forced synchronization with RADIUS server infrastructure.

  Yes.

> fallback mechanism = Responding to Error-Cause

  That can be signaled in the fragmentation exchange.

> autonomy.  Nothing is preventing RADIUS servers from issuing dynamic

  Yes.  The draft proposes that dynamic authorization clients and RADIUS
servers be tightly coupled.

  If the initial authentication sets up authorization rules on the NAS,
how do those get to the dynamic authorization client (DAC)?  If the
RADIUS server doesn't communicate with the DAC, then it is *impossible*
to make any subsequent authorization changes.

  i.e. The use case you're concerned about is when the DAC *doesn't*
have access to the authorization rules, but *can* change them later.

  That confuses me.  I don't see how that works.

  Alan DeKok.