One document matched: draft-barwood-dnsext-edns-page-option-00.txt

DNS Extensions Working Group                                  G. Barwood
Internet-Draft                                                           
Intended status: Standards track                          15 August 2009
Expires: February 2010


                           EDNS Page Option    
               draft-barwood-dnsext-edns-page-option-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 February 16, 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

   Describes an EDNS option to allow large DNS responses to be sent 
   using small UDP packets.







Barwood                    Expires February 2010                [Page 1]

Internet-Draft                EDNS Page Option               August 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4

     2.1 Initial request  . . . . . . . . . . . . . . . . . . . . . .  4

     2.2 Server response  . . . . . . . . . . . . . . . . . . . . . .  4

     2.3 Follow-up request  . . . . . . . . . . . . . . . . . . . . .  5    

   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6

   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6

   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  6

   6.  Informative References . . . . . . . . . . . . . . . . . . . .  6



































Barwood                    Expires February 2010                [Page 2]

Internet-Draft                EDNS Page Option               August 2009


1.  Introduction

   DNSSEC implies that DNS responses may be much large, possibly
   larger than the de factor ~1500 byte internet MTU.

   Large UDP packets are undesirable for 3 reasons:

   (1) Although the IP protocol specifies a means by which large IP 
   packets are split into fragments and then re-assembled, in practice
   this mechanism cannot be relied on, and large UDP packets may fail
   to be delivered

   (2) If a single fragment is lost, the the entire response must be
   re-sent.

   (3) The large ratio between the request size and the response size
   allows malicious programs to mount "amplification" attacks.

   (4) Re-assembling fragments requires buffer resources, which opens
   up denial of service attacks.

   Instead, it is possible to use TCP, but this is undesirable, as TCP
   imposes significant overhead and state that is vulnerable to denial
   of service attack.

   Nearly all current DNS traffic is carried by UDP with a maximum 
   size of 512 bytes, and relying on TCP is a risk for the deployment
   of DNSSEC.

   Therefore an EDNS option to allow large DNS responses to be sent 
   using small UDP packets is proposed.

   The option includes an authentication mechanism that ensures that
   blind spoofing of the response is not possible.




















Barwood                    Expires February 2010                [Page 3]

Internet-Draft                EDNS Page Option               August 2009
   
   
2. Protocol

2.1 Initial request

   The client signals support in it's initial request by including
   an EDNS Page option containing the following data:

   - Secret key length ( up to 16 bytes )
   - Secret key

   The secret key is used to validate the response, preventing blind 
   spoofing.

2.2 Server response

   The server responds with an EDNS Page option containing the following
   option data:

   - Secret key length
   - Secret key ( up to 16 bytes )
   - Total response size ( 16 bits )
   - Data offset ( 16 bits )
   - Response data length ( 16 bits )
   - Response data
   - Cookie length ( 1 byte )
   - Cookie
   - MAC Type ( 1 byte )
   - MAC Length ( 1 byte )
   - MAC ( Message authentication code )
 
   The original Question is also sent.

   The secret key is a copy of the secret key sent in the request.

   The length of the response data is chosen so that the complete 
   response packet size does not exceed the EDNS UDP payload size as
   defined in [RFC2181]. Servers may also limit the response size for 
   other reasons, for example to mitigate an amplification attack.

   The cookie has data that allows the server to send further data. Many
   different implementations are possible, and this document does not
   attempt to enumerate all these possibilities, except to note that
   allowance must be made for server updates and restarts.

   A MAC Type of 0 indicates that the server does not generate MACs.
   A MAC Type of 1 indicates that the MAC is the 129-bit SHA1 hash of
   the concatenation of the following option data.
   Other MAC Types are reserved.

   The client allocates an assembly buffer, and copies the Response data
   into it, at the specified Data offset. 



Barwood                    Expires February 2010                [Page 4]

Internet-Draft                EDNS Page Option               August 2009

2.3 Follow-up request
  
   The client then sends a follow-up request, which contains an EDNS
   page option with option data as follows:

   - Secret key length ( 1 byte )
   - Secret key ( up to 16 bytes )
   - Cookie length ( 1 byte )
   - Cookie

   The secret key may be a new secret key, or the same secret key
   as for the initial request.

   The cookie is a copy of the server cookie it has just received.

   The original Question is also sent.

   The exchange repeats until the client receives a response where the
   (Page offset) + (Response data length) = (Total response size).
   At this point, the client has the complete response, which is then
   processed normally.

   The server may restart the process if necessary ( for example due to
   authoritative data being updated, or for any other reason, such as
   a server restart ). The client must therefore check the Total
   response size of each response, and re-size the buffer as required.

   The client should retry a request if no response is received after a
   timeout period.


























Barwood                    Expires February 2010                [Page 5]

Internet-Draft                EDNS Page Option               August 2009


3.  Security Considerations

   The secret key may expose internal state to an attacker who controls
   a name server. It is essential that a cryptographically strong source
   of random numbers be used to generate the secret key. This must be 
   seeded from data that cannot be guessed by an attacker, such as
   thermal noise or other random physical fluctuations.

   Clients must verify the secret key in each response. Clients should
   also verify the MAC in each response, if there is a possiblity that
   the response may have been IP fragmented. This also ensures that
   any transmission errors are detected with very high probability.

   Servers should seek to minimise or eliminate per-client state, to 
   mitigate DoS attacks.

4.  IANA Considerations

   The EDNS TYPE code for Page Option.
   The MAC Type code ( new registry ).

5.  Acknowledgments


6.  Informative References

   [RFC2181]  P. Vixie, "Extension Mechanisms for DNS (EDNS0)", 
              RFC 2181, August 1999.

Author's Address

   George Barwood
   33 Sandpiper Close
   Gloucester 
   GL2 4LZ
   United Kingdom

   Phone: +44 452 722670
   EMail: george.barwood@blueyonder.co.uk















Barwood                       Expires February 2010             [Page 6]