Subject: nasreq attribute handling

From: "Yves T'Joens" <[email-masked]>
Date: Tue, 19 Oct 1999 14:18:47 +0200

Hi Nasreq,

I started off some mails back with a discussion on handling of
attributes/messages in a proxy situation, however during the discussion,
the topic diverged to handling of vendor specific attributes.

Here is a set of requirements that could be included in the nasreq
document, specific to proxy handling in an inter-domain scenario. Note
that this is irrespective of the vendor specific or standardized nature
of the attribute/message.

Handling of attributes/ messages
--------------------------------

The protocol MUST allow the sending implementation to indicate to the
next hop in the proxy chain to behave as follows on the receipt of an
unknown attribute/message 
(a) silently discard and proceed
(b) interrupt the session associated with the sending of this
attribute/message
(c) send back an error message and proceed unmodified
(d) forward the attribute/message unmodified to the next hop (no
semantic interpretation required)

The protocol MUST allow the sending implementation to indicate to the
end system in the chain to behave as follows on the receipt of an
unknown attribute/message
(a) silently discard and proceed
(b) interrup the session associated with the sending of this
attribute/message
(c) send back an error message and proceed unmodified

Yves

---

From: Robert Pluim <[email-masked]>
Date: Wed, 20 Oct 1999 09:34:12 +0200 (CEST)

> Handling of attributes/ messages

?? What's the difference between (a) and (b). Discarding implies
interruption.

 > semantic interpretation required)

If I were even a mildly paranoid ISP, I would never allow (c) and
scream at anyone that implemented (d). Who knows what that
attribute/message could be controlling?

Robert

--

---

From: "Yves T'Joens" <[email-masked]>
Date: Thu, 21 Oct 1999 09:14:48 +0200

> ?? What's the difference between (a) and (b). Discarding implies

I would not say so. Some AVPs may just be discarded, while the session
will survive, only with deteriorated service handling. This is in my
opinion how most of the vendor specific additions to any base protocol
should be handled.

> If I were even a mildly paranoid ISP, I would never allow (c) and

well, (c) would only allow some limited debugging, however this req. may
be dropped, I don't care too much...

> attribute/message could be controlling?

Given a single administrative domain, and a proxy situation. Trust of
operation is not necessarily an issue.

Assume the NAS to be of vendor X, the proxy of vendor Y and the end AAA
server of vendor Z. 
Assume a piece of information V that only needs to be send from the
NAS_X to the end server_Z, without any semantic interpretation of the
proxy. (assume e.g., the proxy is just there for scaleability of the
configuration, and possible attribute modification)
Assume the proxy has not yet the software upgrade to syntactically and
semantically interprete V. 
In such a case, my opinion is that requirement (d) might be valuable.

note that specific to _interdomain_ proxy operation, the pass-along or
not of unknown information is indeed susceptible to a certain policy,
there I certainly agree with you.

regards,
Yves

---

From: Robert Pluim <[email-masked]>
Date: Thu, 21 Oct 1999 10:17:15 +0200 (CEST)

> opinion how most of the vendor specific additions to any base protocol

Sorry, I misunderstood here, I thought you meant discarding the entire
message. You're right, in most cases unrecognised attributes should
just be transparently discarded.

 > be dropped, I don't care too much...

Hmm, ok. (b) would make it more obvious that things are going wrong,
though.

 > operation is not necessarily an issue.

Given a single administrative domain, I agree. Given multiple
administrative domains, behaviour like (d) is distinctly unpopular
unless explicitly enabled.

 > In such a case, my opinion is that requirement (d) might be valuable.

In that one case, yes.

 > there I certainly agree with you.

So perhaps we should specify that the behaviour should be configurable
(in practice I think it would be made so anyway).

Robert