Subject: Re: Review of draft-ietf-dnsext-forgery-resilience-03.txt

From: Alfred Hönes <[email-masked]>
Date: Thu, 5 Jun 2008 16:00:31 +0200 (MESZ)

At 27 May 2008 11:52:22 +0200, Peter Koch wrote:

>
> this is a review of draft-ietf-dnsext-forgery-resilience-03.txt.
> ...
>
>> 9.  Countermeasures
>> 
>> ...
>> 
>>    Resolver implementations MUST have the ability to:
>> 
>>    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;
>
> Maybe use >= 1024 and give some reasoning for the choice to avoid
> "privileged" ports discussion.  Some ports are definitely bad
> choices (e.g. the "daytime" port) anyway, so starting at 1024 is OK,
> but needs and explanation.

I strongly oppose against this latter proposal, as I already did
(in previous off-list communications) against the draft text.

This 'choice' is a very bad and damaging idea.
Such recommendations violate STD 3 (see below), and system
administrators following such recommendations are the most
effective and annoying, time consuming, single source of
denial-of-service attacks we (and others) suffer from.

All kind of classification of port numbers only concerns *server*
(listen) ports, *not* ephemeral port usage in client-server context.

The misconception I observe in a couple of I-Ds and other
recommendations circulating on the Web is the improper application
of arguments well resonable for *server* port numbers, to *client*
(request source) port numbers as well.

Recurring symptoms:
==================

The user level symptom is inaccessability of Web sites and
bouncing of email after long unsuccessful retries.

Diagnosis has revealed the typical context:

Most NAT/NAPT boxes currently deployed as ISDN or xDSL access
routers randomize an "internal" source port number during
translation to an available "external" port number in a way
that cannot be controlled by the user/administrator.

In a typical SOHO environment, a local "split" DNS server is
used to authoritatively serve local (non-public) zone(s) and
offer recursive caching name service to the local site.
It is common that such DNS servers use the single port 53 for
listening and for sending queries to public DNS servers as well.

In outbound DNS quries, the NAPT substitutes a random value for
the internal source port 53, and many such boxes try to maintain
the 'classification' of the port, effectively choosing an external
source port in the range 1..1023.
[Note that common NAT/NAPT boxes operate a local, low-functionality
DNS resolver as well, and hence *never* translate the internal
source port number 53 identically, because they have an (unbound)
pending local Listen on that port.]

Packet filters denying DNS queries with such source ports
resulting from randomized port mapping make it impossible to
obtain DNS service from the sites that have deployed these filters.
Since most such filters, in violation to the applicable standards,
not even return ICMP error messages, and hence appear as black
holes, legitimate queriers are blocked; in particular Mail Transfer
Agents suffer from repeated timeouts necessitating them to perform
retries for many days, all condemned to ultimate failure.

Many adaptors of such black-holing have been responsive to an
exposition of the problems (delivered via auxiliary channels),
and have removed these filters in the meantime (including the
greatest gTLD operators, and well renowned security businesses),
but at least one important global player is totally irresponsive.

Background:
==========

When symptoms of such behavior first occurred roughly two years ago,
I have performed a complete review of the relevant RFCs to determine
the applicable normative rules.

Major result:

||  There is *no* statement in the DNS specification and more generic
||  specifications restricting the *source* port for DNS queries.

The situation is a bit complicated because STD 3 restricts
almost all discussion of port numbers to TCP and simply refers
to that scattered discussion in its sections on UDP (and DNS).

---- excerpt from RFC 1122 (pg. 77) ----

4. TRANSPORT PROTOCOLS

   4.1  USER DATAGRAM PROTOCOL -- UDP

      4.1.1  INTRODUCTION
         .
         .
      4.1.2  PROTOCOL WALK-THROUGH

         There are no known errors in the specification of UDP.

      4.1.3  SPECIFIC ISSUES

         4.1.3.1  Ports

|           UDP well-known ports follow the same rules as TCP
|           well-known ports; see Section 4.2.2.1 below.

|           If a datagram arrives addressed to a UDP port for which
|           there is no pending LISTEN call, UDP SHOULD send an ICMP
|           Port Unreachable message.

---- end of excerpt from RFC 1122 ----

Therefore, we have to also look into the TCP Standard, RFC 793.

---- excerpt from RFC 793 ----

2.7.  Connection Establishment and Clearing

| TCPs are free to associate ports with processes however they choose.
  However, several basic concepts are necessary in any implementation.
| There must be well-known sockets which the TCP associates only with
| the "appropriate" processes by some means.  We envision that processes
| may "own" ports, and that processes can initiate connections only on
| the ports they own.  (Means for implementing ownership is a local
  issue, but we envision a Request Port user command, or a method of
  uniquely allocating a group of ports to a given process, e.g., by
  associating the high order bits of a port name with a given process.)

---- end of excerpt from RFC 793 ----

---- excerpt from RFC 1122 (pg. 82) ----

   4.2  TRANSMISSION CONTROL PROTOCOL -- TCP

      4.2.1  INTRODUCTION
         .
         .
      4.2.2  PROTOCOL WALK-THROUGH

         4.2.2.1  Well-Known Ports: RFC-793 Section 2.7

            DISCUSSION:
|                TCP reserves port numbers in the range 0-255 for
|                "well-known" ports, used to access services that are
|                standardized across the Internet.  The remainder of the
|                port space can be freely allocated to application
|                processes.  Current well-known port definitions are
                 listed in the RFC entitled "Assigned Numbers"
                 [INTRO:6].  A prerequisite for defining a new well-
                 known port is an RFC documenting the proposed service
                 in enough detail to allow new implementations.

                 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.  For example, reserved ports might fall
                 between 256 and some system-dependent upper limit.
|                Some systems further choose to protect well-known and
|                reserved ports by permitting only privileged users to
|                open TCP connections with those port values.  This is
|                perfectly reasonable as long as the host does not
|                assume that all hosts protect their low-numbered ports
|                in this manner.

---- end of excerpt from RFC 1122 (pg. 82) ----

To restate the last sentence using modern (RFC 2119) language:

||  Management and protection of local port ranges is a local issue.
||  Any system MAY manage (low) port numbers as it fits and desires,
||  but it MUST NOT assume that other hosts protect their
||  low-numbered ports in the same manner.

Therefore, any discriminating treatment of particular port ranges
used strictly under control of a remote system is not legitimate.

Filtering query-response traffic at the server site based on
query source port is an instance of such illegitimate behavior.

Conclusion:
==========

I therefore request that, for conformance with STD 3,
the above quoted bullet of Section 9 of
draft-ietf-dnsext-forgery-resilience-03 be changed to say:

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

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

--
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/>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Jun 2008 09:41:14 +1000

> (in previous off-list communications) against the draft text.
	I don't see your problem.  The above is setting a minimum
	requirement.  If you want to make all ports available as
	source ports you are free to do so.

	I also does not say source ports are restricted to port 53
	or ports >= 1024.

	There are plenty of firewalls that don't allow queries from
	port 53 in (let alone any other port below 1024) just as
	there are still some firewalls that only allow queries from
	port 53 in.

	If you offer a service then you shouldn't care which port
	the query is sourced from.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 6 Jun 2008 09:42:50 +0200 (MESZ)

>     the query is sourced from.

That's the point.

My concern is that any clause in a future RFC like the above
quoted bullet in the DNS forgery resilience draft will be taken
by some folks as an easy excuse for not supporting that latter
statement.

This is not a theoretical assumption; I already had enough trouble
with admins arguing based on similar clauses in some dnsop related
drafts in support of, and as a rationale for, the DNS blackholes
they had deployed.

That's the reason why I hope for a more neutral clause in the

>     Mark

  Alfred.

--