Subject: draft-ietf-dnsext-forgery-resilience-03

From: Alfred Hönes <[email-masked]>
Date: Thu, 27 Mar 2008 16:45:44 +0100 (MEZ)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

----- Forwarded message from Alfred Hönes -----

>From [email-masked] Thu Mar 27 16:42:26 MEZ 2008
From: Alfred Hönes <[email-masked]>
Subject: draft-ietf-dnsext-forgery-resilience-03
To: [email-masked], [email-masked]
Date: Thu, 27 Mar 2008 16:42:23 +0100 (MEZ)
Cc: [email-masked]

Hello,
after some time I eventually found the time to again spent some
time for the latest revision of your DNS Forgery Resilience I-D,
draft-ietf-dnsext-forgery-resilience-03.

The notes below are restricted to areas already discussed earlier
but not (yet) addressed in this edition, and which I did not find
being subject to elaboration on the list, quickly browsing through
the recent records in the list archive.

(1)  Section 1.1 -- editorial nit

Please apply a consistent style of punctuation, at the end of
the definitions in Section 1.1.

(2)  Section 3 -- order of numbered items

The draft says:

   DNS data is to be accepted by a resolver if and only if:

   1.  The question section of the reply packet is equivalent to that of
       a question packet currently waiting for an answer

   2.  The ID field of the reply packet matches that of the question
       packet

   3.  The answer comes from the same network address the question was
       sent to

   4.  The answer comes in on the same network address, including port
       number, as the question was sent from

This seems to suggest an order of checks to be performed by the
receiver of a DNS reply, but the sequence of items is illogical
and inappropriate for several reasons:

a)  The checks should be performed 'bottom up' in the network layers,
    for architectural reasons.
    If TCP transport is used, the correlation of transport address
    tuples (src/dst addr & port) is performed at the IP and TCP
    layers, anyway, before the application ever sees the response.
    In the (standard) case of UDP transport, these checks must be
    performed by the application (i.e., DNS resolver software)
    in a transport layer API specific manner.  For the sake of
    proper structuring, such code should parallel the code for TCP
    transport and provide a comparable set of functionality to the
    application (DNS) layer.

b)  To mitigate the net effect of DoS attacks, the computationally
    most simple checks should be performed first.
    Because the transport address tuples have to be matched first
    anyway to discover the DNS query context of the DNS reply,
    it is natural that the matching check of source address and port
    and destination address and port of the reply should be performed
    first.

c)  If multiple transactions are outstanding to an authoritative
    server using the same transport 'connection' (addr+port quadruple),
    the next step in discovering the context is the check of the
    ID field.

d)  If (and only if) all these checks have identified a single open
    query context, the reply can be accepted provisionally, and then
    the details of the question section be cross-checked with the
    query sent.  This is a much more complex operation, in particular
    due to the complicated rules for QNAME matching (case-insensitive
    matching of standard DNS labels, etc.), and hence should be
    performed late anyway -- see b) above.

Hence, the above snippit must be reordered and the items renumbered,
and the wording adjusted to the amount of context available at each
level:

   DNS data is to be accepted by a resolver if and only if:

|  1.  The answer comes from a transport address (IP address and port
|      number) a question was sent to recently (and still awaiting an
|      answer).

|  2.  The answer comes in on the same transport address (IP address
|      and port number) a question was sent from to the transport
|      address checked in step 1.

|  3.  The ID field of the reply packet matches that of a question
|      packet sent using the transport address pair checked in steps
|      1 and 2.

|  4.  The question section of the reply packet is equivalent to that of
|      the question packet identified in step 3 as currently waiting for
|      an answer, in particular, QCLASS and QTYPE match literally, and
|      QNAME matches according to the applicable label-specific rules.

Note 1:
  Section 9 already almost adheres to this ordering;
  I suggest to only reverse the last two bullets in the
  first part of section 9 to list the QCLASS + QTYPE check
  *before* the more complicated QNAME check.

Note 2:
  Since this is a SHOULD requirement, some resolvers might
  see the need to allow administrative suppressing some of
  these checks under particular circumstances, e.g. for
  TCP connections dedicated for a single AXFR query to legacy
  servers not following the echo-back rule for the ID field.

  This might be clarified in the draft at this place as well.

(3)  Section titles

After all, the title of Sections 3 and 4 seem to be inappropriate.

How about changing:

 3.  Description of DNS spoofing
---
 3.  Accepting DNS Replies

and:

 4.  Details
---
 4.  Details of DNS Reply Spoofing Attempts

(4)  Section 4.4

In the last paragraph, delete the word "spcifically"; it has
become redundant, or even confusing, by the text change performed
recently:

        [...].  While two Best Current Practice documents ([RFC2827] and
|  [RFC3013] specifically) direct Internet access providers to prevent
   their customers from assuming IP addresses that are not assigned to
   them, these recommendations are not universally (nor even widely)
   implemented.
---
        [...].  While two Best Current Practice documents ([RFC2827] and
|  [RFC3013]) direct Internet access providers to prevent their
   customers from assuming IP addresses that are not assigned to them,
   these recommendations are not universally (nor even widely)
   implemented.

Furthermore, I strongly recommend putting more emphasis on the
inalienable importance of ingress filtering, e.g., by replacing the
last two lines above by:

   [...]
   unfortunately these recommendations are yet not universally (nor even
   widely) implemented.

(5)  Section 4.5

Because of the drastical operational consequences, I suggest to
amend the text in Section 4.5, after the 2nd paragraph, as follows:

   The actual address of a recursing nameserver is generally known; the
   port used for asking questions is harder to determine.  Most current
   resolvers pick an arbitrary port at startup (possibly at random) and
   use this for all outgoing questions.  In quite a number of cases the
   source port of outgoing questions is fixed at the traditional DNS
   assigned server port number of 53.
|
|  Note however that, if the resolver is located behind a (port
|  translating) NAT or firewall, the externally visible source port
|  number will be randomized, perhaps over the full port number range.
|  Depending on the strategy implemented in the NAT or firewall, the
|  port number will be chosen independent of the destination transport
|  address or per transport address association.
|
|  The more granular the port selection of the NAT/firewall and the
|  larger the pool of port numbers used is, and the better the random
|  port number selection algorithm performs, this will restrict the
|  opportunities for an attacker to spoof the source transport address
|  significantly, and as such mitigate the threat of cache poisoning
|  for a resolver behind a NAT or firewall middlebox, from outside of
|  the protected subnetwork.

(6)  Section 7.2 -- editorials

The draft text still uses a confusing mix of quoted and non-quoted
instances of the formula variable names in the running text.

I strongly suggest to remove all single quotes still present in
the text surrounding variable names of formula terms.

(7)  Section 9 -- order of attribute checks

See Note 1 in item (2) above.

(8)  Section 9 -- Licence for active DoS ???

Section 9 contains a fatal recommendation.  Similar text in other
Internet-Drafts already has caused much trouble and denial of service
to legitimate, well-behaving resolvers.

The first bullet in the second part of Section 9 says:

   o  Use an unpredictable source port for outgoing queries from a range
|     (53, or > 1024) of ports that is as large as possible and
      practicable;

It should say:

   o  Use an unpredictable source port for outgoing queries from a range
|     of ports that is as large as possible and practicable;

Rationale:

Apparently, similar recommendations have caused administrators to
block access to DNS servers for specific source port number ranges,
in particular 1..52 and 54..1023.

This immediately leads to denial of service for all resolvers located
behind a (port translating) NAT/firewall middlebox that randomizes
the externally visible source port numbers, e.g. of DNS queries
sent out to the globally routable Internet.

For instance, practical observations and dedicated tests indicate
that a well-known major player in IT has established (since last
summer) such packet filters for the name servers they operate for
the public part of the company resources and for the public services
they offer, including a popular "high temperature" mail gate.

This effectively blackholes all attempts to establish communication
with users/clients of the "protected" infrastructure, for all users
of a DNS resolver located behind a port mapping NAT/firewall.
In particular, this practice makes it impossible for us to send mail
to IETF members affiliated with that company or being clients of the
mail gate they operate.

I have been told that the above restriction was based on the
(platform dependent) subdivision of port numbers.
This neglects the fundamental distinction between server port
numbers and client port numbers.
The classification of port numbers as codified in RFCs only applies
to server ports, i.e. ports intentionally unbound to a specific
remote transport address (unspecific Passive OPEN).
Apparently, this distinction is disregarded deliberately by some
(implementors and) administrators.

However, looking into RFC 1122, it becomes immediate that the
practice of restricting access for traffic based on (client) port
numbers in the range deemed 'restricted' in popular operating
systems (1-1023) is inappropriate.

Section 4.2.2.1 of RFC 1122 says (with respect to TCP -- but the
sections on UDP there refer to the port number discussion for TCP
as well):

              Some systems extend this notion by adding a third
              subdivision of the TCP port space: reserved ports,
              which are generally used for operating-system-specific
              services.  [...]
              [...]
              Some systems further choose to protect well-known and
              reserved ports by permitting only privileged users to
o>>>          open TCP connections with those port values.  This is
o>>>          perfectly reasonable as long as the host does not
o>>>          assume that all hosts protect their low-numbered ports
o>>>          in this manner.

I repeat:    ... as long as the host does not assume that all hosts
             protect their low-numbered ports in this manner.

Colophon:
  Some major providers of DNS services (including the operators
  of the largest gTLDs) and important security service providers
  once had installed similar filters as well, but they all have
  diligently removed these quickly after being informed of the
  damaging consequences.
  To my knowledge, it's only the single big player indicated above
  which still maintains these filters and has been resistive to all
  attempts to explain the DoS it causes.

(9)  Section 9 -- conflict with other specification

Subsequently, the draft requests:

   If a resolver is multihomed or otherwise has the ability to transmit
   and receive datagrams using more than one IP source address, then an
   IP address can be chosen at random in order to increase an attacker's
   difficulty in guessing what address to flood.

This recommendation is inappropriate.  Source address selection is
governed by specific rules that should not be overridden by this
document.  In particular, RFC 3484 has been written for IPv6 and
entirely dedicated to this topic (and there is work in progress for
a revised version of RFC 3484).

Consequently, the above clause should either be omitted entirely,
or be amended by a qualifying note, e.g.:

   If a resolver is multihomed or otherwise has the ability to transmit
   and receive datagrams using more than one IP source address, then,
|  as far as other standards do not overrule this recommendation, an
   IP address can be chosen at random in order to increase an attacker's
   difficulty in guessing what address to flood.

(10)  Section 9 -- further minor issues

a)  The IETF has reached consensus to spell IP Security as "IPsec",
    thus please     s/IPSEC/IPsec/  '

b)  RFC 2401 has been obsoleted long ago by RFC 4301, which in turn
    now should be quoted for IPsec.

(11)  Section 9 -- substantial omission

As already mentioned in item (4) above, I strongly miss emphasis
on the importance of ingress filtering, the single and most simple
measure in defence of many kinds of attacks against many services
in the Internet.

So please add to Section 9 another strong recommendation for
adherence to RFC 2827 and RFC 3013, and add BCP 84, RFC 3704,
to the list of fundamental references for this topic.

(12)  Section 10 -- editorial

in the 3rd paragraph, the comma is inappropriate and should be replaced
by a semicolon (or a full-stop):

   This document directly impacts the security of the Domain Name
   System, implementers are urged to follow its recommendations.
---
   This document directly impacts the security of the Domain Name
   System; implementers are urged to follow its recommendations.

or:

   This document directly impacts the security of the Domain Name
   System.  Implementers are urged to follow its recommendations.

(13)  Section 12

Apparently, not all references listed there are truly Normative.

So please split off this section in Normative and Informative.

In particular, references
-  [RFC2821],
-  [RFC3833], and
-  [vu-457875]
are clearly Informative.
I personally would also demote
-  [RFC2401] (or better: [RFC4301] -- see above),
-  [RFC2845] (and SIG(0) mentioned by others as missing),
-  [RFC2827], and
-  [RFC3013]
to Informative.

(14)  Further Reference

Finally, I suggest adding an Informative Reference to
<draft-ietf-tsvwg-port-randomization>
for practices for source port randomization
(already close to WGLC, if I recall things the right way).

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

----- End of forwarded message from Alfred Hönes -----

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>