John Loughney, Hannes Tschofenig and Victor Fajardo

1
3588-bis Current Issues

• John Loughney, Hannes Tschofenig and Victor
  Fajardo

2

• Overview
• Currently 20 Issues present in the tracker
  (http//www.tschofenig.com8080/diameter-interop/)
  
• Majority of the issues generated during the last
  interop event (Week of April 24th)

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

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 ?

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

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 ?

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 ?

8

• Issue 13 Clarify the usage of application id
  avps (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
  avps of the message ?
• Do the header and AVP values always have to
  match? If not, what does it mean.
• Proposed Solution ?

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_BI
  T_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 ?

10

• Issue 10 Unclear semantics with multiple
  Vendor-Id avps in Vendor-Specific-Application-Id
• Issue
• Unclear why the ABNF of Vendor-Specific-Applicati
  on-Id would specify more than one Vendor-Id avp
  instance
• Proposed Solution
• Vendor-Id ABNF should be change to 01
  Vendor-Id

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 ?

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 ?

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 FQDNport (more) in
  redirect URI. Can we clarify the behavior ?
• Proposed Solution ?

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

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

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_T
  O_YOU implies do not reconnect.
• Proposed Solution ?

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 ?

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 ?

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 avps 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)

20

• Summary (2/2)
• Issue 13 Clarify the usage of application id
  avps (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