RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs

["Bernard Aboba" <bernard_aboba@hotmail.com>]

> What happens in the instance that a diameter->radius gateway can't 
> translate a packet?

RFC 4005 Section 9 describes two situations in which translation may not be 
possible:

"  Although the Diameter protocol is in many ways a superset of RADIUS
  functions, a number of RADIUS representations are not allowed, so
  that new capabilities can be used without the old problems.

  There are primarily two different situations that must be handled:
  one in which a RADIUS request is received that must be forwarded as a
  Diameter request, and another in which the inverse is true.  RADIUS
  does not support a peer-to-peer architecture, and server-initiated
  operations are generally not supported.  See [RADDynAuth] for an
  alternative.

  Some RADIUS attributes are encrypted.  RADIUS security and encryption
  techniques are applied on a hop-per-hop basis.  A Diameter agent will
  have to decrypt RADIUS attribute data entering the Diameter system,
  and if that information is forwarded, the agent MUST secure it by
  using Diameter specific techniques."

> There must be some exception path, right?

My reading of RFC 4005 is that other than these situations, that RADIUS 
packets are expected to be translatable to Diameter.  RADIUS does not have a 
mechanism to enable a NAS to indicate an error in response to an 
Access-Accept, so that if RADIUS packets are not translatable it would 
difficult to communicate this to a RADIUS server.  If the NAS does a silent 
discard, then no Accounting-Request is generated.  That's the only 
indication that a RADIUS server will have that the attributes sent were 
unacceptable.

> If so, why couldn't we leave in the MUST NOT for mixture of filter-id and 
> nas-filter-rule
> attributes and have the gateway generate an error to avoid wedging both 
> attributes into a radius >packet?

On the Diameter side, behavior will depend on whether the gateway silently 
discards the RADIUS packet (in which case no error would be sent to the 
Diameter NAS) or whether it acts as though an Access-Reject were received 
(in which case the Diameter equivalent of the Reject would be sent to the 
NAS).

BTW, here is what RFC 2119, Section 6 says about MUST and MUST NOT:

"   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability."

In this particular case, there does not appear to be an interoperability 
issue (in fact, the MUST NOT might create an issue), so we are left with 
assessing the potential for causing harm.



--
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/>