Re: [Dime] NAPTR fix for 3588bis

[Victor Fajardo <[e-mail]>]

Hi Qun,

Comments inline:

On Tue, Apr 13, 2010 at 9:47 PM, Qin Wu <[e-mail]> 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?
>


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.



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


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




> Hope somebody can clarify. Thanks!
>
> Regards!
> -Qin
>
> ----- Original Message -----
> *From:* Victor Fajardo <[e-mail]>
> *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
>
>