One document matched: draft-yourtchenko-tran-announce-dns-00.txt
Network Working Group A. Yourtchenko
Internet-Draft D. Wing
Intended status: Standards Track cisco
Expires: March 22, 2010 September 18, 2009
A la carte: Announcing the supported transport protocols via DNS
draft-yourtchenko-tran-announce-dns-00
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 March 22, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
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 transports beyond just UDP and
TCP and to use TCP in new ways. It is inefficient to naively probe
Yourtchenko & Wing Expires March 22, 2010 [Page 1]
Internet-Draft Announcing the transports via DNS September 2009
the server using the new protocol. This document proposes a new DNS
resource record which provides an efficient way to query which
protocols are supported by a server.
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. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Yourtchenko & Wing Expires March 22, 2010 [Page 2]
Internet-Draft Announcing the transports via DNS September 2009
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 "TRAN", 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 March 22, 2010 [Page 3]
Internet-Draft Announcing the transports via DNS September 2009
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 TRAN 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 MUST 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 March 22, 2010 [Page 4]
Internet-Draft Announcing the transports via DNS September 2009
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 TRAN 5 _sctp,udp
TRAN 5 _sctp
TRAN 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 TRAN 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 March 22, 2010 [Page 5]
Internet-Draft Announcing the transports via DNS September 2009
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. 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.
9. Acknowledgements
[[Placeholder.]]
10. IANA Considerations
This document has no IANA actions.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Yourtchenko & Wing Expires March 22, 2010 [Page 6]
Internet-Draft Announcing the transports via DNS September 2009
[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.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
11.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-02 (work in progress),
October 2008.
[I-D.tuexen-sctp-udp-encaps]
Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP
Packets", draft-tuexen-sctp-udp-encaps-02 (work in
progress), November 2007.
[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.
Authors' Addresses
Andrew Yourtchenko
cisco
6a de Kleetlaan
Diegem 1831
BE
Phone: +32 2 704 5494
Email: ayourtch@cisco.com
Yourtchenko & Wing Expires March 22, 2010 [Page 7]
Internet-Draft Announcing the transports via DNS September 2009
Dan Wing
cisco
170 West Tasman Drive
San Jose CA 95134
USA
Email: dwing@cisco.com
Yourtchenko & Wing Expires March 22, 2010 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 11:47:45 |