Subject: [Dime] Problem with Origin- & Destination-Realm AVPs in RFC3588bis

From: "Glen Zorn" <[email-masked]>
Date: Wed, 4 Mar 2009 04:18:45 +0700

I'm pretty sure that I've mentioned this before, but the problematic
definitions remain.  The Origin-Realm & Destination-Realm AVPs are specified
to be of type DiameterIdentity.  This is plainly wrong, since
DiameterIdentity is defined as an FQDN which is NOT the same as a Diameter
realm.  I think that it is _very_ important to fix this error in RFC 3588,
rather than perpetuating it.

~gwz

Play assigns meaning to human activity--work erases it.
  -- P.L. Wilson

---

From: Fortune HUANG <[email-masked]>
Date: Wed, 04 Mar 2009 11:06:06 +0800

Hi Glen,

I would like to support your proposal.
Maybe we can simply define the realm AVPs to be of type OctetString with the
detailed description of the format, or we can derive a new Derived AVP Data
Format for the realm AVPs.
The latter would be my preference since realm is a very important concept
and realm AVPs are used everywhere in Diameter.

Best Regards,
Fortune

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen
Zorn
Sent: Wednesday, March 04, 2009 5:19 AM
To: [email-masked]
Subject: [Dime] Problem with Origin- & Destination-Realm AVPs in RFC3588bis

~gwz

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Wed, 4 Mar 2009 10:57:06 +0100

Hi,

Could it be "simply" solved by modifying the definition of the DiameterIdentity format to reflect that it can be either an FQDN or a realm?

Something like:

   DiameterIdentity
      The DiameterIdentity format is derived from the OctetString AVP
      Base Format.

         DiameterIdentity  = FQDN/realm

      DiameterIdentity value is used to identify:
      - either a Diameter node for purposes of duplicate connection and
        routing loop detection.
      - either a realm to determine whether messages can be satisfied 
        locally, or whether they must be routed or redirected. 

      When the DiameterIdentity is used to identify a Diameter node,
      the contents of the string MUST be the FQDN of the Diameter node.
      If multiple Diameter nodes run on the same host, each Diameter
      node MUST be assigned a unique DiameterIdentity.  If a Diameter
      node can be identified by several FQDNs, a single FQDN should be
      picked at startup, and used as the only DiameterIdentity for that
      node, whatever the connection it is sent on.

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Glen Zorn
> Envoyé : mardi 3 mars 2009 22:19
> À : [email-masked]
> Objet : [Dime] Problem with Origin- & Destination-Realm AVPs 
> in RFC3588bis
> 
> I'm pretty sure that I've mentioned this before, but the 
> problematic definitions remain.  The Origin-Realm & 
> Destination-Realm AVPs are specified to be of type 
> DiameterIdentity.  This is plainly wrong, since 
> DiameterIdentity is defined as an FQDN which is NOT the same 
> as a Diameter realm.  I think that it is _very_ important to 
> fix this error in RFC 3588, rather than perpetuating it.
> 
> ~gwz
>

---

From: <[email-masked]>
Date: Wed, 4 Mar 2009 14:21:29 +0100

I'm not sure to understand but I might have missed something.
>From a syntax point of view, what is the difference between a FQDN and a realm?
What would be the "potential" impacts to say that the DiameterIdentity can be a FQDN or a realm?

Lionel

> De : Fortune HUANG [mailto:[email-masked]] 
> Envoyé : mercredi 4 mars 2009 13:14
> À : MORAND Lionel RD-CORE-ISS; [email-masked]; [email-masked]
> Objet : RE: [Dime] Problem with Origin- & Destination-Realm 
> AVPs in RFC3588bis
> 
> Hi Lionel,
> 
> Your proposal could probably work, but might challenge the 
> Diameter parser if a strict check on the data format is needed.
> Also, it would be inconvenient for us to apply the 
> DiameterIdentity type to a AVP, we would also need to specify 
> the sub-type (FQDN or realm) in addition to the specification 
> of type DiameterIdentity, or else it would be not clear 
> enough for the definition of a AVP.
> 
> Best Regards,
> Fortune
> 
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Wednesday, March 04, 2009 5:57 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Dime] Problem with Origin- & Destination-Realm 
> AVPs in RFC3588bis
> 
> Hi,
> 
> Could it be "simply" solved by modifying the definition of 
> the DiameterIdentity format to reflect that it can be either 
> an FQDN or a realm?
> 
> Something like:
> 
>    DiameterIdentity
> > De : [email-masked] [mailto:[email-masked]] 
> De la part 
> > de Glen Zorn Envoyé : mardi 3 mars 2009 22:19 À : 
> [email-masked] Objet 
> > : [Dime] Problem with Origin- & Destination-Realm AVPs in RFC3588bis
> > 
> problematic 
> > definitions remain.  The Origin-Realm & Destination-Realm AVPs are 
> > specified to be of type DiameterIdentity.  This is plainly wrong, 
> > since DiameterIdentity is defined as an FQDN which is NOT 
> the same as 
> > a Diameter realm.  I think that it is _very_ important to fix this 
> > error in RFC 3588, rather than perpetuating it.
> > 
> > ~gwz
> >

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 04 Mar 2009 17:02:25 -0500

Hi Fortune,
> What would be the "potential" impacts to say that the DiameterIdentity can be a FQDN or a realm?
I have the same question as Lionel. Syntactically, FQDN and realm are 
the same from the parsers point of view. The difference is in semantics 
which is already specified by the AVP having that type.

regards,
victor

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 4 Mar 2009 15:15:57 -0800

Victor Fajardo [mailto:[email-masked]] writes:

> > What would be the "potential" impacts to say that the
> DiameterIdentity can be a FQDN or a realm?
> >
> the same from the parsers point of view. 

Yes.

> The difference is in semantics

???

---

From: Fortune HUANG <[email-masked]>
Date: Thu, 05 Mar 2009 10:46:12 +0800

Hi all,

In section 1.3 of 3588bis, 
"Realm

      The string in the NAI that immediately follows the '@' character.
      NAI realm names are required to be unique, and are piggybacked on
      the administration of the DNS namespace.  Diameter makes use of
      the realm, also loosely referred to as domain, to determine
      whether messages can be satisfied locally, or whether they must be
      routed or redirected.  In RADIUS, realm names are not necessarily
      piggybacked on the DNS namespace but may be independent of it.
"
So I think the format of realm shoud be compliant with RFC4282.

In section 2.1 of RFC4282, the grammar for the realm is  an updated version
of [RFC1035].
"
realm       =  1*( label "." ) label
label       =  let-dig *(ldh-str)
ldh-str     =  *( alpha / digit / "-" ) let-dig
let-dig     =  alpha / digit
alpha       =  %x41-5A  ; 'A'-'Z'
alpha       =/ %x61-7A  ; 'a'-'z'
digit       =  %x30-39  ; '0'-'9'
"
In section 9 of RFC4566
"FQDN =                4*(alpha-numeric / "-" / ".")
                         ; fully qualified domain name as specified
                         ; in RFC 1035 (and updates)
"

Section 2.3.1 of RFC1035
"
<domain> ::= <subdomain> | " "

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case

<digit> ::= any one of the ten digits 0 through 9
"

My conclusion after comparing the grammars of the three RFCs: 
1) According to the above RFC4282 grammar, "2.a " is a valid realm.
2) According to the above RFC4566 grammar, "2.a " is not a valid FQDN since
it has only 3 characters (not 4 or more).
3) According to the above RFC1035 grammar, "2.a" is not a valid domain since
it doesn't start with a letter (but a digit).

If one could prove that the grammar of realm is the same as the grammar of
FQDN,  then, RFC4282, RFC1035 and RFC4566 would be proven inconsistent
according.

However, I am not sure if I have found the right place where the strict
grammar of FQDN is defined. Please tell me if you know.
But RFC4566 and RFC1035 were the materials my comment in the previous email
was based on. 

Best Regards,
Fortune

-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: Thursday, March 05, 2009 6:02 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in
RFC3588bis

Hi Fortune,
> What would be the "potential" impacts to say that the DiameterIdentity can
be a FQDN or a realm?
I have the same question as Lionel. Syntactically, FQDN and realm are the
same from the parsers point of view. The difference is in semantics which is
already specified by the AVP having that type.

regards,
victor

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 09:41:35 +0100

Hi Victor, Glen

> De : Glen Zorn [mailto:[email-masked]] 
> Envoyé : jeudi 5 mars 2009 00:16
> À : 'Victor Fajardo'; MORAND Lionel RD-CORE-ISS
> Cc : [email-masked]; [email-masked]
> > > >From a syntax point of view, what is the difference 
> between a FQDN
> > and a realm?

I think that it is exactly what Glen was pointing out. The "current" definition of the AVP relies on the use of the DiameterIdentity format that it is itself defined as only identifying a FQDN. It is where there is an inconstency and it is why I proposed the modified definition of the DiameterIdentity format.

Glen, Would the proposed modification of the definition of the DiameterIdentity close the issue?

BR,

Lionel

---

From: jouni korhonen <[email-masked]>
Date: Thu, 5 Mar 2009 11:42:50 +0200

Hi Fortune,

On Mar 5, 2009, at 4:46 AM, Fortune HUANG wrote:

[snip]

> 1) According to the above RFC4282 grammar, "2.a " is a valid realm.

Correct.

> it has only 3 characters (not 4 or more).

First, RFC4566 ABNF is not in a role for defining FQDN.. it is an ABNF  
for SDP grammar. So if the SDP grammar ABNF is wrong, it is not the  
problem of original FQDN ABNF. Besides, using "2.a" as an example is  
misleading. There is no root zones that are one character long (see  
ICP-1, RFC1591). The shortest root zone is two characters, which would  
e.g. be "2.ac" and this is correct according to the ABNF in RFC4566.  
The RFC1035 BNF would allow one character root zones, however, those  
just do not exist in Internet DNS.

> it doesn't start with a letter (but a digit).

RFC1101 updates RFC1035 and relaxes the issue with a digit being the  
first character.

> FQDN,  then, RFC4282, RFC1035 and RFC4566 would be proven inconsistent

So far, no problems with cases 2) and 3). Regarding the case 1) few  
notes. RFC3588bis section 1.3. states that "NAI realm names are  
required to be unique, and are piggybacked on the administration of  
the DNS namespace." This basically means one loses its rights for  
"creative" realm names when used with Diameter. In DNS, one character  
root zones do not exist, thus "2.a" is not legal within Diameter scope.

> But RFC4566 and RFC1035 were the materials my comment in the  

Although this stuff is spread a bit around and topped with de-facto  
assumptions, I think there is no issue.

Cheers,
	Jouni

>>> From a syntax point of view, what is the difference between a FQDN  
>>> and a
> realm?

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 10:50:10 +0100

Hi Jouni,

It is also my understanding.

Lionel 

> De : jouni korhonen [mailto:[email-masked]] 
> Envoyé : jeudi 5 mars 2009 10:43
> À : Fortune HUANG
> Cc : 'Victor Fajardo'; MORAND Lionel RD-CORE-ISS; [email-masked]
> Objet : Re: [Dime] Problem with Origin- & Destination-Realm 
> AVPs in RFC3588bis
> 
> 
> Hi Fortune,
> 
> 
> > 2) According to the above RFC4566 grammar, "2.a " is not a 
> valid FQDN 
> > since it has only 3 characters (not 4 or more).
> 
> First, RFC4566 ABNF is not in a role for defining FQDN.. it 
> is an ABNF for SDP grammar. So if the SDP grammar ABNF is 
> wrong, it is not the problem of original FQDN ABNF. Besides, 
> using "2.a" as an example is misleading. There is no root 
> zones that are one character long (see ICP-1, RFC1591). The 
> shortest root zone is two characters, which would e.g. be 
> "2.ac" and this is correct according to the ABNF in RFC4566.  
> The RFC1035 BNF would allow one character root zones, 
> however, those just do not exist in Internet DNS.
> 
> >
> > 3) According to the above RFC1035 grammar, "2.a" is not a 
> valid domain 
> > since it doesn't start with a letter (but a digit).
> 
> RFC1101 updates RFC1035 and relaxes the issue with a digit 
> being the first character.
> 
> 
> > If one could prove that the grammar of realm is the same as the 
> > grammar of FQDN,  then, RFC4282, RFC1035 and RFC4566 would 
> be proven 
> > inconsistent according.
> 
> So far, no problems with cases 2) and 3). Regarding the case 
> 1) few notes. RFC3588bis section 1.3. states that "NAI realm 
> names are required to be unique, and are piggybacked on the 
> administration of the DNS namespace." This basically means 
> one loses its rights for "creative" realm names when used 
> with Diameter. In DNS, one character root zones do not exist, 
> thus "2.a" is not legal within Diameter scope.
> 
> > However, I am not sure if I have found the right place where the 
> > strict grammar of FQDN is defined. Please tell me if you know.
> > But RFC4566 and RFC1035 were the materials my comment in 
> the previous 
> > email was based on.
> 
> Although this stuff is spread a bit around and topped with 
> de-facto assumptions, I think there is no issue.
> 
> Cheers,
> 	Jouni
> 
> 
> 
> 
> >
> >
> >
> > Best Regards,
> > Fortune
> >
> > the same from the parsers point of view. The difference is in 
> > semantics which is already specified by the AVP having that type.
> >
> > regards,
> > victor
> >