IETF66 DIME WG John Loughney, Hannes Tschofenig and Victor Fajardo 3588-bis: Current Issues

IETF66 DIME WG Overview Currently 20 Issues present in the tracker ( Majority of the issues generated during the last interop event (Week of April 24 th )

IETF66 DIME WG Issues that has associated drafts: Issue 4: draft-tsou-dime-base-routing-ext-00.txt Issue 21: draft-garica-dime-aaa-uri-00.txt Implementation related issues: Issue 6: TLS version issues Issue 7: Textual IP address qualify as FQDN Interop issues clarified using the current base spec: Issue 11: Confusion about use of Proxy-Info AVP for relay

IETF66 DIME WG Issue 1: Advertising relay id in Auth-Application-Id or Acct-Application-Id Issue (Critical): When advertising relay, should it be made in an Acct-Application-Id or an Auth-Application-Id or both? The relay application is neither an auth nor an acct application, but the protocol only specifies explicit AVPs for advertising one or the other Proposed Solution ?

IETF66 DIME WG Issue 3 and 16: CER/CEA exchange in open state Issue (Critical): Diameter peer statemachine defines a CER/CEA exchange in the open state but does not specify the behavior of the negotiation Proposed Solution: See issue 16. A “Peer Capabilities Update” section will be introduced in bis

IETF66 DIME WG Issue 2 and 5: Application id to be used by common diameter messages (ASR/ASA, STR/STA etc) Issue (Critical): What is the application id to be used in diameter messages common to applications, STR/STA, RAR/RAA, ASR/ASA Discussion: App id of zero(0) is unclear since implies all apps in the node App id of the application. CCA use app id of 4 for RAR/RAA but not for other msg Proposed Solution ?

IETF66 DIME WG Issue 15: Duplicate detection requires server side storage of E2E-Id and Origin-Host Issue (Urgent): Duplicate detection requires storage of Origin-Host and E2E-Id in the destination node. There seem to be no exact way to determine, when this data needs to be released. Proposed Solution ?

IETF66 DIME WG Issue 13: Clarify the usage of application id avp’s (Auth-Application-Id, Acct-Application-Id etc) and how they relate to the application id in the message header Issue: Why have two copies of application id, one in the header and in the other in application id avp’s of the message ? Do the header and AVP values always have to match? If not, what does it mean. Proposed Solution ?

IETF66 DIME WG Issue 9 and 19: Error codes defined in the wrong category Issue: Unclear what the differences are between error codes DIAMETER_INVALID_AVP_BIT_COMBO and DIAMETER_INVALID_AVP_BITS. DIAMETER_INVALID_AVP_BIT_COMBO is either in the wrong category or redundant. DIAMETER_INVALID_BIT_IN_HEADER and DIAMETER_INVALID_MESSAGE_LENGTH could be considered protocol errors as well ? DIAMETER_COMMAND_UNSUPPORTED and DIAMETER_INVALID_AVP_BITS should be moved to permanent failure category ? Related to end-to-end behavior Proposed Solution ?

IETF66 DIME WG Issue 10: Unclear semantics with multiple Vendor-Id avp’s in Vendor-Specific-Application-Id Issue: Unclear why the ABNF of Vendor-Specific-Application-Id would specify more than one Vendor-Id avp instance Proposed Solution: Vendor-Id ABNF should be change to “0*1 [Vendor-Id]”

IETF66 DIME WG Issue 20: Determining an offending/invalid AVP contained within a grouped AVP Issue: In the case of a Grouped AVP which contains more than one information element, it would be hard to guess which AVP has caused the problem if the Failed-AVP only refers to a problem in the Grouped AVP. Proposed Solution: Extend the definition of Failed-AVP to somehow provide inheritance information of each offending avp belonging to a group ?

IETF66 DIME WG Issue 8: Setting error flag (E-bit) during a CER/CEA exchange Issue: CER/CEA exchange resulting in an error should not require the E-bit to be set since the CER/CEA message and semantics of the exchange is well defined A good example is DIAMETER_UNKNOWN_PEER. Sending a CEA with this Result-Code is optional, but if an implementation does so, it also has to set the E-bit, which doesn't make much sense. Proposed Solution ?

IETF66 DIME WG Issue 12: Differing concept and/or usage of Diameter Identity (FQDN + port or FQDN only) Issue: Misleading concepts and or usage of Diameter Identity. One usage is FQDN for indexing in the peer table. Another is FQDN+port (+more) in redirect URI. Can we clarify the behavior ? Proposed Solution ?

IETF66 DIME WG Issue 14: Explicit specification on which error class should have the error flag (E-bit) set Issue: Sec contains a sentence “Note that these and only these errors MUST only be used in answer messages whose 'E' bit is set.” Standards left it open, what error classes have to use “E-bit”, i.e. have to use error message instead of answer Proposed Solution: Explicitly specify whether the E-bit should be set for each error class

IETF66 DIME WG Issue 17: Removal of trailing [*fixed] avp in Sec 3.2 Issue: Un-necessary trailing [*fixed] ABNF for the diameter-message definition in the command code specification in Sec Proposed Solution: Change the diameter-message definition in Sec 3.2 to: diameter-message = header [*fixed] [*required] [*optional]

IETF66 DIME WG Issue 18: Clarify re-connect behavior of peer based on value of Disconnect-Cause AVP Issue: Is there a need for clarifying the mapping between the value of Disconnect-Cause AVP and expected behavior ? Which values of Disconnect-Cause AVP will provide a hint to the receiver of the DPR that it may or may not reconnect ? Example: REBOOTING will hint on eventual reconnection attempt. BUSY or DONT_WANT_TO_TALK_TO_YOU implies do not reconnect. Proposed Solution ?

IETF66 DIME WG Issue 22: Fetch Data Request & Location Update Request Issue (feature): It would be good to have messages like Fetch data request which allow peers to fetch data from a AAA. Also Location Update Requests which allow peers to update the location of (lets say mobile clients) to the AAA. Instead of each application defining these messages over and over again, it would be good to have it in the Base. Comments ?

IETF66 DIME WG Issue 23: P redictive Loop Detection Issue (feature): Loop detection could be optimized by a node checking the list of route-records before forwarding to see if the next-hop selected is in the list or not. If yes, loop could be avoided, instead of detected. As of now, the check happens after its forwarded, in the node, the node checks the list of route-records to see if "my name is in here or not". Comments ?

IETF66 DIME WG Summary (1/2) Issue 1: Advertising relay id in Auth-Application-id or Acct- Application-id Issue 2 and 5: Application id to be used by common diameter messages (ASR/ASA, STR/STA etc) Issue 3 and 16: CER/CEA exchange in open state Issue 4: Proxy staying in the path of the request messages of a session Issue 8: Setting error flag (E-bit) during a CER/CEA exchange Issue 9 and 19: Error codes defined in the wrong categories Issue 10: Unclear semantics with multiple Vendor-Id avp’s in Vendor-Specific-Application-Id Issue 11: Proxy-Info AVP not being returned in the answer message Issue 12: Differing concept and/or usage of Diameter Identity (FQDN + port or FQDN only)

IETF66 DIME WG Summary (2/2) Issue 13: Clarify the usage of application id avp’s (Auth-Application- Id, Acct-Application-Id etc) and how they relate to the application id in the message header Issue 14: Explicit specification on which error class should have the error flag (E-bit) set Issue 15: Duplicate detection requires server side storage of E2E-Id and Origin-Host Issue 17: Removal of trailing [*fixed] avp in Sec 3.2 Issue 18: Clarify re-connect behavior of peer based on value of Disconnect-Cause AVP Issue 20: Determining an offending/invalid AVP contained within a grouped AVP Issue 22: Fetch Data Request & Location Update Request Issue 23: Predictive Loop Detection