Re: [Dime] NAPTR fix for 3588bis

[jouni korhonen <[e-mail]>]

Hi Qin,

On Apr 14, 2010, at 5:47 AM, Qin Wu wrote:

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

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.

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

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

> Hope somebody can clarify. Thanks!
>  
> Regards!
> -Qin
> ----- Original Message -----
> From: Victor Fajardo
> To: [e-mail]
> Cc: [e-mail] ; [e-mail]
> Sent: Wednesday, April 14, 2010 1:50 AM
> Subject: Re: [Dime] NAPTR fix for 3588bis
> 
> Looks good. I'll send out a bis version with the changes below.
> 
> 
> On Tue, Apr 13, 2010 at 9:46 AM, <[e-mail]> wrote:
> 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:
> 
> ************************* 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.tcp   | TLS/TCP
> 
> ************************* 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.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
> 
> =>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
> 
> ************************* FOURTH CHANGE **************************
> 
> 14.1.  Normative References
> 
> => Add new reference to S-NAPTR DDDS RFC3958.
> 
> ************************* END OF CHANGES ***********************
> 
> 
> 
> 
> 
> > -----Message d'origine-----
> > De : Sebastien Decugis [mailto:[e-mail]]
> > Envoyé : mardi 13 avril 2010 07:14
> > À : Mark Jones
> > Cc : MORAND Lionel RD-CORE-ISS; [e-mail]; [e-mail]
> > Objet : Re: [Dime] NAPTR fix for 3588bis
> >
> > 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:* [e-mail]
> > > [mailto:[e-mail]]
> > > *Sent:* April 12, 2010 11:59 AM
> > > *To:* [e-mail]; [e-mail]
> > > *Cc:* Mark Jones; [e-mail]
> > > *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 :* [e-mail]
> > [mailto:[e-mail]] *De la
> > >     part de* Victor Fajardo
> > >     *Envoyé :* lundi 12 avril 2010 14:28
> > >     *À :* Sebastien Decugis
> > >     *Cc :* Mark Jones; [e-mail]
> > >     *Objet :* Re: [Dime] NAPTR fix for 3588bis
> > >
> > >     Hi Sebastien,
> > >
> > >     On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis
> > >     <[e-mail] <mailto:[e-mail]>> 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
> > Network Architecture Group
> > NICT (nict.go.jp)
> >
> >
> 
> 
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime