Subject: [Dime] NAPTR fix for 3588bis

From: Mark Jones <[email-masked]>
Date: Wed, 31 Mar 2010 09:48:59 -0400

Here are the proposed changes to 3588bis to implement the fix for the NAPTR issues discussed at IETF#77 (see http://www.ietf.org/proceedings/10mar/slides/dime-5.pdf).

Comments appreciated.

There was some discussion at the meeting of creating S-NAPTR Application Service Tag entries for the unregistered NAPTR values in RFC3588 ("AAA+D2x"). No consensus was reached but my impression was that we were leaning towards NOT creating these entries. That would be my preference too but are there any objections on the list?

Regards
Mark

************************* FIRST CHANGE *************************

Section 5.2 Diameter Peer Discovery

=> Replace step 2 with the following text:

   2.  The Diameter implementation performs a NAPTR query for a server
       in a particular realm.  The Diameter implementation has to know
       in advance which realm to look for a Diameter agent in.  This
       could be deduced, for example, from the 'realm' in a NAI that a
       Diameter implementation needed to perform a Diameter operation
       on.

       The NAPTR usage in Diameter follows the S-NAPTR DDDS application 
       [RFC3958] which means that the SERVICE field includes tags for the 
       desired application and supported application protocol.
       The application service tag for a Diameter application is 'aaa' and 
       the supported  application protocol tags are 'diameter.tcp', 
       'diameter.sctp' or 'diameter.tls'. 

       The client follows the resolution process defined by the S-NAPTR 
       DDDS [RFC3958] application to find a matching SRV or A record of 
       a suitable peer.  The domain suffixes in the NAPTR replacement field
       SHOULD match the domain of the original query.

************************* SECOND CHANGE *************************

Section 11.6 NAPTR Service Fields

=> Rename this section to S-NAPTR Parameters and replace content with:

This document registers a S-NAPTR Application Service Tag value of "aaa".

This document also registers the following S-NAPTR Application Protocol Tags:

   Tag            | Protocol
   ---------------|---------
   diameter.tcp   | TCP
   diameter.sctp  | SCTP
   diameter.tls   | TLS

************************* THIRD CHANGE **************************

Appendix B.  NAPTR Example

=> Rename section to S-NAPTR Example and modify as follows.

   As an example, consider a client that wishes to resolve aaa:
   example.com.  The client performs a NAPTR query for that domain, and
   the following NAPTR records are returned:

 ;;        order pref flags service             regexp replacement
 IN NAPTR  50    50   "s"   "aaa:diameter.tls"  ""     _diameter._tls.example.com
 IN NAPTR  100   50   "s"   "aaa:diameter.tcp"  ""     _aaa._tcp.example.com
 IN NAPTR  150   50   "s"   "aaa:diameter.sctp" ""     _diameter._sctp.example.com

   This indicates that the server supports TLS, TCP and SCTP in that
   order.  If the client supports TLS, TLS will be used, targeted to a
   host determined by an SRV lookup of _diameter._tls.example.com.  That
   lookup would return:

    ;;       Priority  Weight  Port    Target
    IN SRV   0         1       5060    server1.example.com
    IN SRV   0         2       5060    server2.example.com

************************* FOURTH CHANGE **************************

14.1.  Normative References

=> Add new reference to S-NAPTR DDDS RFC3958.

************************* END OF CHANGES ***********************

---

From: jouni korhonen <[email-masked]>
Date: Wed, 31 Mar 2010 19:20:25 +0300

Hi,

Thanks Mark for initiating the discussion and proposing text. My initial comments inline.

> There was some discussion at the meeting of creating S-NAPTR Application Service Tag entries for the unregistered NAPTR values in RFC3588 ("AAA+D2x"). No consensus was reached but my impression was…

Would be ok I think.. However, I really would like to see even some discussion related to them _somewhere_. Any ideas? Would an errata be enough to cover that?

>       'diameter.sctp' or 'diameter.tls'. 

RFC3958 ABNF does not allow "." in iana-registered-protocol, so the application protocol has to be changed, like "diametertcp" or "dtcp" etc..

> This document also registers the following S-NAPTR Application Protocol Tags:

See my note above regarding the application protocol.

> IN NAPTR  150   50   "s"   "aaa:diameter.sctp" ""     _diameter._sctp.example.com

And lets have an example of "a" flag as well:

IN NAPTR  150   50   "a"   "aaa:diametertls" ""     server1.example.com
IN NAPTR  150   50   "a"   "aaa:diametertls" ""     server2.example.com

> ************************* END OF CHANGES ***********************

- Jouni

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

---

From: Mark Jones <[email-masked]>
Date: Wed, 31 Mar 2010 14:32:29 -0400

Thanks for the feedback, Jouni. Responses inline.

> -----Original Message-----
> From: jouni korhonen [mailto:[email-masked]]
> Sent: March 31, 2010 12:20 PM
> To: Mark Jones
> Cc: [email-masked]
> Subject: Re: [Dime] NAPTR fix for 3588bis
> 
> Hi,
> 
> > Here are the proposed changes to 3588bis to implement the fix for the
> NAPTR issues discussed at IETF#77 (see
> http://www.ietf.org/proceedings/10mar/slides/dime-5.pdf).
> >
> > Comments appreciated.
> >
> > There was some discussion at the meeting of creating S-NAPTR
> Application Service Tag entries for the unregistered NAPTR values in
> RFC3588 ("AAA+D2x"). No consensus was reached but my impression was
> that we were leaning towards NOT creating these entries. That would be
> my preference too but are there any objections on the list?
> 
> Would be ok I think.. However, I really would like to see even some
> discussion related to them _somewhere_. Any ideas? Would an errata be
> enough to cover that?
> 

I do agree this change needs to be discussed but I assumed we were going to have that discussion _here_ on this list. If the errata review procedure is likely to generate more discussion then I'm all for it.

> RFC3958 ABNF does not allow "." in iana-registered-protocol, so the
> application protocol has to be changed, like "diametertcp" or "dtcp"
> etc..
> 

Lucky for us that IANA is ignoring the RFC3958 ABNF then :)

http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xhtml

Another errata perhaps?

   iana-registered-protocol  = ALPHA *31ALPHANUMSYM

> IN NAPTR  150   50   "a"   "aaa:diametertls" ""     server2.example.com

Fine by me.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 31 Mar 2010 21:46:57 +0300

Hi,

> I do agree this change needs to be discussed but I assumed we were going to have that discussion _here_ on this list. If the errata review procedure is likely to generate more discussion then I'm a…

Right. I have no idea how the errata stuff actually works in practice but we should, of course, first have a common agreement on the list.

>   iana-registered-protocol  = ALPHA *31ALPHANUMSYM

Great to see even RFC3958 authors do not follow the ABNF they created in later RFCs. RFC3958 already has an errata that says the ALPHANUM definition for iana-registered-protocol is missing and proposes one as a solution. Maybe we just have to carry on the  tradition of dodgy IANA DNS definitions in Diameter ;)

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Wed, 31 Mar 2010 22:08:39 +0300

[snip]

>   iana-registered-protocol  = ALPHA *31ALPHANUMSYM

More on this topic.. RFC3958 itself contain examples that go against the ABNF. So, I _guess_ it is ok for us to assume that

"iana-registered-protocol  = ALPHA *31ALPHANUM"

is actually

"iana-registered-protocol  = ALPHA *31ALPHANUMSYM"

- Jouni

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 01 Apr 2010 14:39:29 +0900

Hi,

>    diameter.tls   | TLS

I still don't understand why TLS is at the same level as TCP and SCTP,
while it is actually TLS over TCP or TLS over SCTP. I think that either
"secure diameter" (diameters?) or "secure tcp / secure sctp" (tcps /
sctps) would make more sense.

By the way, the document lacks a reference on how TLSoverSCTP is
supposed to be implemented... (RFC3436?)

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)