Subject: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30

From: Pat Calhoun <[email-masked]>
Date: Fri, 25 May 2001 05:23:46 -0700

All,

Below is the new text for section 9, which attempts to address the issues
mentioned above. I would appreciate some feedback from folks on whether the
text is consistent with their understanding of the outcome of the Interim
meeting.

Actual fixes:

Issue 13: DSI is removed, and a new answer only message is used to report
protocol errors. Protocol errors MAY be treated at each hop. The DSI-Events
are moved to a new class within the Result-Code AVP.

Issue 18: Error-Reporting-FQDN was a dup of Origin-FQDN, and therefore MUST
only be included if a host is changing the result-code AVP, and is not the
one whose identity is in the Origin-FQDN.

Issue 30: Failed-AVP should be a grouped AVP, and include the offending AVP
in it's group.

Thanks,

PatC
----
9.0  Error Handling

   There are two different types of errors in Diameter; protocol and
   extensions. A protocol error is one that occurs at the base protocol
   level, and MAY require attention at each hop in a proxy environment
   (e.g. message routing error). Extension errors, on the other hand,
   are generally occur due to a problem with a function specified in a
   Diameter extension(e.g. user authentication, Missing AVP).

   Result-Code AVP values that are used to report protocol errors MUST
   be used in the Message-Reject-Answer command. Unlike most Diameter
   commands, the Message-Reject-Answer does not have a corresponding
   request.

   When a request message is received that causes a protocol error, the
   command code is changed to Message-Reject-Answer, and the Result-Code
   AVP is set to the appropriate protocol error value. As the answer is
   sent back towards the originator of the request, each proxy MAY take
   action on the message.

Calhoun et al.            expires October 2001                 [Page 41]

Internet-Draft                                                  May 2001

                    1. Request        +---------+ Link Broken
          +-------------------------->|Diameter |----///----+
          |     +---------------------|         |           v
   +------+--+  |      2. MRA         | Proxy 2 |     +--------+
   |Diameter |<-+ (Unable to Forward) +---------+     |Diameter|
   |         |                                        |  Home  |
   | Proxy 1 |--+                     +---------+     | Server |
   +---------+  |   3. Request        |Diameter |     +--------+
                +-------------------->|         |           ^
                                      | Proxy 3 |-----------+
                                      +---------+
         Figure 1 - Example of Protocol Error causing MRA message

   Figure 1 provides an example of a message sent by a Diameter proxy
   towards a home server. When the message is received by Proxy 2, and
   it detects that it cannot forward the request to the home server, an
   MRA message is returned with the Result-Code AVP set to
   DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the
   protocol error category, Proxy 1 would take special action, and given
   the error, attempt to route the message through its alternate proxy
   3.

   +---------+ 1. Request  +---------+ 2. Request  +---------+
   | Access  |------------>|Diameter |------------>|Diameter |
   |         |             |         |             |  Home   |
   | Device  |<------------|  Proxy  |<------------| Server  |
   +---------+  4. Answer  +---------+  3. Answer  +---------+
              (Missing AVP)           (Missing AVP)
           Figure 2 - Example of Extension Error Answer message

   Figure 2 provides an example of a Diameter message that caused an
   extension error. When extension errors occur, the Diameter entity
   reporting the error clears the 'R' bit in the Command Flags, and adds
   the Result-Code AVP with the proper value. Extension errors do not
   require any proxy involvement, and therefore the message would be
   forwarded back to the originator of the request.

   There are certain Result-Code AVP extensions errors that require
   additional AVPs to be present in the answer, such as:

      - An unrecognized AVP is received with the 'M' bit (Mandatory bit)
        set, causes an answer to be sent with the Result-Code AVP set to
        DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP containing the
        offending AVP.
      - An AVP that is received with an unrecognized value causes an
        answer to be returned with the Result-Code AVP set to
        DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing
        the AVP causing the error.

Calhoun et al.            expires October 2001                 [Page 42]

Internet-Draft                                                  May 2001

      - A command is received with an AVP that is ommitted, yet is
        mandatory according to the command's ABNF. The receiver issues
        an answer with the Result-Code set to DIAMETER_MISSING_AVP, and
        creates an AVP with the AVP Code and other fields set to the
        missing AVP's. The created AVP is then added to the Failed-AVP
        AVP.

   The Result-Code AVP contains additional errors conditions, and
   defines the expected behavior of each.

9.1  Result-Code AVP

   The Result-Code AVP (AVP Code 268) is of type Unsigned32 and
   indicates whether a particular request was completed successfully or
   whether an error occurred. All Diameter answer messages MUST include
   one Result-Code AVP. A non-successful Result-Code AVP (one containing
   a non 2xxx value) MUST include the Error-Reporting-Host AVP if the
   host setting the Result-Code AVP is different from the identity
   encoded in the Origin-Host AVP.

   The Result-Code data field contains an IANA-managed 32-bit address
   space representing errors (see section 16.4). Diameter provides the
   following classes of errors, all identified by the thousands digit:
      - 1xxx (Informational)
      - 2xxx (Success)
      - 3xxx (Protocol Errors)
      - 4xxx (Transient Failures)
      - 5xxx (Permanent Failure)

   A non-recognize class (one whose first digit is not defined in this
   section) MUST be handled as a permanent failure.

9.1.1  Informational

   Errors that fall within the Informational category are used to inform
   a requester that the request cannot be immediately satisfied and a
   further response will be issued in the near future. There are
   currently no errors that fall within this class.

9.1.2  Success

   Errors that fall within the Success category are used to inform a
   peer that a request has been successfully completed.

      DIAMETER_SUCCESS                   2001

Calhoun et al.            expires October 2001                 [Page 43]

Internet-Draft                                                  May 2001

         The Request was successfully completed.

9.1.3  Protocol Errors

   Errors that fall within the Protocol Error category SHOULD be treated
   on a per-hop basis, and Diameter proxies MAY attempt to correct the
   error, if it is possible. Note that these errors MUST only be used in
   the Message-Rejected-Answer message, therefore a Diameter entity that
   wishes to return an error in this category MUST change the command
   code to Message-Rejected-Answer message.

      DIAMETER_INVALID_ROUTE_RECORD      3001
         The last Route-Record AVP in the message is not set to the
         identity of the sender of the message. See Section 11.0 for
         more information.

      DIAMETER_COMMAND_UNSUPPORTED       3002
         The Request contained a Command-Code that the receiver did not
         recognize or support.

      DIAMETER_UNABLE_TO_DELIVER         3003
         The request could not be delivered to a host that handles the
         realm, and extension, requested at this time.

      DIAMETER_REALM_NOT_SERVED          3004
         The intended realm of the offending message is unknown.

      DIAMETER_TOO_BUSY                  3005
         When returned, a Diameter node SHOULD attempt to sent the
         message to an alternate peer.

      DIAMETER_INVALID_CMS_DATA          3006
         The Request did not contain a valid CMS-Data [11] AVP.

      DIAMETER_LOOP_DETECTED             3007
         A Proxy or Redirect server detected a loop while trying to get
         the message to the Home Diameter server. The message MAY be
         sent to an alternate peer, if one is available, but the peer
         reporting the error has identified a configuration problem.

      DIAMETER_END_2_END_SECURITY        3008
         A proxy has detected that end-to-end security has been applied
         to portions of the Diameter message, and the proxy does not
         allow this security mode since it needs to alter the message by
         applying some local policies.

Calhoun et al.            expires October 2001                 [Page 44]

Internet-Draft                                                  May 2001

9.1.4  Transient Failures

   Errors that fall within the transient failures category are used to
   inform a peer that the request could not be satisfied at the time it
   was received, but MAY be able to satisfy the request in the future.

      DIAMETER_AUTHENTICATION_REJECTED   4001
         The authentication process for the user failed, most likely due
         to an invalid password used by the user. Further attempts MUST
         only be tried after prompting the user for a new password.

      DIAMETER_OUT_OF_SPACE              4002
         A Diameter node received the accounting request but was unable
         to commit it to stable storage due to a temporary lack of
         space.

9.1.5  Permanent Failures

   Errors that fall within the permanent failures category are used to
   inform the peer that the request failed, and should not be attempted
   again.

      DIAMETER_USER_UNKNOWN              5001
         A request was received for a user that is unknown, therefore
         authentication and/or authorization failed.

      DIAMETER_AVP_UNSUPPORTED           5002
         The peer received a message that contained an AVP that is not
         recognized or supported and was marked with the Mandatory bit.
         A Diameter message with this error MUST contain one or more
         Failed-AVP AVP containing the AVPs that caused the failure.

      DIAMETER_UNKNOWN_SESSION_ID        5003
         The request contained an unknown Session-Id.

      DIAMETER_AUTHORIZATION_REJECTED    5004
         A request was received for which the user could not be
         authorized.  This error could occur if the service requested is
         not permitted to the user.

      DIAMETER_INVALID_AVP_VALUE         5005
         The request contained an AVP with an invalid value in its data
         portion. A Diameter message indicating this error MUST include
         the offending AVPs within a Failed-AVP AVP.

      DIAMETER_MISSING_AVP               5006
         The request did not contain an AVP that is required by the

Calhoun et al.            expires October 2001                 [Page 45]

Internet-Draft                                                  May 2001

         Command Code definition. If this value is sent in the Result-
         Code AVP, a Failed-AVP AVP SHOULD be included in the message.
         The data portion of the Failed-AVP MUST contain an AVP header
         containing the AVP Code and vendor-Id.

      DIAMETER_AUTHORIZATION_FAILED      5007
         A request was received for which the user could not be
         authorized at this time. This error could occur when the user
         has already expended allowed resources, or is only permitted to
         access services within a time period.

      DIAMETER_CONTRADICTING_AVPS        5008
         The Home Diameter server has detected AVPs in the request that
         contradicted each other, and is not willing to provide service
         to the user. One or more Failed-AVP AVPs MUST be present,
         containing the AVPs that contradicted each other.

      DIAMETER_AVP_NOT_ALLOWED           5009
         A message was received with an AVP that MUST NOT be present.
         The Failed-AVP AVP MUST be included and contain the AVP Code of
         the offending AVP.

      DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010
         A message was received that included an AVP that appeared more
         often than permitted in the message definition. The Failed-AVP
         AVP MUST be included and contain the AVP Code of the offending
         AVP.

      DIAMETER_VENDOR_ID_UNSUPPORTED     5011
         The Home Diameter server has detected vendor-specific AVPs in
         the message, and the vendor dictionary is not supported. One or
         more Failed-AVP MUST be present, containing the offending AVPs.

      DIAMETER_UNSUPPORTED_TRANSFORM     5012
         A message was received that included an CMS-Data AVP [11] that
         made use of an unsupported transform.

      DIAMETER_NO_COMMON_EXTENSION       5013
         This event is returned when a DRA message is received, and
         there are no common extensions supported between the peer.

      DIAMETER_UNSUPPORTED_VERSION       5014
         This event is returned when a DRA message is received, and the
         Diameter message is unsupported.

9.2  Message-Reject-Answer

Calhoun et al.            expires October 2001                 [Page 46]

Internet-Draft                                                  May 2001

   The Message-Reject-Answer (MRA), indicated by the Command-Code set to
   282, and the Command Flags' 'R' bit cleared, is sent in response to a
   request that has caused a protocol error.

   Although the command code is different from the one found in the
   request, the same procedures used in issuing an answer message is
   followed. The Result-Code AVP MUST be present, and include a value in
   the "Protocol Error" category.

   Proxies receiving an MRA message MAY attempt to rectify the error
   reported, if possible. In the event that no proxy is able to correct
   the problem, the MRA will be returned to the originator of the
   request message.

   Message Format

      <Message-Reject-Answer> ::= < Diameter Header: 282, I >
                                  < Session-Id >
                                  { Origin-Host }
                                  { Origin-Realm }
                                  { Result-Code }
                                  { Destination-Host }
                                * [ AVP ]

9.3  Error-Message AVP

   The Error-Message AVP (AVP Code 281) is of type OctetString.  It is a
   human readable UTF-8 character encoded string.  It MAY accompany a
   Result-Code AVP as a human readable error message. The Error-Message
   AVP is not intended to be useful in real-time, and SHOULD NOT be
   expected to be parsed by network entities.

9.4  Error-Reporting-Host AVP

   The Error-Reporting-Host AVP (AVP Code 294) is of type OctetString,
   encoded in the UTF-8 [24] format, according to the Diameter identity
   rules defined in section 2.6.  This AVP contains the identity of the
   Diameter host that set the Result-Code AVP to a value other than 2001
   (Success), only if the host setting the Result-Code is different from
   the one encoded in the Origin-Host AVP. This AVP is intended to be
   used for troubleshooting purposes, and MUST be set when the Result-
   Code AVP indicates a failure.

9.5 Failed-AVP AVP

Calhoun et al.            expires October 2001                 [Page 47]

Internet-Draft                                                  May 2001

   The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
   debugging information in cases where a request is rejected or not
   fully processed due to erroneous information in a specific AVP. The
   value of the Result-Code AVP will provide information on the reason
   for the Failed-AVP AVP.

   The possible reasons for this AVP are the presence of an improperly
   constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
   value, the omission of a required AVP, the presence of an explicitly
   excluded AVP (see table 13.0), or the presence of two or more
   occurrences of an AVP which table 15.1 restricts to 0, 1, or 0-1
   occurrences.

   A Diameter message MAY contain one Failed-AVP AVP, containing the
   entire AVP that could not be processed successfully. If the failure
   reason is omission of a required AVP, an AVP with the missing AVP
   code, the missing vendor id, and a zero filled payload of the minimum
   required length for the ommitted AVP will be added.

   AVP Format

      <Failed-AVP> ::= < AVP Header: 279 >
                    1* {AVP}

---

From: Mark Eklund <[email-masked]>
Date: Fri, 25 May 2001 09:48:28 -0400 (EDT)

Pat,
Looks good.  One small documentation issue and one minor
issue.  See MWE>

>    +---------+  |   3. Request        |Diameter |     +--------+

MWE> Should you also have:
				    [ Error-Message ]
				    [ Error-Reporting-Host ]
				    [ Failed-AVP ]

>       <Failed-AVP> ::= < AVP Header: 279 >

MWE> When I sent you this text, I assummed that if you had more
than one problematic AVP for the same reason, you could add
multiple AVPs to the Failed-AVP (hence the 1* {AVP} above).  I
just wanted to make sure that is how everyone else saw it.

-mark

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 25 May 2001 07:07:24 -0700

> > MWE> Should you also have:

right, I should probably propagate these to all answer messages.

> just wanted to make sure that is how everyone else saw it.

yup, that's what the proposed ABNF says, and I agree that there isn't
a reason for multiple Failed-AVP AVPs.

PatC

---

From: Paul Funk <[email-masked]>
Date: Sat, 26 May 2001 19:47:17 -0400

Pat,

>one whose identity is in the Origin-FQDN.

I may be misremembering, but I thought we concluded that we could eliminate 
Error-Reporting-FQDN entirely. If a proxy sets its own failure Result-Code,
it is 
in effect taking responsibility for the response, and would set its own FQDN 
as Origin-FQDN.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 28 May 2001 10:43:50 +0200

Looks good to me, just two small questions/clarifications (see below).
/Fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf
>Of Pat Calhoun
>Sent: den 25 maj 2001 14:24
>To: [email-masked]
>Subject: [AAA-WG]: Proposed fixes for Issues 13, 18 and 30
>
>
>All,
>

Is there realy a 'R'-bit in the cmd flags? See Mark's mail titled "Make FAIR
flags a part of Command-Code"

>   required length for the ommitted AVP will be added.

Does a zero filled payload of the minimum length mean that a octetstring has
a payload of 1 byte. The AVP is then padded to be 32bit aligned.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 29 May 2001 11:28:52 -0700

> in effect taking responsibility for the response, and would set its own FQDN 

That's not what I remember, but I could be wrong.

Others?

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 29 May 2001 11:28:06 -0700

> flags a part of Command-Code"

Well, Mark's e-mail didn't quite reflect the figure that I had put on the
board, but the concept is identical. There is an 'R' bit only, where Mark's
e-mail introduced the 'A' bit.

Same difference, though.
> a payload of 1 byte. The AVP is then padded to be 32bit aligned.

correct.