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

[Henrik Villför <[e-mail]>]

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 <[e-mail]>:

> 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..
>
>  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
>>
>>