Re: [Dime] NAPTR fix for 3588bis

[Qin Wu <[e-mail]>]

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: [e-mail] ; [e-mail] ; [e-mail] 
  Sent: Wednesday, April 14, 2010 8:42 PM
  Subject: Re: [Dime] NAPTR fix for 3588bis


  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. 

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

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

  [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


  Â 
    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