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

[Jouni Korhonen <[e-mail]>]

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