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

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