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

["Jouni.nosmap" <[e-mail]>]

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

> <[e-mail]> <[e-mail]> kirjoitti 31.3.2015 kello 10.41:
> 
> Hi,
> 
> Please see below.
> 
> Lionel
> 
> -----Message d'origine-----
> De : DiME [mailto:[e-mail]] De la part de Jouni Korhonen
> Envoyé : jeudi 26 mars 2015 06:07
> À : Henrik Villför; [e-mail]
> 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 <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
>> : [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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> 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.
>