Subject: [Dime] realm vs domain (was: Allowed host and realm naming for a diameter node)

From: Henrik Villför <[email-masked]>
Date: Wed, 25 Mar 2015 09:18:35 +0100

Hi,

  a follow up on the question below.

Is there anything in the base specification requiring the realm in the
Origin-Realm AVP to be the same as the domain part of the Origin-Host AVP?

Would the following be allowed?

Origin-Realm: realmexample.com

Origin-Host: node.domainexample.com

Also, although none of the examples of Diameter host identities in rfc 6733
show an FQDN with a trailing dot it should be allowed, but a realm may not
end in a dot.

So, this should be allowed:

Origin-Host: node.domainexample.com.

This should not be allowed:

Origin-Realm: realmexample.com.

(Sorry about the ugly cut'n'paste. Just joined the list and found the
recent post below in the archive.)

Best Regards,

Henrik Villför

---------

Hi Lars,

According to the base protocol, there is no such restriction. When the
DiameterIdentity format is used to identify a Diameter node, the only
requirement is that:

* the DiameterIdentity value in Origin/Destination-Host AVP is an FQDN.

* there is at least one peer table in the realm identified by the
Origin/Destination-Realm  AVP that contains the host identified by the FQDN.

So Example 2 is perfectly valid from a base protocol point of view, as long
as there is at least one node in "example.com" with a transport connection
with the peer "node.site1.example.com".

Now, some Diameter applications may have defined specific rules regarding
the format of realm/host identity, with explicit restrictions/limitations.
It is then required to check if there is any of these restrictions defined
in the related specification.

Regards,

Lionel

De : DiME [mailto:dime-bounces at ietf.org] De la part de Lars Jørgen
Lillehovde Envoyé : dimanche 15 mars 2015 12:54 À : dime at ietf.org Objet
: [Dime] Allowed host and realm naming for a diameter node

Hi,

I'm trying to clarify the allowed naming convension for the host and realm
of a diameter node. This relates to the values used in the Origin-Host AVP
(AVP Code 264) and Origin-Realm AVP (AVP Code 296). I've reviewed the
Diameter RFCs and cannot find a definitive answer to this issue.

The reason for asking this question is that I'm in discussion with a vendor
of a Diameter Routing Agent (DRA) which claims that the host of a diameter
node has to be in the format host.realm.

(1) Example of the only allowed format according to the vendor:

Origin-Realm: example.com

Origin-Host: node.example.com

I want to clarify if multiple subdomains are allowed to be added in the
host without being present in the realm.

(2) Example:

Origin-Realm: example.com

Origin-Host: node.site1.example.com

According to the vendor, the example 2 is not allowed. To have the host as
in example 2, the realm will have to be site1.example.com.

Could someone please clarify this naming issue or point me to the standard
where this is defined.

Thank you.

Best regards,

Lars J. Lillehovde

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.

If you have received this email in error, please notify the sender and
delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.

Thank you.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 25 Mar 2015 22:07:11 -0700

Hi,

> Origin-Host: node.domainexample.com

Based on my reading of RFC6733 yes.. but when reading RFC3588 no'ish. 
The subttle change between these two was:

OLD:
   DiameterIdentity  = FQDN
NEW:
   DiameterIdentity  = FQDN/Realm

And when reading the text on a DiameterIdentity a Diameter node _should_ 
(ok.. the should is not must..) only use one DiameterIdentity which 
means the FQDN in Origin-Host and Origin-Realm should be the same..

> Also, although none of the examples of Diameter host identities in rfc
> 6733 show an FQDN with a trailing dot it should be allowed, but a realm
> may not end in a dot.

AFAIR the FQDN first appeared in RFC1206.. none of the FQDN examples use 
the trailing ".". Anyway, referring to RFC1034 and the "relative names" 
it is stated that:

--
Relative names are either taken relative to a well known origin, or to a
list of domains used as a search list.  Relative names appear mostly at
the user interface, where their interpretation varies from
implementation to implementation, and in master files, where they are
relative to a single origin domain name.  The most common interpretation
uses the root "." as either the single origin or as one of the members
of the search list, so a multi-label relative name is often one where
the trailing dot has been omitted to save typing.
--

Thus it is expected that the resolver library (or equivalent) knows when 
to add the missing "." e.g. when the domain name is supposed to be a 
DiameterIdentity.

> Origin-Host: node.domainexample.com.

Irrespective of my above rant, I agree.

> Origin-Realm: realmexample.com.

Agree (since the example shows a realm).

- Jouni

> So Example 2 is perfectly valid from a base protocol point of view, as
> long as there is at least one node in "example.com <http://example.com>"
> with a transport connection with the peer "node.site1.example.com
> <http://node.site1.example.com>".
>
> Now, some Diameter applications may have defined specific rules
> regarding the format of realm/host identity, with explicit
> restrictions/limitations. It is then required to check if there is any
> of these restrictions defined in the related specification.
>
> Regards,
>
> Lionel
>
> De : DiME [mailto:dime-bounces <mailto:dime-bounces> at ietf.org
> <http://ietf.org>] De la part de Lars Jørgen Lillehovde Envoyé :
> dimanche 15 mars 2015 12:54 À : dime at ietf.org <http://ietf.org> Objet
> I'm trying to clarify the allowed naming convension for the host and
> realm of a diameter node. This relates to the values used in the
> Origin-Host AVP (AVP Code 264) and Origin-Realm AVP (AVP Code 296). I've
> reviewed the Diameter RFCs and cannot find a definitive answer to this
> issue.
>
> The reason for asking this question is that I'm in discussion with a
> vendor of a Diameter Routing Agent (DRA) which claims that the host of a
> diameter node has to be in the format host.realm.
>
> Origin-Realm: example.com <http://example.com>
>
> Origin-Host: node.example.com <http://node.example.com>
>
> Origin-Realm: example.com <http://example.com>
>
> Origin-Host: node.site1.example.com <http://node.site1.example.com>
>
> According to the vendor, the example 2 is not allowed. To have the host
> as in example 2, the realm will have to be site1.example.com
> <http://site1.example.com>.
>
> Could someone please clarify this naming issue or point me to the
> standard where this is defined.
>
> Thank you.
>
> Best regards,
>
> Lars J. Lillehovde
>
> pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
>
> information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
>
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
>
> Thank you.
>
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Henrik Villför <[email-masked]>
Date: Fri, 27 Mar 2015 09:02:05 +0100

Thank you Jouni,
I interpret your answer to say that from a standards and functional point
of view the Origin-realm and the domain part of the Origin-host may differ
but for (backward) compatibility reasons it is a good idea to keep them the
same.

Correct?

Regards,
Henrik

2015-03-26 6:07 GMT+01:00 Jouni Korhonen <[email-masked]>:

> Based on my reading of RFC6733 yes.. but when reading RFC3588 no'ish. The
> subttle change between these two was:
>
> OLD:
>   DiameterIdentity  = FQDN
> NEW:
> (ok.. the should is not must..) only use one DiameterIdentity which means
> the FQDN in Origin-Host and Origin-Realm should be the same..
>
> the trailing ".". Anyway, referring to RFC1034 and the "relative names" it
> is stated that:
>
> --
>> ____________________________________________________________
>> _____________________________________________________________
>>

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 27 Mar 2015 11:25:07 -0700

Hi,

3/27/2015, 1:02 AM, Henrik Villför kirjoitti:
> Thank you Jouni,
> I interpret your answer to say that from a standards and functional
> point of view the Origin-realm and the domain part of the Origin-host
> may differ but for (backward) compatibility reasons it is a good idea to
> keep them the same.
>
> Correct?

Yes'ish.. and to my best collective memory of Diameter it was never 
intended that these two would have non-overlapping domain parts.

- Jouni

>
> Regards,
> Henrik
>
>
>
> 2015-03-26 6:07 GMT+01:00 Jouni Korhonen <[email-masked]
> <mailto:[email-masked]>>:
>
>     Hi,
>
>         Origin-Realm: realmexample.com <http://realmexample.com>
>
>         Origin-Host: node.domainexample.com <http://node.domainexample.com>
>
>
>     Based on my reading of RFC6733 yes.. but when reading RFC3588
>     no'ish. The subttle change between these two was:
>
>     OLD:
>        DiameterIdentity  = FQDN
>     NEW:
>     And when reading the text on a DiameterIdentity a Diameter node
>     _should_ (ok.. the should is not must..) only use one
>     DiameterIdentity which means the FQDN in Origin-Host and
>     Origin-Realm should be the same..
>
>     AFAIR the FQDN first appeared in RFC1206.. none of the FQDN examples
>     use the trailing ".". Anyway, referring to RFC1034 and the "relative
>     names" it is stated that:
>
>     --
>     Thus it is expected that the resolver library (or equivalent) knows
>     when to add the missing "." e.g. when the domain name is supposed to
>     be a DiameterIdentity.
>
>         Origin-Host: node.domainexample.com <http://node.domainexample.com>.
>
>
>         Origin-Realm: realmexample.com <http://realmexample.com>.
>
>
>         long as there is at least one node in "example.com
>         <http://example.com> <http://example.com>"
>         with a transport connection with the peer
>         "node.site1.example.com <http://node.site1.example.com>
>         <http://node.site1.example.com__>".
>
>         De : DiME [mailto:dime-bounces <mailto:dime-bounces>
>         <mailto:dime-bounces <mailto:dime-bounces>> at ietf.org
>         <http://ietf.org>
>         dimanche 15 mars 2015 12:54 À : dime at ietf.org
>         <http://ietf.org> <http://ietf.org> Objet
>         Origin-Realm: example.com <http://example.com> <http://example.com>
>
>         <http://node.example.com>
>
>         Origin-Realm: example.com <http://example.com> <http://example.com>
>
>         <http://node.site1.example.com> <http://node.site1.example.com__>
>
>         <http://site1.example.com>
>         _________________________________________________________________________________________________________________________________
>
>         _________________________________________________
>         DiME mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/dime
>         <https://www.ietf.org/mailman/listinfo/dime>
>
>

---

From: Iliya Peregoudov <[email-masked]>
Date: Mon, 30 Mar 2015 10:08:50 +0300

> intended that these two would have non-overlapping domain parts.

According to Base Diameter requests are routed by Destination-Realm and 
application. Destination-Host is not used in routing. Destination-Host 
is only used in "last hop" forwarding, when peer is selected by 
Destination-Host. So I think for Destination-Host it is sufficient to be 
unique within destination realm.

What do you think about "loopback host identity" technique? I mean 
identity that is not announced in capability exchange with peers, but 
used by Diameter applications. For example two Diameter nodes that 
announce "ocs1" and "ocs2" host identities to peers, but use single 
"ocs" host identity in credit-control application. (Of course such 
Diameter nodes should use shared backend database that will store all 
session-level application state.) Does it contradicts with Base Diameter 
and/or credit-control application? I don't think so. What do you think?

This technique can be directly compared with IP anycast technique.

---

From: <[email-masked]>
Date: Tue, 31 Mar 2015 17:41:05 +0000

Hi,

Please see below.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Jouni Korhonen
Envoyé : jeudi 26 mars 2015 06:07
À : Henrik Villför; [email-masked]
Objet : Re: [Dime] realm vs domain (was: Allowed host and realm naming for a diameter node)

Hi,

OLD:
   DiameterIdentity  = FQDN
NEW:

And when reading the text on a DiameterIdentity a Diameter node _should_ (ok.. the should is not must..) only use one DiameterIdentity which means the FQDN in Origin-Host and Origin-Realm should be the same..
 
[LM]> not sure to understand what the text above means. In RFC3588, the definition in sect 4.3 was clearly an error as the text in sect 6.4 sect 6.6 was already saying that:

   The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity.
   This AVP contains the Realm of the originator of any Diameter message
   and MUST be present in all messages.

   The Destination-Realm AVP (AVP Code 283) is of type DiameterIdentity,
   and contains the realm the message is to be routed to.

[LM]> So a DiameterIdentity was meant to be either an FQDN or a Realm, depending of its use as x-Host or x-Realm AVP value. If someone was implementing the Diameter identity of a realm as an FQDN, it would be an error. And this was fixed with RFC6733.

> 6733 show an FQDN with a trailing dot it should be allowed, but a 
> realm may not end in a dot.

AFAIR the FQDN first appeared in RFC1206.. none of the FQDN examples use the trailing ".". Anyway, referring to RFC1034 and the "relative names" 
it is stated that:

--
Relative names are either taken relative to a well known origin, or to a list of domains used as a search list.  Relative names appear mostly at the user interface, where their interpretation varies from implementation to implementation, and in master files, where they are relative to a single origin domain name.  The most common interpretation uses the root "." as either the single origin or as one of the members of the search list, so a multi-label relative name is often one where the trailing dot has been omitted to save typing.
--

Thus it is expected that the resolver library (or equivalent) knows when to add the missing "." e.g. when the domain name is supposed to be a DiameterIdentity.

- Jouni

> Origin-Host AVP (AVP Code 264) and Origin-Realm AVP (AVP Code 296). 
> I've reviewed the Diameter RFCs and cannot find a definitive answer to 
> this issue.
>
> vendor of a Diameter Routing Agent (DRA) which claims that the host of 
> a diameter node has to be in the format host.realm.
>
> I want to clarify if multiple subdomains are allowed to be added in 
> the host without being present in the realm.
>
> (2) Example:
>
> According to the vendor, the example 2 is not allowed. To have the 
> host as in example 2, the realm will have to be site1.example.com 
> ______________________________________________________________________
> ___________________________________________________
>
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
>

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Tue, 31 Mar 2015 17:49:13 +0000

Hi,

As said in another mail, from my understanding, at the protocol level, the only restriction is that the x-Host AVP uniquely identifies a peer in the peer table of a node of the realm identified by the x-Realm AVP.
From an operational point of view, it is more than likely that the FQDN will be part of the realm identified in the x-Realm AVP. But this is not deemed mandatory to ensure a successful request routing, as long as there is at least one peer in the given realm as transport connection open with the peer identified in the x-Host AVP whatever the realm it belongs to.

And there is no compatible issue here from my point of view.

regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Jouni Korhonen
Envoyé : vendredi 27 mars 2015 19:25
À : Henrik Villför
Cc : [email-masked]
Objet : Re: [Dime] realm vs domain (was: Allowed host and realm naming for a diameter node)

Hi,

3/27/2015, 1:02 AM, Henrik Villför kirjoitti:
> may differ but for (backward) compatibility reasons it is a good idea 
> to keep them the same.
>
> Correct?

Yes'ish.. and to my best collective memory of Diameter it was never intended that these two would have non-overlapping domain parts.

- Jouni

> <http://node.domainexample.com>
>
>
> <http://example.com>
> <http://example.com>
> ___________________________________________________________
>
>         privileged

---

From: "Jouni.nosmap" <[email-masked]>
Date: Tue, 31 Mar 2015 12:06:04 -0700

Sent from a smart phone.. Mind the typos..

> <[email-masked]> <[email-masked]> kirjoitti 31.3.2015 kello 10.41:
> 
> Hi,
> 
> Please see below.
> 
> Lionel
> 

We need to remembet that with Diameter realm is piggybacked in DNS. So if your Origin-Realm is an FQDN and you just extract the domain part of it when using it, you achieved the same as realm. This to work properly requires some magic sauce.. which e.g. for certain deployments is described in system specific specs. 

> [LM]> So a DiameterIdentity was meant to be either an FQDN or a Realm, depending of its use as x-Host or x-Realm AVP value. If someone was implementing the Diameter identity of a realm as an FQDN,…

I would bet there is stuff out there.. 

- jouni