Re: capabilities problem

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Hi,

On Thu, Oct 20, 2005 at 07:01:22PM -0400, Alan DeKok wrote:

> 
> > Indeed.  To put the point more forcefully -- continued attempts to advocate 
> > for the original capabilities advertisement draft are not productive.
> 
>   I don't understand.
> 
>   From my reading of recent messages and the draft, even Avi isn't
> advocating the solution proposed in the draft.  And I'm certainly
> opposed to much of what the draft says, for reasons I've articulated
> previously.
> 
>   To address one of Emile's points:
> 
> > In the case of GEOPRIV, and we've been at this at length, the case
> > of service being dependent on Location information CANNOT be
> > implemented in a single round trip AT ALL, because the NAS first
> > needs to be informed of the user's privacy policy -- in short,
> > whether or not that NAS is allowed to send the user's Location at
> > all.
> 
>   There is no conflict that I can see between this requirement and my
> position, or Avi's position.

Ok. So can we conclude that the inefficiency objection of a second
round trip in case of GEOPRIV is moot, because it's needed anyway, and 
that this is solved perfectly by your proposal with my refinements?

(In short, the NAS indicates (let's go of advertise for a moment, as
that has a broadcasting association with it) in its access request
support for Access-Challenges containing the Challenge-Cause attribute,
telling the server it can send a Challenge without fear of rejection,
and that the NAS will repeat its original access request if it doesn't
understand the Challenge-Cause).

Note that I'm not saying this solves the /other/ issue, that of
mandatory session limiting attributes ('prepaid'). There we /do/ want to
avoid a second round trip if possible, because its necessity has not
been demonstrated on other grounds.

>   The ability to perform multi-round negotiation of data to include in
> a packet is itself a capability that can be advertised.  That
> capability MUST (IMHO) be advertised in the first packet, otherwise
> the server may send an Access-Challenge to a NAS that doesn't support
> it.  The user then ends up with no service rather than limited service.

Agreed. Problably the misunderstanding lies in that I take 'advertising
a capability', as 'This party implements standards document X,
containing numberous clauses with musts, shoulds and mays', which I find
problematic. That's perhaps my biggest objection.

If you understand the advertised capability as semantically narrow as I
explained it ('the capability indicates that the NAS will behave as
follows when presented with information as follows'), then we are on the
same page.

>   The only disagreement I can see is that Avi and I believe that
> multi-round capability negotiation is itself a capability that has to
> be advertised, and others believe it's OK to send Access-Challenge
> without knowing if the NAS supports it.

I agree that it has to be advertised. In numerous messages about this
subject, including the one where I expanded on your suggestion that for
GEOPRIV, the NAS mainly has to advertise that it won't reject on
challenges that are properly labeled, I've said so.

>   For the record, my original position was that I was OK with blindly
> sending Access-Challenge, as it was fail safe.  But if there are
> use-cases where it's useful to offer limited services, then sending
> Access-Challenge is itself a capability that has to be negotiated or
> advertised.  The alternative is to make it impossible to "fail
> gracefully", and offer limited service.  The choice will be all or
> nothing.

We completely agree. I just want to make the semantics of the
advertisement as narrow as possible, without loss of generality (even
gaining it, because this support for 'reason-explained challenges' can
also be used for future things).

But I want to get rid of the explosion of possible states that a system
can get when two parties state their abilities, their wishes, and then
have to do a form of negotiation.

It took numerous endless looping implementations of PPP to get that
right in PPP.

If not absolutely needed, I definitely don't want negotiation, and I
want advertisements to be very narrow and with very well defined results
in case it does not sent or is not understood by the receiver, and so
on.

>   To put it another way:
> 
>   If Emile's NAS supports multi-round negotiation, then it advertises
> that, and the NAS and server perform the negotiation that Emile wants.

Inquiries, using particularly formed challenges, not negotiation. My
mechanism (Challenge-Supported = Yes and Challenge-Cause) could be used
for multi-round negotiation, but I'm not proposing that.

It's wasteful to use inquiries for information that can be included in
the first and final access request. It's only needed where the NAS MUST
withhold information from the first access request, as is the case with
GEOPRIV. 

If the use of challenges to get at information that can be put in the
first access request was Avi's worry too, then I completely agree.

I'm NOT proposing these challenges as the mechanism for all cases where the
server requires information from the NAS it currently doesn't have.

I am ONLY proposing these challenges as a mechanism for the cases where
the server requires information from the NAS that the NAS IS NOT ABLE to
send in its first Access-Request. Case in point: GEOPRIV, reason:
location privacy.

The 'advertisement' of support of a certain set of session limiting
attributes (and this is only a single bit of information per attribute
at most and a single bit of information per set of attributes at
minimum) can be done in the first access request. No extra roundtrips
necessary.

>   If Avi's NAS doesn't support multi-round negotiation, then it
> advertises that, and rather than doing negotiation, the server offers
> limited service, which is what Avi wants.

That phrase, 'multi-round negotiation', sends shivers down my spine as
it evokes the thought of endlessly debugging negotiations that don't
converge in certain implementations due to /very/ subtle bugs, and
admins having to fine tuning the advertisements so that the other side
responds correctly, and on and on.

>   I don't see any disagreement between the two positions, and I don't
> see how this relates to the original draft, which didn't talk about
> these issues.
> 
>   Avi's position (I believe), and mine, is to allow both scenarios.
> Emile's position (from what I can understand) would appear to prevent
> Avi from deploying his scenario.

Luckily here, you've misunderstood. I'm surprised. Am I really so bad at
explaining my position clearly?

I totally agree that the NAS must advertise that it will respond in a
certain defined way to challenges, for them to be useful as a mechanism
for GEOPRIV and related things.

(And to prevent all misunderstanding here: 'related things' DOES NOT
include CUI, session limiting attributes and and other static
information about the NAS!).

So I think we may have complete agreement on the problem and abstract
solution for GEOPRIV and alike future cases, at least between you, Avi
and myself. 

We only need to work out the attributes and values, but I suggest we
postpone that for a second and work on the problem statement for servers
requiring advance knowledge about the NAS' response to certain session
limiting attributes.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>