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

Differences from draft-barwood-dnsext-edns-page-option-01.txt

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


                           EDNS Page Option    
               draft-barwood-dnsext-edns-page-option-02    

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 20, 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 large, possibly larger
   than the de facto ~1500 byte internet MTU.

   Large UDP packets are undesirable for several 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.

   A particular problem occurs with home router proxies, which
   often truncate DNS responses at 512 bytes. In this case, TCP does
   not help, and it is impossible to retrieve responses through the
   proxy.

   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 prevents blind
   spoofing of the response, provided IP fragmentation does not occur.
   














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

2. Protocol

   Option data is sent in the order shown. Reserved areas must be set to
   zero by the sender and must be ignored by the receiver.

2.1 Initial request

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

   - Follow up request ( 1 bit, set to 0 )
   - Send All Pages flag ( 1 bit )
   - Reserved ( 6 bits )
   - UDP payload size ( 2 bytes )
   - Secret Key ( 4 bytes )  
   - Reserved ( variable length )

   The "Send All Pages" flag may be set to 1 to request that the server
   sends all pages immediately. Servers are not required to support 
   this mode of operation, and it must not be used with proxy servers
   that do not support it.

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

   The server responds with an EDNS Page option with option data :

   - All Pages Sent ( 1 bit )
   - No Cookie ( 1 bit )
   - Reserved ( 2 bits )
   - Page size ( 12 bits )
   - Total response size ( 2 bytes )
   - Secret key ( 4 bytes )
   - Cookie ( 4 bytes )
   - Page number ( 1 byte )
   - Page data ( variable length )
 
   The original Question is not sent.

   The No Cookie flag is defined only when All Pages Sent is 1,
   otherwise it is reserved. If No Cookie is 1, the Cookie is omitted,
   and follow-up requests are not possible.

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

   The page size is chosen so that the complete response packet size
   does not exceed the UDP payload in the request. Servers may also
   limit the response size for other reasons, for example to mitigate
   an amplification attack, or to avoid IP fragmentation.

   The client allocates an assembly buffer, and copies the Page data
   into it, at offset (Page number) x (Page Size).

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

2.3 Follow-up request
  
   If All Pages Sent is 0, the client sends a follow-up request for each
   page it has not yet received. The client should also send follow-up
   requests if an expected response is not received after a timeout 
   period due to packet loss.
   
   A follow-up request is identical to the initial request, except 
   that the EDNS page option data is as follows:

   - Follow up request ( 1 bit, set to 1 )
   - Reserved ( 3 bits )
   - Page size ( 12 bits )
   - Secret Key ( 4 bytes )  
   - Cookie ( 4 bytes )
   - Page number ( 1 bytes )
   - Reserved ( variable length )

   The cookie (possibly in conjunction with the Question) identifies a
   read-only representation of the full response on the server.

   The cookie has a lifetime of 5 seconds. After this time has elapsed,
   a SERVERFAIL error response may be generated.
   
   When the client has received all of the pages, the complete assembled
   response is then processed normally.

   Follow-up requests may be sent in parallel. 

3. Compatibility

   Servers are not required to support the EDNS Page option, however
   support is encouraged.

   Authoritative servers that do not support the EDNS page option can
   expect a higher level of TCP traffic.

   Authoritative servers need not support cookies. Requests to 
   authoritative servers should always set the Send All Pages flag. 
   However, cookie support is encouraged, as it allows dropped packets
   to be retried without re-sending the whole response.

   DNSSEC aware recursive servers need to support cookies if they may
   be accessed via proxy servers that truncate responses at 512 bytes.

   DNSSEC validating stub resolvers need to use the EDNS Page option if
   they may be deployed behind proxy servers that truncate responses at
   512 bytes.







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


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

   Fragmented responses are vulnerable to blind spoofing, therefore
   fragmented responses should be avoided if possible.

5.  IANA Considerations

   The EDNS TYPE code for Page Option.  

6.  Acknowledgments

   Mark Andrews, Alex Bligh, Robert Elz, Wouter Wijngaards, Nicholas Weaver
   were each instrumental in creating and refining this specification.

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