EDX - Edge Exchanger
draft-edx-edge-exchanger-01

Document Type Active Internet-Draft (individual)
Last updated 2019-12-04
Stream (None)
Intended RFC status (None)
Formats plain text pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Draft                                            Sweta Jaiswal
<draft-edx-edge-exchanger-01.txt>                         Karthikeyan A.
Intended status: Standards Track                         Jamsheeed M. P.
Expires: April 25, 2020                                Siva Sabareesh D.
                                                           Madhan Raj K.
                                                        December 4, 2019

                          EDX - Edge Exchanger
                      draft-edx-edge-exchanger-00

Abstract          

   This document describes a new DNS resource record (RR) type, called
   the Edge Exchanger (EDX) RR, that is used to find services and
   location of the server(s) for any specific domain (the word domain is
   used here in the strict RFC1034 sense). 

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts. The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

Copyright Notice

   Copyright (c) 2019 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

 

                          Expires June 6, 2020                  [Page 1]
Internet Draft                                         December 04, 2019

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2. Applicability Statement . . . . . . . . . . . . . . . . . . . .  3
   3. EDX Resource Record Format  . . . . . . . . . . . . . . . . . .  3
     3.1.  Example Data . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  EDX RDATA Wire Format  . . . . . . . . . . . . . . . . . .  5
   4. Usage Rules . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1. Query without knowing the service name  . . . . . . . . . .  6
     5.2. A new way to explore available services . . . . . . . . . .  6
     5.3. Discover the edge servers . . . . . . . . . . . . . . . . .  7
     5.4. A platform to advertise the available services  . . . . . .  7
   6. IANA considerations . . . . . . . . . . . . . . . . . . . . . .  7
   7. Security Considerations . . . . . . . . . . . . . . . . . . . .  7
     7.1. Attacker Tampering with an Insecure EDX RR  . . . . . . . .  7
     7.2. Response Data . . . . . . . . . . . . . . . . . . . . . . .  8
     7.3. Error Handling  . . . . . . . . . . . . . . . . . . . . . .  8
   8. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1. Normative References  . . . . . . . . . . . . . . . . . . .  8
     8.2. Informative References  . . . . . . . . . . . . . . . . . .  9
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9

1. Introduction

   This document proposes a new Resource Record (RR) named Edge
   Exchanger (EDX) for the Domain Name System (DNS) [RFC1034] and its
   application usage. This document specifies how this DNS resource
   record helps client in finding lowest latency servers and also
   facilitate service discovery given the correct domain name.

   Currently, the service discovery can be done using SRV resource
   record type where the client requests for a specific service and
   protocol for a domain name and receives the target host and port
   where the service instance can be reached. To connect to the target
   host client needs to perform DNS resolution to fetch the IP address.
   Hence, we propose DNS EDX RR which provides a platform for clients to
   discover the services available for a domain name with list of
   primary IP address, running services and port information.

   At present, there is no way to find all the services available in a
   server using one DNS query. The new RR EDX allow servers to advertise
   its services to all users as well as it enables client to find the
   low latency edge servers for a service using the service and location
   information.

   Querying the EDX Resource Record does not mean replacement of SRV
 

                          Expires June 6, 2020                  [Page 2]
Internet Draft                                         December 04, 2019

   [RFC2782] and LOC [RFC1876] Resource record. Instead, EDX RR provides
   a complimentary mechanism to find the list of services as well as
   location, port and IP address of the primary servers present for the
   corresponding services for a domain, using just one query.

   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 BCP 14, RFC 2119
   [RFC2119].

2. Applicability Statement

   In general, it is expected that EDX records will be used by clients
   for applications to find the hosted services and locations for a
   specific hostname. Clients pass a hostname with EDX Service Field and
   get back the services, protocol and target names of all available
   servers. One example is when an organization provides more than one
   services running on multiple primary and backup servers but the
   clients are unaware of these services. Clients can discover these set
   of services using EDX RR type queries.

3. EDX Resource Record Format

   The master file format of EDX RR type is defined below.

   owner TTL Class EDX (Edge Port Lat Long Priority Version Address     
                                        _Service._Proto.Target-host)

   ( The parentheses are used for multi-line data as specified in [RFC
   1035] section 5.1. )

   Owner       : The domain-name for which these RR refers to.

   TTL         : Standard DNS meaning [RFC1035].

   Class       : Standard DNS meaning [RFC1035]. EDX records occur in
              the IN Class.

   Edge        : A flag to set the target host as edge or remote server.

   Service     : The symbolic name of the services supported by the
              owner. An underscore (_) is prepend to the service
              identifier to avoid collisions with DNS labels that occur
              in nature. Valid service parameters are those registered
              by IANA in the "Service Name and Transport Protocol Port
              Number Registry" as mentioned in [RFC6335]. The Service is
              case insensitive.

 

                          Expires June 6, 2020                  [Page 3]
Internet Draft                                         December 04, 2019

   Proto       : The symbolic name of the protocol supported by target
              host, with an underscore (_) prepend to prevent collisions
              with DNS labels that occur in nature. Valid protocol
              parameters are those registered by IANA in the "Service
              Name and Transport Protocol Port Number Registry" as
              mentioned in [RFC2782]. _TCP and _UDP are at present the
              most useful values for this field, though any name defined
              by Assigned Numbers or locally may be used (as for
              Service). The Proto is case insensitive.

   Target-host : The domain name of the target host. There MUST be one
              or more address records for this name, the name MUST NOT
              be an alias (in the sense of [RFC1034]).

   Port        : The port on this target host of this service. The range
              is 0-65535.  This is a 16 bit unsigned integer in network
              byte order. This is often as specified in Assigned Numbers
              but need not be.

   Lat         : The latitude of the center of the sphere described by
              the SIZE field, expressed as a 32-bit integer, most
              significant octet first (network standard byte order), in
              thousandth of a second of arc.  2^31 represents the
              equator; numbers above that are north latitude.

   Long        : The longitude of the center of the sphere described by
              the SIZE field, expressed as a 32-bit integer, most
              significant octet first (network standard byte order), in
              thousandths of a second of arc, rounded away from the
              prime meridian. 2^31 represents the prime meridian;
              numbers above that are east longitude.

   Priority    : The priority of this target host. A client MUST attempt
              to contact the target host with the lowest-numbered
              priority it can reach; target hosts with the same priority
              SHOULD be tried in an order defined by the weight field.
              The range is 0-65535. This is a 16 bit unsigned integer in
              network byte order.

   Version     : The Internet Protocol (IP) Version defines the type of
              target host IP address. It MUST BE 4 for "A" [RFC1035]
              type or 6 for "AAAA" [RFC3596] type.

   Address     : A 128 bit Internet address. The IP addresses may 
              belong to A [RFC1035] or AAAA [RFC3596] Resource Record
              Sets. The IP address will range from 32 bit to 128 bit.

3.1.  Example Data
 

                          Expires June 6, 2020                  [Page 4]
Internet Draft                                         December 04, 2019

   ;
   ; Please note that these data are fictional and not appear in any 
   ; zone file
   ; EDX RR data are derived from SRV RR & ZIP data combined together
   ;

   $ORIGIN sribsamsung.example.com.
           3600 IN EDX (0 389 23.000 32.000 2 4 198.51.100.110
                        _quic._tcp.sribsamsung.example.com.)

           3600 IN EDX (0 80 23.000 32.000 4 6
                        2001:0db8:85a3:0000:0000:8a2e:0370:7334
                        _http._tcp.sribsamsung.example.com.)

           3600 IN EDX (0 443 23.000 32.000 1 4 198.51.100.112
                        _https._tcp.sribsamsung.example.com.)

3.2.  EDX RDATA Wire Format

   The RDATA of EDX RR consist fixed length as well as variable length
   parameters.

      MSB                                                   LSB
        0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                     EDGE                      |
        2 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                     PORT                      |
        4 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                   LATITUDE                    |
        6 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                   LONGITUDE                   |
        8 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                   PRIORITY                    |
       10 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                  IP VERSION                   |
       12 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                                               |
          |                  IP ADDRESS                   |
          |                                               |
       28 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          /                                               /
          /           _service_proto.target               /
          /                                               /
     28+x +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    (octet)

   Edge flag and Port are unsigned 16 bit integer. Edge Flag is 0 or 1
 

                          Expires June 6, 2020                  [Page 5]
Internet Draft                                         December 04, 2019

   for remote server or edge server respectively, whereas the value of
   port ranges from 0-65535. It is expressed in network byte order.

   Latitude and Longitude are signed integers expressed in network byte
   order.

   Priority and IP Version are unsigned integers in network byte order.

   IP Address can vary from 32 to 128 bit unsigned integer based on IP
   Address Type "A" or "AAAA".

   Finally, the RDATA consists of a variable length Target field which
   consist of service, protocol and target name. The length of the
   Target Field MUST be greater than zero.

4. Usage Rules

   A EDX-cognizant client SHOULD use this procedure to discover the list
   of services and the location of these servers:

      Do a lookup for QNAME=domain-name, QTYPE=EDX.

5. Usage Scenarios

   In this section, a number of scenarios showing the usage and
   practical applications of EDX RR are explained briefly. 

5.1. Query without knowing the service name

   Client need not know the service name for querying the domain for any
   service related information. The EDX resource record can be viewed as
   a broader extension of SRV RR. Unlike SRV RR, where SHOULD know the
   domain name, the service name and the protocol name, EDX RR can be
   used without knowing the service name. Just the correct domain name
   is enough to fetch the available services and its related
   information.

5.2. A new way to explore available services

   Client can now explore a domain for its available services. An
   organization having specific domain name providing many services like
   FTP archive, http and https services can be browsed by any client
   knowing the domain name. For example, the organization with domain
   name sribsamsung.example.com. can have these entries in DNS master
   file.

   $ORIGIN sribsamsung.example.com.
 

                          Expires June 6, 2020                  [Page 6]
Internet Draft                                         December 04, 2019

           3600 IN EDX (0 21 23.000 32.000 4 4 198.51.100.113
                        _ftp._tcp.sribsamsung.example.com.)
                
           3600 IN EDX (0 80 23.000 32.000 5 4 198.51.100.111
                        _http._tcp.sribsamsung.example.com.)

           3600 IN EDX (0 443 23.000 32.000 3 4 198.51.100.112
                        _https._tcp.sribsamsung.example.com.)

   These services provided by sribsamsung.example.com can be fetched
   using just one DNS EDX RR query using the domain name and without
   knowing all the services and protocols. With the EDX RR responses the
   clients can use these available services.

   The number of answers and its sequence in EDX RR MUST be based on
   server Resource Record configuration and the maximum limit of
   response data. This document does not specify any priority criteria,
   based on service name or location information.

5.3. Discover the edge servers

   Clients can use the edge flag and the location information of EDX
   response to locate the low latency servers among all for any
   services.

5.4. A platform to advertise the available services

   This new EDX RR provides servers a platform to advertise their
   services to clients by updating their running services and target
   host information as EDX resource record.
6. IANA considerations

   This RFC defines the format of a new Resource Record (RR) for the
   Domain Name System (DNS), and reserves a corresponding DNS type
   mnemonic (EDX) and numerical code (234) if accepted by IANA. IANA is
   requested to assign a DNS RR data type value of 234 and DNS type
   mnemonic EDX for this new DNS EDX RR. No other IANA services are
   required by this document.

7. Security Considerations

   This section contains a description of the known threats involved
   with the usage of the DNS EDX RR.

7.1. Attacker Tampering with an Insecure EDX RR

   With EDX, DNS spoofers can supply false port numbers, locations as
   well as target names and addresses. Because this vulnerability exists
 

                          Expires June 6, 2020                  [Page 7]
Internet Draft                                         December 04, 2019

   already, with names and addresses, this is not a new vulnerability,
   merely a slightly extended one, with little practical effect.

   To avoid the same, an EDX client SHOULD obtain EDX RRs from a trusted
   party through a secure channel ensuring data integrity and
   authenticity of the RRs. DNSSEC [RFC4033] [RFC4034] [RFC4035]
   provides such a secure channel. However, it should be emphasized that
   DNSSEC only offers data integrity and authenticity guarantees to the
   channel between the DNS server publishing a zone and the HIP node.
   DNSSEC does not ensure that the entity publishing the zone is
   trusted.

7.2. Response Data

   In the absence of secure channel, the Authoritative DNS servers MAY
   validate the client IP Address. An Authoritative DNS server MAY
   prevent returning EDX records over UDP unless the source IP address
   has been confirmed with DNS Cookies.  If a query is received via UDP
   without source IP address verification, the server MUST NOT return
   REFUSED but answer the query with an empty answer section and the
   truncation flag set ("TC=1").

7.3. Error Handling

   It is also possible that the EDX in the resource record type has
   errors in it.  Applications using the EDX resource record type for
   resolution SHOULD behave similarly as if the user typed the correct
   domain name without any resource records.  At least it must be clear
   to the user that the error is not due to any error from his side.

8. References

8.1. Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI
              10.17487/RFC2119, March 1997, <http://www.rfc-
              editor.org/info/rfc2119>.

 

                          Expires June 6, 2020                  [Page 8]
Internet Draft                                         December 04, 2019

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000, <http://www.rfc-
              editor.org/info/rfc2782>.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", RFC 3596, DOI
              10.17487/RFC3596, October 2003, <http://www.rfc-
              editor.org/info/rfc3596>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <http://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <http://www.rfc-editor.org/info/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <http://www.rfc-editor.org/info/rfc4035>.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,
              <http://www.rfc-editor.org/info/rfc6335>.

8.2. Informative References

   [RFC1876]  Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
              Means for Expressing Location Information in the Domain
              Name System", RFC 1876, DOI 10.17487/RFC1876, January
              1996, <http://www.rfc-editor.org/info/rfc1876>.

Author's Addresses

   Sweta Jaiswal
   Samsung R&D Institute India - Bangalore
 

                          Expires June 6, 2020                  [Page 9]
Internet Draft                                         December 04, 2019

   Karnataka - 560037
   India.
   Email: sweta.j@samsung.com

   Karthikeyan Arunachalam
   Samsung R&D Institute India - Bangalore
   Karnataka - 560037
   India.
   Email: karthikeya.a@samsung.com

   Jamsheed Manja Ppallan
   Samsung R&D Institute India - Bangalore
   Karnataka - 560037
   India.
   Email: jamsheed.mp@samsung.com

   Dronamraju Siva Sabareesh
   Samsung R&D Institute India - Bangalore
   Karnataka - 560037
   India.
   Email: s.sabareesh@samsung.com

   Madhan Raj Kanagarathinam
   Samsung R&D Institute India - Bangalore
   Karnataka - 560037
   India.
   Email: madhan.raj@samsung.com

                          Expires June 6, 2020                 [Page 10]