Subject: [dnsop] misread the cutoff date/time...

From: Daniel Senie <[email-masked]>
Date: Mon, 25 Oct 2004 10:42:04 -0400

Well, I had put 5PM today in my calendar as the cutoff, and got the 
submission for draft-ietf-dnsop-inaddr-required in at about 10AM :(

The version I was trying to submit is viewable online at:

http://www.senie.com/dan/draft-ietf-dnsop-inaddr-required.txt

I guess folks can read this and discuss at the meeting, and I'll push this 
version into the process once the queue opens up again.

Sorry folks.
-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

   "September 11, 2001, already a day of immeasurable tragedy,
       cannot be the day liberty perished in this country."
                  -- 11th Circuit Court of Appeals 

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Sat, 30 Oct 2004 18:56:38 +0300 (EEST)

> version into the process once the queue opens up again.

Comments below.  In short, I think there are still a couple of too 
strong requirements which should have been removed, but I think a 
document like this will be useful.

Details below.

...

The Domain Name Service has provision for providing mapping of IP
addresses to host names. It is common practice to ensure both name to
address, and address to name mappings are provided for networks. This
practice, while documented, has never been documented as a requirement
placed upon those who control address blocks. This document fills this
gap.

==> 'requirement' ?  This should have been updated... The same here and further
along in the section:

4.1 Delegation Recommendations

Regional Registries and any Local Registries to whom they delegate
should establish and convey a policy to those to whom they delegate
blocks that IN-ADDR mappings are required.  Policies should require
those receiving delegations to provide IN-ADDR service and/or delegate
to downstream customers.

.........

Web sites are in some cases using IN-ADDR checks to verify whether the
client is located within a certain geopolitical entity. This is being
employed for downloads of crypto software, for example, where export of
that software is prohibited to some locales.

==> are these for real?  If they would be serious about these checks, 
they'd just check the IP address against the RIR allocations and 
possibly the RIR->LIR allocations, because DNS operators cannot be 
trusted to deal with this properly.  And what of '.com', '.net' or 
whatever?  Those could reside in the restricted areas as well.

The popular TCP Wrappers program found on most Unix and Linux systems
has options to enforce IN-ADDR checks and to reject any client that does
not resolve.

==> maybe it could be further said here that if the hostnames or domains
(instead of IP addresses; using hostnames is a good idea) are used in tcp
wrappers, the reverse+forward lookups obviously have to exist and match.

Many web servers look up the IN-ADDR of visitors to be used in log
analysis.  This adds to the server load, but in the case of IN-ADDR
unavailability, it can lead to delayed responses for users.

==> do the web servers also perform the forward mapping?  Note that most
*external* log analysers only do the reverse mapping.

Applications SHOULD NOT rely on IN-ADDR for proper operation. The use of
IN-ADDR, sometimes in conjunction with a lookup of the name resulting
from the PTR record provides no real security, can lead to erroneous
results and generally just increases load on DNS servers. Further, in
cases where address block holders fail to properly configure IN-ADDR,
users of those blocks are penalized.

==> you'll need to be careful to be specific when you are talking about
reverse+forward checking, or just reverse lookup.  This was brought up
in IESG evaluation by Thomas Narten on draft-ietf-dnsop-ipv6-dns-issues-10.txt,
so you might want to check how I resolved that particular terminology issue.

    By recommending applications avoid using IN-ADDR as a security
    mechanism this document points out that this practice, despite its
    use by many applications, is an ineffective form of security.
    Applications should use better mechanisms of authentication.

==> this could probably be beefed up better, see e.g.
draft-ietf-dnsop-ipv6-dns-issues-10.txt.  In particular, IMHO it should be noted that:
  1) simple reverse lookup offers no security at all
  2) reverse+forward check is not a true form of security, but could be useful
combined with other forms of checking

editorial
---------

==> some sections are indented, some others are not.  I'd suggest
converting to using a good tool such as xml2rfc to get this right.
Proper indenting helps a lot for readability.

==> a placeholder IANA considerations section needs to be added,
saying that there are no IANA considerations.

                Encouraging the use of DNS IN-ADDR Mapping

==> s/IN-ADDR/Reverse/ (because this covers v6 as well)
There are also numerous similar occurrences throughout the document,
and these should be likewise replaced.

The assignment of blocks of IP Address space was delegated to three

==> s/Address/address/

4. Requirements

==> rename to 'Requirements and Recommendations' or just 
Recommendations.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Sat, 30 Oct 2004 20:53:12 +0300 (EEST)

On Sat, 30 Oct 2004 [email-masked] wrote:
> 	why can't dns operators be trusted?  what do you base your
> 	assertions on?

The example was using DNS lookups for code export controls.

If the code would check, for example, that the reverse records would 
not point to '.ir' (iran), there is nothing to prevent legitimate IP 
address space owners from registering e.g. example.com, example.nu, or 
whatever non-banned domain.

Therefore, reverse(+forward) checking cannot in any way be used to 
check which geographical area you're from.  The IP addresses 
themselves are the best bet for achieving that.

(Maybe 'DNS operators' was a bad word choice.  I wasn't implying that 
the operators of the critical DNS infrastructures (e.g., root, TLD 
servers) could not be trusted; they'll have to be, to a certain extent 
at least.  I was referring to whoever controls the particular reverse 
zone, and the forward zone(s).)

> 	host names are registered in the DNS... just like addresses.
> 	if you can't trust the DNS operators...

The applications are likely very difficult.

If you'd be checking for example, '.ca', then yes, this would be of 
very little usefulness.

But you're checking for example, 'host.domain.ca' or 'domain.ca'.

> 	simple forward lookup offers no security at all.
> 	reverse+forward checking is better than nothing.

Only DNSSEC can help with 'simple forward lookup', and its out of 
scope here.

> 	recent audits suggest that the reverse maps are in
> 	better shape than the forward maps ... which is a
> 	change from previous years.

From the intended "security" perspective, the reverses must be checked 
from the forward tree (due do who controls the data), while forwards 
would only need to checked from the reverse tree if you'd believe the 
forward tree would be used for e.g. DoS misdirection attacks.  And as 
you can do DoS attacks already, this shouldn't be a concern.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 30 Oct 2004 22:28:57 +0300 (EEST)

This is probably the last message from me on this particular subject..

On Sat, 30 Oct 2004 [email-masked] wrote:
> 	DNSSEC is forward/reverse agnostic.
> 	what seems to be missing here is the underlaying
> 	assertion that only one mapping is useful,

Certainly.   Let me try to be more verbose, because I didn't bother to 
write this out at more length first.

'Simple forward lookup' seems to be only useful for "service 
discovery", i.e., finding the address of service X.

There are two main threats one could imagine here:
  1) the requestor thinks the service X is at address A, while the 
correct address is at B.  I.e., someone is doing DNS spoofing, or some 
other tricks like that.  DNSSEC fixes that particular problem, by 
giving the requestor means to assure of the results of the lookup.

  2) that the legitimate owner of the service X is maliciously pointing 
it to another address, rather than the real service, causing some kind 
of unwanted DoS attack on the victim.  Doing reverse lookup after the 
forward lookup could mitigate this risk, (with DNSSEC for both if you 
wanted to be extra careful).

But as I said, I don't think 2) is a real risk, so if you're doing 
just a forward lookup, for service discovery, DNSSEC seems to be 
sufficient to fix your problems.

> 	trusting a node who claims to be, say icbm-launch-control.dod.mil.
> 	might be reasonable if the IP address was in the range 215.0.0.0/8
> 	while it would be more suspect if mapped to 66.198.41.0/24
>
> 	yes, this does bring up whole other issues re routing and route
> 	hijacking - but the point is that it is a simple and useful check
> 	to check -BOTH- forward and reverse maps.  Checking just one
> 	is not in anyway a reasonable security check.

I don't disagree with what you're saying, if it's in the context of 
verifying where the connection attempt (or similar is coming from). 
For the purposes of a simple forward lookup, this is also true in a 
sense, but I don't think it's worth out while, due to 2) above.

> 	who controls what data?  the end system gets to assert a name
> 	regardless of what is in the forward tree.  for packets to flow,
> 	the node must be anchored in the topology and that requires some
> 	ISP hand it an IP address.

If the owner of 1.1.1.1 said he's "president.whitehouse.gov", you 
probably would not believe him, unless you checked 
'president.whitehouse.gov'.  That's because you only "trust" those who 
control the IP topology to be able to say anything about the domains 
that they can prove (at least weakly) to be under their control.

(On the other hand, if you wanted to find where 
'president.whitehouse.gov' is, and the result would be 1.1.1.1, you'd 
likely believe that, regardless of looking up the record for 1.1.1.1.)