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

[<[e-mail]>]

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:[e-mail]] De la part de Jouni Korhonen
Envoyé : vendredi 27 mars 2015 19:25
À : Henrik Villför
Cc : [e-mail]
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:
> 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 <[e-mail]
> <mailto:[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 <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:
>        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 <http://node.domainexample.com>.
>
>
>     Irrespective of my above rant, I agree.
>
>         This should not be allowed:
>
>         Origin-Realm: realmexample.com <http://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> <http://example.com>"
>         with a transport connection with the peer
>         "node.site1.example.com <http://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>
>         <mailto:dime-bounces <mailto:dime-bounces>> at ietf.org
>         <http://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> <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> 
> <http://example.com>
>
>         Origin-Host: node.example.com <http://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> 
> <http://example.com>
>
>         Origin-Host: node.site1.example.com
>         <http://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>
>         <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] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/__listinfo/dime
>         <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.