[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                     A. Yourtchenko
Internet-Draft                                                   D. Wing
Intended status:  Standards Track                                  cisco
Expires:  October 2, 2010                                 March 31, 2010


    A la carte: Announcing the supported transport protocols via DNS
                 draft-yourtchenko-tran-announce-dns-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 2, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   While TCP has enjoyed many enhancements over the decades, it is
   useful to allow applications to use new transports, such as SCTP.  It



Yourtchenko & Wing       Expires October 2, 2010                [Page 1]


Internet-Draft      Announcing the transports via DNS         March 2010


   is inefficient to naively probe the server using the new transport
   protocol.  This document proposes a new DNS resource record which
   provides an efficient way to query which protocols are supported by a
   server.  The presence of this record will allow the client to avoid
   the excessive probing.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
   3.  Description . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Contents of RR  . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Comparison with SRV records . . . . . . . . . . . . . . . . . . 4
   6.  The example of a zone file  . . . . . . . . . . . . . . . . . . 5
   7.  Deployment considerations . . . . . . . . . . . . . . . . . . . 5
   8.  Evaluation of existing resource record types  . . . . . . . . . 6
     8.1.  TXT RR  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.2.  WKS RR  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.3.  CNAME RR  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     12.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     12.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
























Yourtchenko & Wing       Expires October 2, 2010                [Page 2]


Internet-Draft      Announcing the transports via DNS         March 2010


1.  Introduction

   Many new transport protocols have been developed in recent years DCCP
   [RFC4340], SCTP [RFC4960], but have seen little deployment on the
   Internet.  There are two reasons for the lack of deployment:  IPv4
   middleboxes (e.g, NAT, firewall) which block the new protocol and
   lack of application support for the transport protocol.  By running
   the transport protocols over UDP ( DCCPoUDP
   [I-D.phelan-dccp-natencap] and SCTPoUDP
   [I-D.tuexen-sctp-udp-encaps]), or utilizing IPv6, hosts can overcome
   the problems caused by IPv4 middleboxes.  But once a client
   application supports a new transport protocol a new problem arises:
   the client application has no choice but to probe the server (and the
   network) with all of the viable transport protocols.  For example, an
   HTTP client that supports both TCP and SCTP would need to send a TCP
   SYN and an SCTP INIT and SCTP over UDP until the client learns if
   both the network path and the server support TCP, SCTP, or SCTP over
   UDP.  This is described in detail in I-D.wing-http-new-tech
   [I-D.wing-http-new-tech]

   This specification defines a new DNS resource record (RR) which helps
   optimize the probing.  With the new RR, the server can advertise
   which transport protocols it supports for a specific application.
   With that information, the client application only needs to probe the
   network path for those transport protocols.  This helps reduce
   unnecessary network traffic and, more importantly, prevents
   degradation of the user experience when a new transport protocol is
   enabled on the client and is being deployed on servers on the
   Internet.


2.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Description

   This proposal introduces the new resource record type, which we
   denote "XPORT", that allows to get the answer to the question "For a
   given application-level protocol APP on the host HOST in the domain
   DOMAIN, which transport protocol should I choose ?".

   The client that wants to know the preferred transport, would query
   for this record on the name _app.hostname.example.com, and parse the
   received reply in order to get the list of the transports that the



Yourtchenko & Wing       Expires October 2, 2010                [Page 3]


Internet-Draft      Announcing the transports via DNS         March 2010


   server(s) can offer for this application.  Each of the returned RRs
   would contain the transport choice along with the preference value
   for this choice.  The smaller values mean more preferred choices.
   [LATER:  the parameters for the transport may also be specified]

   Subsequently, the client would use the application name and the
   resolved transport name to query the SRV records to get the actual
   hostname and port to connect to.


4.  Contents of RR

   The preference is encoded as a single byte value between 48 and 57 -
   which gives the textual representation in the ASCII format between
   '0' and '9'.  The protocol and its optional parameters are encoded
   into a comma-separated string.  The protocol is the name of the
   protocol suitable for passing to getprotobyname(), prefixed with "_".

   +-------+-------+-------+ . . .
   | pref  | proto and parms ....
   +-------+-------+-------+ . . .

   The parameters are protocol-specific.  When the casing of the
   parameters is not explicitly specified, they MUST be all-lowercase.

   The only currently defined parameter is "udp" which means the
   protocol-specific encapsulation over UDP.

   The reason for choosing this format is the possibility of easy
   (ab)use of TXT record in order to hold the same information, in case
   the new RR is deemed unnecessary.


5.  Comparison with SRV records

   The SRV records allow to answer the question:  "What is the hostname
   and port?" - given the known application, transport, and domain name.

   The XPORT records allow to answer the question:  "What is the
   transport ?" - given the known application and domain name.

   The client stack MAY use SRV records subsequently in order to
   determine the ports and the real hosts that will serve this
   application.

   The server application SHOULD also listen on the default transports
   for that application, to avoid the malfunction of the clients that
   are not upgraded (for example, for HTTP that would be TCP transport).



Yourtchenko & Wing       Expires October 2, 2010                [Page 4]


Internet-Draft      Announcing the transports via DNS         March 2010


6.  The example of a zone file

   Borrowing the example of the zone file from SRV RR [RFC2782]
   specification, we show the relevant part of it in order to hint the
   clients about the various protocols that can be used for accessing
   "http://www.example.com", and to hint that
   "http://newhost.example.com/" is only accessible via SCTP.


     $ORIGIN example.com.
     @               SOA server.example.com. root.example.com. (
                         1995032001 3600 3600 604800 86400 )
                     NS  server.example.com.
                     NS  ns1.provider.example.net.
                     NS  ns2.provider.example.net.

     ; http transport selection - signal to use SCTP over UDP and SCTP,
     ; and use tcp as a fallback mechanism for the host 'www'

     _http.www        XPORT    5 _sctp,udp
                      XPORT    5 _sctp
                      XPORT    9 _tcp

     www              A       192.0.2.10

     ; the newhost's http is only accessible via SCTP, hint about this.
     ; note that we still need to have the host listening on TCP
     ; as well to preserve the legacy hosts' operation.

     _http.newhost    XPORT    1 _sctp

     newhost          A       192.0.2.11



7.  Deployment considerations

   The DNS was chosen instead of any other mechanism due to its
   widespread deployment, and the logical positioning of the protocol
   within the applications.

   The incremental nature of the change means that only one side would
   need to be modified initially (content provider).  The unmodified
   applications would work with the default transport assignments for
   the application protocols.

   The separate resource record allows for the separation of this
   mechanism from the existing ones.  However, considering the possibly



Yourtchenko & Wing       Expires October 2, 2010                [Page 5]


Internet-Draft      Announcing the transports via DNS         March 2010


   lower entry costs, one could consider using the TXT record for
   storing the preference information - the encoding is crafted in such
   a way that using the TXT record is straightforward.  (TBD:  should we
   consider a "magic number" to be put in the beginning of the TXT
   record to ensure we can verify the usage of TXT record, or the exotic
   name is enough ?)

   It may be noted that the extra lookup mentioned in this proposal adds
   to the latency of the initial connection establishment.  However,
   assuming the transports are not going to change, it should be
   feasible to use longer lifetimes, and cache the results at the local
   recursive name server.


8.  Evaluation of existing resource record types

   Introducing of a new resource record type takes time due to the
   standards process, the availability of the support for the new
   resource record type in the nameservers code, problems with the
   nameservers that fail when queried for the resource record types they
   do not recognize, and so on.  This section evaluates how well
   existing resource records can provide the functionality similar to
   XPORT.

8.1.  TXT RR

   The authors have considered following the example of RFC4871
   [RFC4871] to use a subdomain starting with an underscore.  This would
   result in the following zone file examples:

        _xport._http.www.example.com in txt ("SCTP,SCTPUDP,TCP")
        _xport._http.server.example.com in txt ("TCP")

   This could be extended further to provide weights like the XPORT
   resource record, for example:

        _xport._http.www.example.com in txt ("SCTP=5,SCTPUDP=5,TCP=9")

   While this could be quickly deployed, it was felt too cumbersome.

8.2.  WKS RR

   The WKS resource record [RFC1035] provides functionality similar to
   the proposal in this document.  However, WKS returns an IPv4 address
   and a bitmask of ports for the explicit transport protocols (e.g.
   TCP, SCTP), thus is not suitable for IPv6 nor for protocols which
   lack an IETF protocol assignment (such as tunneling a transport
   protocol over UDP [I-D.tuexen-sctp-udp-encaps]).



Yourtchenko & Wing       Expires October 2, 2010                [Page 6]


Internet-Draft      Announcing the transports via DNS         March 2010


8.3.  CNAME RR

   The authors considered an idea of combining the SRV and defining a
   "catch-all" transport name, say, "_any", and use the SRV records to
   help determine the transport(s) offered by the server.  The
   "_appname._any.example.com" record would contain multiple CNAME
   records, say, "_appname._tcp.example.com" and
   "_appname._sctp.example.com".  The latter names would have the valid
   SRV records for the respective protocols.  Consequently, an SRV
   lookup of _appname._any.example.com would give a CNAME and the
   corresponding SRV record - and the contents of the CNAME could be
   analyzed to extract the protocol to use.

   However, this would not work, because the section 3.6.2 of [RFC1034]
   allows only one CNAME.


9.  Security Considerations

   This proposal allows to influence the preferred transport for the
   client by means of DNS.

   First possibility is attacker preventing the DNS reply from reaching
   the client.  In this case, the client would fallback to the default.
   However, assuming the attacker can block the message on the way back
   to the client, it could block the A/AAAA response messages as well,
   so this path does not add any new attack vectors.

   Second possibility is for the attacker to spoof the packets in case
   they are not there.  In this case, the attacker could have spoofed
   the A/AAAA responses as well and direct the client to an address of
   his choosing.  Therefore, this path does not add any new attack
   vectors either.


10.  Acknowledgements

   Thanks to Bryan Ford and Janardhan Iyengar for the discussions that
   led to this draft.  Thanks to Erik Kline for the review and
   suggestions.


11.  IANA Considerations

   This document has no IANA actions.


12.  References



Yourtchenko & Wing       Expires October 2, 2010                [Page 7]


Internet-Draft      Announcing the transports via DNS         March 2010


12.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

12.2.  Informative References

   [I-D.phelan-dccp-natencap]
              Phelan, T., "Datagram Congestion Control Protocol (DCCP)
              Encapsulation for NAT Traversal (DCCP-NAT)",
              draft-phelan-dccp-natencap-03 (work in progress),
              November 2009.

   [I-D.tuexen-sctp-udp-encaps]
              Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP
              Packets", draft-tuexen-sctp-udp-encaps-03 (work in
              progress), December 2009.

   [I-D.wing-http-new-tech]
              Wing, D., Yourtchenko, A., and P. Natarajan, "Happy
              Eyeballs: Successful Introduction of New Technology to
              HTTP", draft-wing-http-new-tech-00 (work in progress),
              July 2009.








Yourtchenko & Wing       Expires October 2, 2010                [Page 8]


Internet-Draft      Announcing the transports via DNS         March 2010


Authors' Addresses

   Andrew Yourtchenko
   cisco
   6a de Kleetlaan
   Diegem  1831
   BE

   Phone:  +32 2 704 5494
   Email:  ayourtch@cisco.com


   Dan Wing
   cisco
   170 West Tasman Drive
   San Jose  CA 95134
   USA

   Email:  dwing@cisco.com
































Yourtchenko & Wing       Expires October 2, 2010                [Page 9]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/