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

[Lars Jørgen Lillehovde <[e-mail]>]

Hi,

I've noticed a multitude of strange behavior from diameter products related
to naming. E.g. the issue of Origin-Host has to be in the format of
'host.realm' as mention in my initial post or diameter nodes requiring all
Destination-Host to be resolvable in DNS. These examples are not from
diameter products from small vendors.

Perhaps this is something that should be considered clarified in a future
Diameter standard. There could be advantages by having all the naming
related requirements in a single section. Also, more advanced examples of
allowed and disallowed naming could be a good idea as the current examples
in the RFCs are very basic.


Lars J. Lillehovde


Date: Thu, 2 Apr 2015 06:58:19 +0000
From: John Basha <[e-mail]>
To: Dave Dolson <[e-mail]>, Jouni Korhonen
        <[e-mail]>, "[e-mail]"
        <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Dime] realm vs domain (was: Allowed host and realm
        naming for a diameter node)
Message-ID:
        <[e-mail]>
Content-Type: text/plain; charset="utf-8"

I go with Dave here. I have seen many implementations where we do not put
any restriction on deciding the host or realm names like the way it is
mentioned below.

It has been decided by operators based on the domain name they have.

I go with Dave here. I have seen many implementations where we do not
put any restriction on deciding the host or realm names like the way
it is mentioned below.

It has been decided by operators based on the domain name they have.


-----Original Message-----
From: DiME [mailto:dime-bounces <dime-bounces> at ietf.org] On Behalf
Of Dave Dolson
Sent: Thursday, April 02, 2015 12:18 AM
To: Jouni Korhonen; lionel.morand at orange.com
Cc: dime at ietf.org
Subject: Re: [Dime] realm vs domain (was: Allowed host and realm
naming for a diameter node)

In our implementation, we do not place these kinds of constraints on
host or realm names. It is the operator's choice as to whether or not
host and realm match DNS names.
When all Diameter connections are pre-configured, there is no need for
dynamic connection to a new agent by resolving hosts in DNS.


-----Original Message-----
From: DiME [mailto:dime-bounces <dime-bounces> at ietf.org] On Behalf
Of Jouni Korhonen
Sent: Wednesday, April 01, 2015 4:11 PM
To: lionel.morand at orange.com
Cc: dime at ietf.org
Subject: Re: [Dime] realm vs domain (was: Allowed host and realm
naming for a diameter node)

I do not quite agree on your described use of DiameterIdentities - the
part of using different domain part. It would be great to hear from
implementations whether they are able to cope with that or not before
going any further.

- Jouni

4/1/2015, 10:49 AM, lionel.morand at orange.com kirjoitti:
> If the FQDN is used as x-Realm AVP, the host MUST be anyway defined as an absolute domain name under the realm normally used as x-realm value ad registered in the DNS (or configured in the receiving Diameter nodes). Otherwise, the routing will fail.
> Even in this (weird) case, the FQDN may be defined in a subdomain of
> domain name of the x-Realm AVP value expected in the Diameter messages
> (cf. initial question)
>
> Now, when FQDN are ONLY used for x-Host AVP values (as it should be), there is no limitation regarding the domain name used for the x-Host AVP and for the x-Realm AVP value. For instance, this provides flexibility for the naming of the diameter nodes in the internal network (that can used a private naming plane) while ensuring consistency on the domain name used by external networks (using a standard naming plane).
>
> Lionel
>
> -----Message d'origine-----
> De : Jouni Korhonen [mailto:jouni.nospam <jouni.nospam> at gmail.com] Envoyé : mercredi
> 1 avril 2015 16:48 À : MORAND Lionel IMT/OLN Cc : Henrik Villför;
> dime at ietf.org Objet : Re: [Dime] realm vs domain (was: Allowed host
> and realm naming for a diameter node)
>
> You still need to care for implementations that do put FQDN into Origin-Realm (or Destination-Realm).
>
> - Jouni
>
> 4/1/2015, 2:12 AM, lionel.morand at orange.com kirjoitti:
>> Hi Jouni,
>>
>> Some magic might exist somewhere to fix some weird implementation,
>> for sure. But the RFC6733 was actually meant to fix in a generic way
>> those issues. Therefore, if someone comes to say that using FQDN as
>> realm is correct according to RFC3588, I would only say "please refer
>> to the
>> RFC6733 to see what should be the correct implementation of the base
>> protocol" :)
>>
>> Lionel
>>
>> -----Message d'origine-----
>> De : Jouni.nosmap [mailto:jouni.nospam <jouni.nospam> at gmail.com] Envoyé : mardi 31
>> mars 2015 21:06 À : MORAND Lionel IMT/OLN Cc : Henrik Villför;
>> dime at ietf.org Objet : Re: [Dime] realm vs domain (was: Allowed host
>> and realm naming for a diameter node)
>>
>>
>>
>> Sent from a smart phone.. Mind the typos..
>>
>>> <lionel.morand at orange.com> <lionel.morand at orange.com> kirjoitti 31.3.2015 kello 10.41:
>>>
>>> Hi,
>>>
>>> Please see below.
>>>
>>> Lionel
>>>
>>> -----Message d'origine-----
>>> De : DiME [mailto:dime-bounces <dime-bounces> at ietf.org] De la part de Jouni
>>> Korhonen Envoyé : jeudi 26 mars 2015 06:07 À : Henrik Villför;
>>> dime at ietf.org Objet : Re: [Dime] realm vs domain (was: Allowed host
>>> and realm naming for a diameter node)
>>>
>>> Hi,
>>>
>>> 3/25/2015, 1:18 AM, Henrik Villför kirjoitti:
>>>> 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
>>>
>>> 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..
>>>
>>> [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.
>>
>> 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.
>>
>>>
>>>     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.
>>
>> I would bet there is stuff out there..
>>
>> - jouni
>>
>>
>>>
>>>> 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.
>>>
>>>> So, this should be allowed:
>>>>
>>>> Origin-Host: node.domainexample.com.
>>>
>>> Irrespective of my above rant, I agree.
>>>
>>>> This should not be allowed:
>>>>
>>>> Origin-Realm: realmexample.com.
>>>
>>> Agree (since the example shows a realm).
>>>
>>> - Jouni
>>>
>>>> (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 <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 <dime-bounces> <mailto:dime-bounces <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
>>>> : [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 <http://example.com>
>>>>
>>>> Origin-Host: node.example.com <http://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 <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
>>>>
>>>> ___________________________________________________________________
>>>> _ _ _ ___________________________________________________
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME at ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>>> ____________________________________________________________________
>>> _ _ ___________________________________________________
>>>
>>> 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.
>>>
>>
>> _____________________________________________________________________
>> _ ___________________________________________________
>>
>> 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.
>>
>
> ______________________________________________________________________
> ___________________________________________________
>
> 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.
>