Subject: [AAA-WG]: [Issue] Error processing/capabilities negotiation

From: Jacques Caron <[email-masked]>
Date: Tue, 07 Aug 2001 14:03:42 +0200

Submitter name:		Jacques Caron
Submitter email address:	[email-masked]
Date first submitted:		August 6, 2001
Reference:
Document:			Base-07
Comment type:			E
Priority:			1
Section:			throughout
Rationale/Explanation of issue:

In the current draft, there are many situations where any agent can return 
an error when processing a message (e.g. when receiving an AVP tagged with 
the 'M' bit that it doesn' accept). However, there are no provisions for 
sending an error in response to an answer (an error is an answer, and can 
only be sent in response to a request).

This makes it difficult to handle some cases, especially end-to-end 
capabilities negotiation (e.g. server wants access device to set up some 
filter, encryption, IP address, route..., but access devices cannot/will 
not do it: there is no way for the access device to communicate this back 
to the server).

I think the best approach is to move from the simple Request/Answer model 
to a Transaction model possibly involving multiple round-trips until 
everybody is satisfied. Another possibility is for access devices to 
advertise their capabilities in advance in the initial request, but that 
might be quite difficult.

Follows a (longish) description of one possible implementation using the 
Transaction model. I think most people might find it waaaaaay too complex, but:
(a) it gives a clear understanding of the process and the several 
round-trips, why they are needed, and when.
(b) there are hints at the end as to ways to simplify this A LOT :-)

Creativity welcome :-)

The following messages can be exchanged between two nodes:

Msg	Dir	Description				Expects
------	----	---------------------------------------	---------------------------
REQ	C->S	request					WMORE, AUTH, REJECT, ACCEPT
MORE	C->S	error or additional information		WMORE, AUTH, REJECT, ACCEPT
NAUTH	C->S	auth not accepted, need new one		AUTH, REJECT
ACK	C->S	auth accepted				ACCEPT
ABORT	C->S	transaction abort			REJECT

WMORE	S->C	request for more information		MORE, ABORT
AUTH	S->C	authorization information		ACK, NAUTH, ABORT
REJECT	S->C	reject connection/non-recoverable error	(nothing)
ACCEPT	S->C	accept with negociated authorization	(nothing)

"server" and "client" are defined here solely in the context of the given 
transaction, the client being the node initiating the transaction, and the 
server being the node that is supposed to provide an answer.

REQ is the first message of a transaction, including application, realm, 
etc. It is routed according to the realm routing table towards the server 
for regular access-device to home-server transactions, and using 
source-routing for home-server to access-device transactions. Routing 
information is collected on the way and stored in Route-Record AVPs.

MORE is sent whenever the client needs to send additional or modified 
information in a transaction. It might be due to capabilities negociation 
(e.g. the server didn't understand an 'M'-AVP) or a multi-round-trip auth 
(e.g. EAP), that were signalled by the server using a WMORE message.

NAUTH is sent whenever the client received authorization information (AUTH) 
for the transaction, but isn't satisfied with it (e.g. there is an 'M'-AVP 
that it doesn't accept). It includes the usual AVP-related info (missing 
AVP, bad AVP value, unrecognized AVP...), possibly with hints about 
accepted values (I like very much the modem AT command set extensions such 
as AT+command=? that give a list of allowed values, would be cool if we 
could have something equivalent here).

ACK is sent once the client got authorization information for the 
transaction (AUTH) from the server, and is satisfied with it.

ABORT is sent by the client if it got a WMORE message and cannot provide 
any new or modified information (e.g. the server didn't accept an 'M'-AVP, 
but the access device absolutely needs it), or got an AUTH message and 
doesn't accept some of the values and doesn't want to negotiate them.

MORE, NAUTH, ACK, and ABORT are sent with Source-Route AVPs from the WMORE 
or ANS message.

WMORE is sent by the server to the client if it needs the client to send 
additional or modified information (using a MORE message). It includes info 
about what it wants (e.g. further EAP messages, or modified AVPs).

AUTH is sent by the server when it has any authorization information it 
wants to send the client.

ACCEPT is sent by the server to the client to give a final yes, either 
directly after receiving info (REQ or MORE) if it only says "yes", or after 
receiving an ACK accepting previous AUTH information.

REJECT is sent by the server to the client if the transaction was refused 
or if there was an unrecoverable error, or if the server got a NAUTH to an 
AUTH message and doesn't want to negotiate, or to confirm it got an ABORT.

All messages from server to client (WMORE, AUTH, ACCEPT, REJECT) are routed 
using stored message state in proxies/relays. They also carry Route-Record 
information to help routing of further messages from client to server.

Note that "authorization" (and of course AUTH and NAUTH) is an abuse, it's 
actually any negotiable AVPs the server sends to the client, but the only 
case I could think of is authorization information.

So, in the simplest case, the scenario would be:
REQ  ->
      <- ACCEPT

If there is any authorization information:
REQ  ->
      <- AUTH
ACK  ->
      <- ACCEPT

In a simple 2-round trip EAP auth, the scenario might be:
REQ  ->
      <- WMORE
MORE ->
      <- AUTH
ACK  ->
      <- ACCEPT

In a simple one-round trip auth, but where the access devices doesn't agree 
with the authorization parameters the first time, it would be:
REQ   ->
       <- AUTH
NAUTH ->
       <- AUTH
ACK   ->
       <- ACCEPT

Server doesn't understand/accept an AVP the client sent, and the client 
doesn't want to do without:
REQ   ->
       <- WMORE
ABORT ->
       <- REJECT

Server thinks the access device is completely out of its mind, or knows 
right away the user is not allowed:
REQ   ->
       <- REJECT

More generally, for a successful transaction:
   REQ   ->
[
         <- WMORE
   MORE  ->
]*
[
         <- AUTH
  [
   NAUTH ->
         <- AUTH
  ]*
   ACK   ->
]?
         <- ACCEPT

Note that it may require adding a transaction identifier. Alternatively, 
the session identifier may be enough?

On a final note, it might be possible to reduce the number of possible 
message types (by using some other AVP, e.g. different ranges of 
Result-Code), but it must be possible for relays/proxies to track a 
transaction state, i.e. know when it ends (by either a REJECT or an 
ACCEPT). All that is needed (as seen from the outside) are "Request" 
(anything client to server), "Continue" or "Challenge" (WMORE, AUTH) and 
"Answer" (REJECT, ACCEPT). This could be done by classifying correctly all 
Result-Codes that require further exchanges in a different range than those 
that don't. In particular, that means that any answer with negotiable AVPs 
should be in the first category, since they need another request to either 
accept them, or ask for changes.

Jacques-in-complex-mode.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 7 Aug 2001 05:13:40 -0700

> only be sent in response to a request).

Right. So the spec states that if this should occur, the access device
should terminate the session, via an STR.

> might be quite difficult.

This is not a requirement in RFC 2989, or in any of the requirements
specs that were used to create RFC 2989. I would feel very uncomfortable
redesigning the protocol this late in the game.

IMHO, this isn't a problem. A request fails, then you ask again. An answer
fails, then you terminate the session. You can ask again if necessary.

> Jacques-in-complex-mode.

I think I like the other Jacque better. Can you bring him back :) :)

PatC

---

From: Jacques Caron <[email-masked]>
Date: Tue, 07 Aug 2001 14:47:59 +0200

>should terminate the session, via an STR.

I think this is way too harsh.

>redesigning the protocol this late in the game.

I'm pretty sure I had seen capabilities negotiation somewhere in some 
requirements doc (though I can't find where), and I had understood that to 
be end-to-end, not the (very limited) peer-to-peer capabilities negotiation 
we do in CER/CEA.

>fails, then you terminate the session. You can ask again if necessary.

The request doesn't fail: it just gives you information you can't handle 
(or don't want to), and there is no way to retry it by specifying which 
parts you didn't like :-(

>I think I like the other Jacque better. Can you bring him back :) :)

Did you notice we had a full moon last night? ;->

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 7 Aug 2001 06:21:11 -0700

> I think this is way too harsh.

Perhaps it is crude, but it is simple, and it works.

> be end-to-end, not the (very limited) peer-to-peer capabilities negotiation 

The capabilities negotiation discussions that I am aware of didn't include this.

> parts you didn't like :-(

well, you get information back on what the sender of the answer message didn't
like. THen you can try again. If the problem is with the processing of the
answer message itself, then we can either:
1. do something simple as we have now (terminate session), and try again if
   need be.
2. re-architect the protocol to have 3 way messages (req->answ->ack)

I'd opt for #1

PatC

---

From: Jacques Caron <[email-masked]>
Date: Tue, 07 Aug 2001 15:42:19 +0200

At 15:21 07/08/01, Pat Calhoun wrote:
>like. THen you can try again.

That indeed works fn=ine when the server rejects a request.

>  If the problem is with the processing of the

I do you try again? You're supposed to get the same answer again, aren't you?

>2. re-architect the protocol to have 3 way messages (req->answ->ack)

3. Have two types of answers: those that require further exchanges, and 
those that do not. On top of EAP-type stuff, any answer with 'M'-AVPs would 
be in the first category. Then we just need a way to send a request 
specifying "I didn't like your answer, dude, gimme another one". And just 
for symmetry (to avoid having servers maintaining state for an answer for 
which they might or might not get a new request), a dummy "I'm fine thank 
you" request. Of course all "regular" answers (the "yes/no" kind, without a 
collection of authorization AVPs) don't need further request/answers.

>I'd opt for #1

I'd opt for #3 :-)

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 7 Aug 2001 06:34:59 -0700

> I do you try again? You're supposed to get the same answer again, aren't you?

you will if you send the same thing again. Of course, you can modify the
request instead to make sure that the response is not the same.

PatC