Subject: [Dime] Use of Origin-Host

From: jouni korhonen <[email-masked]>
Date: Sun, 10 Apr 2011 18:36:26 +0300

Hi,

As discussed briefly during Prague Dime meeting, here is background about the changing Origin-Host.

One interpretation of RFC3588(bis) is that the DiameterIdentity in the Origin-Host AVP received in a CER/CEA must equal to the DiameterIdentity in Origin-Host AVP for every request message the same Diameter node originates over the same transport connection. This is not explicit in RFC3588(bis). RFC3588 Section 4.3 says a Diameter node can have multiple DiameterIdentities but a single identity should be selected when the Diameter node starts. Note the 'should' here, which is not RFC2119 language 'SHOULD' and even if it were it is not a 'MUST' or 'SHALL’. Because a Diameter node has really no other way to learn the DiameterIdentity of its peer, it uses the Origin-Host AVP received in the CER/CEA message as stated in Section 5.6.1.

What we have observed in the field is that some Diameter peers change their identity spontaneously. This would not be an issue if the peer were a proxy or a relay. However, there are peers that are 1) directly connected and 2) change their DiameterIdentity in the Origin-Host to something else what they claimed during CER/CEA exchange. Regarding 1) the requests with changed identity are not proxied/relayed i.e. they do not include any routing AVPs and especially no Route-Record AVP. This is clearly a violation of RC3588(bis). Usually this still happens to work out as the answer follows hop-by-hop identifiers rather than Origin-Host & Origin-Realm. However, problems arise when a peer that originally received a request with changed DiameterIdentity sends a request (like ASR or alike) later on using the "cached identity" from the previous message exchange (and there is no authorization state maintained). Now the changed identity cannot be found from the peer table. One could fall back to realm based routing and get the message delivered but still this not "as it should be based on RFC3588" and may also lead to unwanted routing paths.

Should we make Section 4.3 text explicit: “If a Diameter node can be identified by several FQDNs, a single FQDN MUST be picked at startup, and used as the only DiameterIdentity for that node, whatever the connection it is sent on.” ??! 

- Jouni