1 / 20

3588-bis: Current Issues

3588-bis: Current Issues. John Loughney, Hannes Tschofenig and Victor Fajardo. Overview Currently 20 Issues present in the tracker ( http://www.tschofenig.com:8080/diameter-interop/ ) Majority of the issues generated during the last interop event (Week of April 24 th ).

gerda
Download Presentation

3588-bis: Current Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Overview • Currently 20 Issues present in the tracker (http://www.tschofenig.com:8080/diameter-interop/) • Majority of the issues generated during the last interop event (Week of April 24th) IETF66 DIME WG

  3. 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

  4. 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

  5. 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

  6. 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

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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. Issue 14: Explicit specification on which error class should have the error flag (E-bit) set • Issue: • Sec 7.1.3 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

  15. 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. 3.2. Proposed Solution: • Change the diameter-message definition in Sec 3.2 to: • diameter-message = header [*fixed] [*required] [*optional] IETF66 DIME WG

  16. 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

  17. 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

  18. Issue 23: Predictive 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

  19. 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

  20. 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 IETF66 DIME WG

More Related