Re: [Dime] NAPTR fix for 3588bis

[Qin Wu <[e-mail]>]

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: [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