Subject: Re: [Dime] NAPTR fix for 3588bis

From: "Glen Zorn" <[email-masked]>
Date: Sun, 4 Apr 2010 22:12:30 -0700

If the problem will be fixed in 3588bis then there is no need to file an
erratum.

Hope this helps.

~gwz

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mark Jones
> Sent: Wednesday, March 31, 2010 11:32 AM
> To: jouni korhonen
> Cc: [email-masked]
> Subject: Re: [Dime] NAPTR fix for 3588bis
> 
> 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,
> >
> > Thanks Mark for initiating the discussion and proposing text. My
> > initial comments inline.
> >
> > On Mar 31, 2010, at 4:48 PM, Mark Jones wrote:
> >
> > > 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.
> 
> >
> > >
> > > 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'.
> >
> > 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
> 
> > >
> > >       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
> >
> > See my note above regarding the application protocol.
> >
> >
> > >
> > > ************************* 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
> >
> > 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
> >
> 
> Fine by me.
> 
> >
> > >
> > >   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 ***********************
> >
> > - Jouni
> >
> >
> >
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Thu, 8 Apr 2010 12:41:48 +0200

Hi All,

I'm fine with the proposal, as said furing the meeting.
About the ABNF issue, i think it is solved now and and we can go on with "diameter.x" (cf. http://www.rfc-editor.org/errata_search.php?rfc=3958)

About registry issue in the RFC 3588, my understanding is that existing Diameter deployments (i.e. based on the RFC3588) rely somehow on "specific" implementation if they want to use DNS for Diameter peer discovery (as the actual content of the RFC 3588 is "not correct").

After the publication of the RFC 3588bis, the exiting RFC3588 will become obsolete. New Diameter deployment will be based on the new RFC. Pre-existing Diameter deployment will either still rely on their "specific" DNS procedures (if already deployed and there is no need to interwork with new external networks i.e. "do what you want in your walled garden") or update their implementation to cope with the solution defined in the RFC 3588bis.

If my understanding is correct, there is no need for Erratum for existing RFC 3588 if the "bis" version is (at last) published!

BR,

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Glen Zorn
> Envoyé : lundi 5 avril 2010 07:13
> À : 'Mark Jones'; 'jouni korhonen'
> Cc : [email-masked]
> Objet : Re: [Dime] NAPTR fix for 3588bis
> 
> If the problem will be fixed in 3588bis then there is no need 
> to file an erratum.
> 
> Hope this helps.
> 
> ~gwz
> 
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Mark Jones
> > > that we were leaning towards NOT creating these entries. 
> That would 
> > > be my preference too but are there any objections on the list?
> > >
> > > 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.
> > 
> > >
> > > >
> > > > Regards
> > > > Mark
> > > >
> > > >       [RFC3958] which means that the SERVICE field 
> includes tags 
> > > > for
> > > the
> > > >   order.  If the client supports TLS, TLS will be used, 
> targeted 
> > > > to
> > a

---

From: Mark Jones <[email-masked]>
Date: Thu, 8 Apr 2010 16:02:52 -0400

> Sebastien Decugis
> Sent: April 1, 2010 1:39 AM
> To: [email-masked]
> 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.
> 

Thanks for the feedback, Sebastien.

Now the tag ABNF issue is resolved, how about:

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

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

Agreed.

Regards
Mark

> Best regards,
> Sebastien.
> 
> --
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 8 Apr 2010 15:22:38 -0500

Hi Mark,

Are there any other open issues with this thread ? Do we have an agreed upon
solution ?

regards,
victor

---

From: Mark Jones <[email-masked]>
Date: Thu, 8 Apr 2010 18:02:50 -0400

Hi Victor,

I counted six issues raised by the proposed NAPTR fix:

1) Resolve what to do about existing NAPTR entries in RFC3588 (Jouni).
                Conclusion: Let them die with RFC3588 (when obsoleted by 3588bis).

2) Application protocol tags do not confirm to the ABNF in RFC3958 (Jouni)
                Conclusion: RFC3958 errata updated so the protocol tags now do conform to the new ABNF.

3) Add a TLS record to the S-NAPTR example (Jouni).
                Conclusion: Include Jouni's TLS example text in this fix.

4) Application protocol tag for TLS does not differentiate TLS/TCP vs TLS/SCTP (Sebastian).
                Conclusion: New TLS tags proposed to Sebastian. Still open.

5) Missing ref to TLS/SCTP - RFC3436 (Sebastian).
                Conclusion: Add the missing reference to 3588bis. Unrelated to this fix though.

6) Should this be handled as an errata to 3588 and/or added to 3588bis.
                Conclusion: Fix in 3588bis is preferred approach (Thanks Glen & Lionel for feedback).

If Sebastian is OK with the new application protocol tags for TLS, I think we have an agreed solution.

Did I miss anything?

Regards
Mark

From: Victor Fajardo [mailto:[email-masked]]
Sent: April 8, 2010 4:23 PM
To: Mark Jones
Cc: Sebastien Decugis; [email-masked]
Subject: Re: [Dime] NAPTR fix for 3588bis

Hi Mark,

Are there any other open issues with this thread ? Do we have an agreed upon solution ?

regards,
victor

On Thu, Apr 8, 2010 at 3:02 PM, Mark Jones <[email-masked]<mailto:[email-masked]>> wrote:
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Sebastien Decugis
> To: [email-masked]<mailto:[email-masked]>

  Tag               | Protocol

Agreed.

Regards
Mark

> NICT (nict.go.jp<http://nict.go.jp>)
>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Fri, 9 Apr 2010 18:42:07 +0200

Mark, Sébastien,

I don't have a specific issue with TLS over SCTP but if we rae referring to the current version of the RFC3588bis, there is the following limitation in section 2.1:

"  It is assumed that TLS is run on top of TCP when it is used.
   The remainder of this document uses the term TLS to abbreviate the
   use of TLS over TCP."

Before going further on this area, I would like to know why such a limitation was put.

Regards,

Lionel

> la part de Mark Jones
> Envoyé : jeudi 8 avril 2010 22:03
> À : Sebastien Decugis
> Cc : [email-masked]
> > Of Sebastien Decugis
> > while it is actually TLS over TCP or TLS over SCTP. I think that 
> > either "secure diameter" (diameters?) or "secure tcp / secure sctp" 
> > (tcps /

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 9 Apr 2010 12:01:28 -0500

Hi Lionel,

I guess it was added there because in practice, TLS is most often run over
TCP. Although, SCTP can be used, simplification of the process was the goal.
This is also reinforced when we cleaned up the inband-security in CER/CEA
and give way to specific listener port for TLS over TCP. We are treating TLS
over TCP as a unique secure transport for diameter and this is the reason
why we have TLS over TCP as the same level as TCP and SCTP.

regards,
victor

On Fri, Apr 9, 2010 at 11:42 AM, <[email-masked]> wrote:

> Mark, Sébastien,
>
> I don't have a specific issue with TLS over SCTP but if we rae referring to
> the current version of the RFC3588bis, there is the following limitation in
> section 2.1:
>

---

From: <[email-masked]>
Date: Fri, 9 Apr 2010 19:10:12 +0200

Thx Victor for the clarification.
 
It was also my recollection but I was not deeply involved in this discussion. That means that, whatever the exact wording (i.e. diameter.tls.tcp, diameter.tls), only TCP over TLS is added as alternative to ipsec. And only three tags have to be defined i.e. TCP, SCTP and TLS/TCP.
 
I'm fine with "diameter.tls.tcp" for the last one.
 
regards,
 
lionel

________________________________

	De : Victor Fajardo [mailto:[email-masked]] 
	Envoyé : vendredi 9 avril 2010 19:01
	À : MORAND Lionel RD-CORE-ISS
	Cc : [email-masked]; [email-masked]; [email-masked]
	Objet : Re: [Dime] NAPTR fix for 3588bis

	Hi Lionel,
	
	I guess it was added there because in practice, TLS is most often run over TCP. Although, SCTP can be used, simplification of the process was the goal. This is also reinforced when we cleaned up the inband-security in CER/CEA and give way to specific listener port for TLS over TCP. We are treating TLS over TCP as a unique secure transport for diameter and this is the reason why we have TLS over TCP as the same level as TCP and SCTP.
	
	regards,
	victor

		Mark, Sébastien,

		
		
		Regards,
		
		Lionel

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 12 Apr 2010 11:43:23 +0900

Hi,

Sorry for the delay, I was on vacation.

>                 Conclusion: New TLS tags proposed to Sebastian. Still

I am perfectly fine with the resolution you proposed, thank you!

> Unrelated to this fix though.
I guess this resolution will require a bit more feedback from the group,
there may be other ways to implement TLS over SCTP... Can the chairs
give direction on this issue?

Thanks!
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 12 Apr 2010 11:55:12 +0900

Hi,

I personally see no point in limiting the ability to use TLS over SCTP.
In several places, the document describes SCTP as a "better" transport
for Diameter than TCP (for the reasons described in RFC3539). It also
recommends the use of TLS to protect the connection -- and it is quite
straight-forward with a dedicated TLS port. It is easy to listen on this
TLS-dedicated port in SCTP in addition to TCP.

BTW I think the document should have a reference to RFC3554 (SCTP over
IPsec) as well...

Best regards,
Sebastien.

Le 10/04/2010 02:10, [email-masked] a écrit :
> It was also my recollection but I was not deeply involved in this
> discussion. That means that, whatever the exact wording (i.e.
> diameter.tls.tcp, diameter.tls), only TCP over TLS is added as
> alternative to ipsec. And only three tags have to be defined i.e. TCP,
> SCTP and TLS/TCP.
>  
>     ------------------------------------------------------------------------
>     *De :* Victor Fajardo [mailto:[email-masked]]
>     *Envoyé :* vendredi 9 avril 2010 19:01
>     *À :* MORAND Lionel RD-CORE-ISS
>     *Cc :* [email-masked]; [email-masked];
>     [email-masked]
>     *Objet :* Re: [Dime] NAPTR fix for 3588bis
>
>     Hi Lionel,
>
>     I guess it was added there because in practice, TLS is most often
>     run over TCP. Although, SCTP can be used, simplification of the
>     process was the goal. This is also reinforced when we cleaned up
>     the inband-security in CER/CEA and give way to specific listener
>     port for TLS over TCP. We are treating TLS over TCP as a unique
>     secure transport for diameter and this is the reason why we have
>     TLS over TCP as the same level as TCP and SCTP.
>
>     regards,
>     victor
>
>
>     On Fri, Apr 9, 2010 at 11:42 AM, <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Mark, Sébastien,
>
>         I don't have a specific issue with TLS over SCTP but if we rae
>         referring to the current version of the RFC3588bis, there is
>         the following limitation in section 2.1:
>
>         > De : [email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked] <mailto:[email-masked]>] De
>         > la part de Mark Jones
>         > Cc : [email-masked] <mailto:[email-masked]>
>         > > From: [email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked] <mailto:[email-masked]>]
>         > On Behalf
>         > > Of Sebastien Decugis
>         > > To: [email-masked] <mailto:[email-masked]>
>         > > NICT (nict.go.jp <http://nict.go.jp>)
>         > >
>         > > [email-masked] <mailto:[email-masked]>
>         > [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 12 Apr 2010 07:27:48 -0500

Hi Sebastien,

> give direction on this issue?

For all practical purpose, is there really a strong deployable reason to
support TLS over SCTP ? I'm just hesitant to delay bis publication to
support an academic exercise.

regards,
victor

---

From: <[email-masked]>
Date: Mon, 12 Apr 2010 17:59:13 +0200

Hi,
 
Taking account that this topic came quite late in the revision process and to not delay the publication of the RFC3588bis, we could maybe consider to address TLS over SCTP in a separete draft in a latter phase if there is a WG interest of the WG to support this option.
 
Would it be acceptable?
 
Regards,
 
Lionel

	De : [email-masked] [mailto:[email-masked]] De la part de Victor Fajardo
	Envoyé : lundi 12 avril 2010 14:28
	À : Sebastien Decugis
	Cc : Mark Jones; [email-masked]
	Objet : Re: [Dime] NAPTR fix for 3588bis

	Hi Sebastien,

	On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis <[email-masked]> wrote:

		Hi,

		

	For all practical purpose, is there really a strong deployable reason to support TLS over SCTP ? I'm just hesitant to delay bis publication to support an academic exercise.
	
	regards,
	victor

		Thanks!
		Sebastien.

---

From: Mark Jones <[email-masked]>
Date: Mon, 12 Apr 2010 16:08:19 -0400

Works for me. I assume we'd still keep "diameter.tls.tcp" as the tag format so that "diameter.tls.sctp" can be used in the separate draft.

Mark

From: [email-masked] [mailto:[email-masked]]
Sent: April 12, 2010 11:59 AM
To: [email-masked]; [email-masked]
Cc: Mark Jones; [email-masked]
Subject: RE: [Dime] NAPTR fix for 3588bis

Hi,

Would it be acceptable?

Regards,

Lionel

On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

regards,
victor

Thanks!
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 13 Apr 2010 14:13:57 +0900

Hi,

I am fine with this approach as well. My initial intention was just to
highlight that having TLS at the same level as TCP and SCTP is very
confusing.
The tag "diameter.tls.tcp" is perfectly fine for me. And it will be
quite easy to figure what to do, should (TLS over) SCTP become more popular.

Best regards,
Sebastien.

Le 13/04/2010 05:08, Mark Jones a écrit :
>
> Works for me. I assume we’d still keep “diameter.tls.tcp” as the tag
> format so that “diameter.tls.sctp” can be used in the separate draft.
>
> Mark
>
> *From:* [email-masked]
> [mailto:[email-masked]]
> *Sent:* April 12, 2010 11:59 AM
> *To:* [email-masked]; [email-masked]
> *Cc:* Mark Jones; [email-masked]
> *Subject:* RE: [Dime] NAPTR fix for 3588bis
>
> Hi,
>
> Taking account that this topic came quite late in the revision process
> and to not delay the publication of the RFC3588bis, we could maybe
> consider to address TLS over SCTP in a separete draft in a latter
> phase if there is a WG interest of the WG to support this option.
>
> Would it be acceptable?
>
> Regards,
>
> Lionel
>
>     *De :* [email-masked] [mailto:[email-masked]] *De la
>     part de* Victor Fajardo
>     *Envoyé :* lundi 12 avril 2010 14:28
>     *À :* Sebastien Decugis
>     *Cc :* Mark Jones; [email-masked]
>     On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     > 4) Application protocol tag for TLS does not differentiate
>     TLS/TCP vs
>     > TLS/SCTP (Sebastian).
>     >
>     For all practical purpose, is there really a strong deployable
>     reason to support TLS over SCTP ? I'm just hesitant to delay bis
>     publication to support an academic exercise.
>
>     regards,
>     victor
>
>
>
>         Thanks!
>         Sebastien.
>
>         --
>         Sebastien Decugis
>         Research fellow

---

From: <[email-masked]>
Date: Tue, 13 Apr 2010 16:46:11 +0200

Thx Sébastien.

So to sum up, all the existing issues are now closed.

Any other feedback from the WG on the proposed modification?

Hereafter the modification proposed by Mark with corrections based on the agreement reached after email discussion:

   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.

=> 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.tcp   | TLS/TCP

   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.tcp"  ""     _diameter._tls.tcp.example.com
 IN NAPTR  100   50   "s"   "aaa:diameter.tcp"      ""     _diameter._tcp.example.com
 IN NAPTR  150   50   "s"   "aaa:diameter.sctp"     ""     _diameter._sctp.example.com

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

=>addition of an example with "a" flag required such as:

 IN NAPTR  150   50   "a"   "aaa:diameter.tls.tcp"  ""     server1.example.com
 IN NAPTR  150   50   "a"   "aaa:diameter.tls.tcp"  ""     server2.example.com

> De : Sebastien Decugis [mailto:[email-masked]] 
> Envoyé : mardi 13 avril 2010 07:14
> À : Mark Jones
> Cc : MORAND Lionel RD-CORE-ISS; [email-masked]; [email-masked]
> I am fine with this approach as well. My initial intention 
> was just to highlight that having TLS at the same level as 
> TCP and SCTP is very confusing.
> The tag "diameter.tls.tcp" is perfectly fine for me. And it 
> will be quite easy to figure what to do, should (TLS over) 
> SCTP become more popular.
> 
> Best regards,
> Sebastien.
> 
> > Works for me. I assume we'd still keep "diameter.tls.tcp" 
> as the tag 
> > format so that "diameter.tls.sctp" can be used in the 
> separate draft.
> >
> > Mark
> >
> >     I guess this resolution will require a bit more 
> feedback from the
> >     group,

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 13 Apr 2010 12:50:40 -0500

Looks good. I'll send out a bis version with the changes below.

On Tue, Apr 13, 2010 at 9:46 AM, <[email-masked]> wrote:

> Hereafter the modification proposed by Mark with corrections based on the
> agreement reached after email discussion:
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 14 Apr 2010 10:47:06 +0800

Hi,
Sorry for my late reply. 
Go through the proposed Changes to the bis version. 
I found  "diameter.tls" as the supported application protocol in the *FIRST CHANGE* is still used there 
which is not consistent with "diameter.tls.tcp" specified in the *SECOND CHANGE*.

Also some questions to the changes:
1. If the Diameter server indicates to the Diameter client that it support both TCP and TLS/TCP
  and the Diameter client also support both, whether the Diameter client can still choose TCP as transport
  protcol? In other words, in which condition does the client choose TCP and in which condition does the client choose TLS/TCP?
or Can we say TLS/TCP transport is more reliable and secure than TCP transport for Diameter? That's why we choose TLS over TCP instead of TCP?
2. I am wondering Whether TLS/TCP transport can work in the roaming scenario? In order words, whether we can 
allow several Diameter peers located between Diameter Client and Diameter Server? whether TLS/TCP can work across realms?
3.When the Diameter Client choose TLS/TCP as transport, what transport port will be used ? Same as port for TCP or SCTP or not ? if not,what is it?
Hope somebody can clarify. Thanks!

Regards!
-Qin
  ----- Original Message ----- 
  From: Victor Fajardo 
  To: [email-masked] 
  Cc: [email-masked] ; [email-masked] 
  Sent: Wednesday, April 14, 2010 1:50 AM
  Subject: Re: [Dime] NAPTR fix for 3588bis

    Thx Sébastien.

      Tag                | Protocol

    > >     publication to support an academic exercise.

------------------------------------------------------------------------------

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 14 Apr 2010 07:42:24 -0500

Hi Qun,

Comments inline:

On Tue, Apr 13, 2010 at 9:47 PM, Qin Wu <[email-masked]> wrote:

>   protcol? In other words, in which condition does the client choose TCP
> and in which condition does the client choose TLS/TCP?
>

That depends on the security policy during deployment of the diameter node.
Its not something that the document should specify.

> or Can we say TLS/TCP transport is more reliable and secure than
> TCP transport for Diameter? That's why we choose TLS over TCP instead of
> TCP?
>

I'm not exactly sure what you mean here. Additional security would be the
only criteria for using TLS/TCP.

> allow several Diameter peers located between Diameter Client and Diameter
> Server? whether TLS/TCP can work across realms?
>

Hmmm ... I think your forgetting the fact that diameter transport are
peering transports, i.e. transport connections are negotiated/configured on
a per peer connection basis. So the question does not seem to make sense to
me.

> 3.When the Diameter Client choose TLS/TCP as transport, what transport port
> will be used ? Same as port for TCP or SCTP or not ? if not,what is it?
>

TLS/TCP is going to be on a different port than just plain TCP. Port
assignments for TCP is in to current doc while TLS is still to be allocated.

regards,
victor

> *From:* Victor Fajardo <[email-masked]>
> *To:* [email-masked]
> *Cc:* [email-masked] ; [email-masked]
> *Sent:* Wednesday, April 14, 2010 1:50 AM
> *Subject:* Re: [Dime] NAPTR fix for 3588bis
>
>  ------------------------------
>

---

From: jouni korhonen <[email-masked]>
Date: Wed, 14 Apr 2010 19:24:59 +0300

Hi Qin,

>   protcol? In other words, in which condition does the client choose TCP and in which condition does the client choose TLS/TCP?

An operator can actually set the preference using NAPTR order and preference fields when doing DNS provisioning. So the mechanism is there.

> or Can we say TLS/TCP transport is more reliable and secure than TCP transport for Diameter? That's why we choose TLS over TCP instead of TCP?

Up to an operator to set the preference.

> allow several Diameter peers located between Diameter Client and Diameter Server? whether TLS/TCP can work across realms?

Such deployment issues are usually handled by e.g. a consortium that mandates the use of Diameter in the first place.

> 3.When the Diameter Client choose TLS/TCP as transport, what transport port will be used ? Same as port for TCP or SCTP or not ? if not,what is it?

When using SVRs (i.e. a NAPTR points to a SRV), an operator can define the used port number. So, this can again be solved by proper provisioning. A predefined port number could be useful but imho really not needed. The draft could though say something about this.

- Jouni

---

From: Qin Wu <[email-masked]>
Date: Thu, 15 Apr 2010 12:51:59 +0800

Hi, Jouni:
Please see my feedback below.
----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Victor Fajardo" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, April 15, 2010 12:24 AM
Subject: Re: [Dime] NAPTR fix for 3588bis

Hi Qin,

[Qin]: Agree this is deployment specific issue.

[Qin]: As I discussed with Victor, I buy it.:-)

[Qin]: Okay, but as I mentioned to Victor, the only difficult for me is whether TLS/TCP transport works in the case when the intermeidate peer(e.g., Proxy) does not support TLS/TCP between the client and server?

[Qin]: Agree. Thank for your clarification.

- Jouni

---

From: Qin Wu <[email-masked]>
Date: Thu, 15 Apr 2010 12:53:09 +0800

Hi, Victor:
Thank for your reply. I have no objection for these changes to the bis version.
Just want to look deeper into TLS/TCP as transport. Please see my feedback
below.

Regards!
-Qin
  ----- Original Message ----- 
  From: Victor Fajardo 
  To: Qin Wu 
  Cc: [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Wednesday, April 14, 2010 8:42 PM
  Subject: Re: [Dime] NAPTR fix for 3588bis

  Hi Qun,

  Comments inline:

    Hi,
    Sorry for my late reply. 
    Go through the proposed Changes to the bis version. 
    I foundÂ  "diameter.tls" asÂ the supported application protocol in the *FIRST CHANGE* is still used there 
    which is not consistent with "diameter.tls.tcp"Â specified in the *SECOND CHANGE*.
    Â 
    AlsoÂ some questionsÂ to the changes:
    1. If the Diameter server indicates to the Diameter client that it support both TCP and TLS/TCP
    Â  and the Diameter client also support both,Â whether the Diameter client can still chooseÂ TCP as transport
    Â  protcol?Â In other words,Â in which conditionÂ does the client choose TCP andÂ in which conditionÂ does the client choose TLS/TCP?

  That depends on the security policy during deployment of the diameter node. Its not something that the document should specify. 

  [Qin]: I agree this is deployment specific issue, actually my intention is to try to figure out how many criterials for choosing different transport for Diameter.

  Â 
    orÂ Can we say TLS/TCP transport is more reliableÂ and secure than TCPÂ transport for Diameter? That's why we choose TLS over TCP instead of TCP?

  I'm not exactly sure what you mean here. Additional security would be the only criteria for using TLS/TCP.

  [Qin]: That's what I try to answer by myself in response to what transport protocol will be chosen. :-) But I still want to figure out what the limitations of choosing TLS/TCP is.
  In that case, when Diameter Client support both TCP and TLS/TCP, the Diameter Client may still choose TCP as transport. Anyway it is just deployment specific issue and depend
  on the operator's own choice.

  Â 

  Hmmm ... I think your forgetting the fact that diameter transport are peering transports, i.e. transport connections are negotiated/configured on a per peer connection basis. So the question does not seem to make sense to me.

  [Qin]: You get to the point. Diameter transport is peering transport. I buy it. But suppose Diameter works across two realms, there are one Diameter peer A without TLS support between Diameter Client and Diameter Server, also both Diameter Client and Diameter Server support TLS/TCP transport, Can Diameter Client choose TLS/TCP as transport
  between itself and Diameter Server? That's the only difficult I have.

  Â 
    3.WhenÂ the DiameterÂ Client choose TLS/TCP as transport, what transport port will be usedÂ ? Same as port for TCP or SCTP or not ? if not,what is it?

  TLS/TCP is going to be on a different port than just plain TCP. Port assignments for TCP is in to current doc while TLS is still to be allocated.

  [Qin]: I think it is better to choose the same port number for transport like 3868, in that way, it is easy to filter Diameter protocol when capturing. But that is not important any more.

  regards,
  victor

  Â 
    Â 
    Regards!
    -Qin
      ----- Original Message ----- 
      From: Victor Fajardo 
      To: [email-masked] 
      Cc: [email-masked] ; [email-masked] 
      Sent: Wednesday, April 14, 2010 1:50 AM
      Subject: Re: [Dime] NAPTR fix for 3588bis

        Thx SÃ©bastien.

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

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

        Appendix B. Â NAPTR Example

        Â  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.tcp" Â "" Â  Â  _diameter._tls.tcp.example.com
        Â IN NAPTR Â 100 Â  50 Â  "s" Â  "aaa:diameter.tcp" Â  Â  Â "" Â  Â  _diameter._tcp.example.com
        Â IN NAPTR Â 150 Â  50 Â  "s" Â  "aaa:diameter.sctp" Â  Â  "" Â  Â  _diameter._sctp.example.com

        Â  This indicates that the server supports TLS/TCP, TCP and SCTP in that
        Â  order. Â If the client supports TLS/TCP, TLS/TCP will be used, targeted to a
        Â  host determined by an SRV lookup of _diameter._tls.tcp.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

        Â IN NAPTR Â 150 Â  50 Â  "a" Â  "aaa:diameter.tls.tcp" Â "" Â  Â  server1.example.com
        Â IN NAPTR Â 150 Â  50 Â  "a" Â  "aaa:diameter.tls.tcp" Â "" Â  Â  server2.example.com

        14.1. Â Normative References

        > EnvoyÃ© : mardi 13 avril 2010 07:14
        > Ã€ : Mark Jones

        > Le 13/04/2010 05:08, Mark Jones a Ã©crit :
        > >
        > > Â  Â  *De :* [email-masked]
        > [mailto:[email-masked]] *De la
        > > Â  Â  part de* Victor Fajardo
        > > Â  Â  *EnvoyÃ© :* lundi 12 avril 2010 14:28
        > > Â  Â  *Ã€ :* Sebastien Decugis
        > > Â  Â  *Cc :* Mark Jones; [email-masked]
        > > Â  Â  *Objet :* Re: [Dime] NAPTR fix for 3588bis
        > >
        > > Â  Â  Hi Sebastien,
        > >
        > > Â  Â  On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis
        > > Â  Â  <[email-masked] <mailto:[email-masked]>> wrote:
        > >
        > > Â  Â  Hi,
        > >
        > > Â  Â  Sorry for the delay, I was on vacation.
        > >
        > > Â  Â  Le 09/04/2010 07:02, Mark Jones a Ã©crit :
        > > Â  Â  > 4) Application protocol tag for TLS does not differentiate
        > > Â  Â  TLS/TCP vs
        > > Â  Â  > TLS/SCTP (Sebastian).
        > > Â  Â  >
        > > Â  Â  > Conclusion: New TLS tags proposed to Sebastian. Still
        > > Â  Â  > open.
        > > Â  Â  >
        > >
        > > Â  Â  I am perfectly fine with the resolution you proposed, thank you!
        > >
        > > Â  Â  > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian).
        > > Â  Â  >
        > > Â  Â  > Conclusion: Add the missing reference to 3588bis.
        > > Â  Â  > Unrelated to this fix though.
        > > Â  Â  >
        > > Â  Â  I guess this resolution will require a bit more
        > feedback from the
        > > Â  Â  group,
        > > Â  Â  there may be other ways to implement TLS over SCTP...
        > Can the chairs
        > > Â  Â  give direction on this issue?
        > >
        > >
        > >
        > > Â  Â  For all practical purpose, is there really a strong deployable
        > > Â  Â  reason to support TLS over SCTP ? I'm just hesitant to delay bis
        > > Â  Â  publication to support an academic exercise.
        > >
        > > Â  Â  regards,
        > > Â  Â  victor
        > >
        > >
        > >
        > > Â  Â  Â  Â  Thanks!
        > > Â  Â  Â  Â  Sebastien.
        > >
        > > Â  Â  Â  Â  --
        > > Â  Â  Â  Â  Sebastien Decugis
        > > Â  Â  Â  Â  Research fellow
        > > Â  Â  Â  Â  Network Architecture Group
        > > Â  Â  Â  Â  NICT (nict.go.jp <http://nict.go.jp>)
        > >
        >
        > --
        > Sebastien Decugis
        > Research fellow

--------------------------------------------------------------------------