ignoring icmp to make dtls work for the stub/RDNS relationship
Paul Vixie <paul@vix.com> Tue, 22 July 2008 08:41 UTC
Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1819228C10D; Tue, 22 Jul 2008 01:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.838
X-Spam-Level:
X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+zgI7vjp3BK; Tue, 22 Jul 2008 01:41:06 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26A2728C106; Tue, 22 Jul 2008 01:41:06 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KLDKl-0003nz-IW for namedroppers-data@psg.com; Tue, 22 Jul 2008 08:34:59 +0000
Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <vixie@vix.com>) id 1KLDKb-0003l0-VT for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 08:34:52 +0000
Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 53314A10FC for <namedroppers@ops.ietf.org>; Tue, 22 Jul 2008 08:34:26 +0000 (UTC) (envelope-from vixie@nsa.vix.com)
From: Paul Vixie <paul@vix.com>
To: namedroppers@ops.ietf.org
Subject: ignoring icmp to make dtls work for the stub/RDNS relationship
X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1
Date: Tue, 22 Jul 2008 08:33:42 +0000
Message-ID: <78908.1216715622@nsa.vix.com>
MIME-Version: 1.0
X-Vix-MailScanner-Information: Please contact the ISP for more information
X-MailScanner-ID: 53314A10FC.8D836
X-Vix-MailScanner: Found to be clean
X-Vix-MailScanner-From: vixie@vix.com
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
i really like the simplicity of the "just use dtls" approach. it can be done without a X.509 certification hierarchy, just ephemeral self-signed certs. it can be done without secrecy-encryption, using the null cipher. there are libraries that implement it on several popular platforms. there is an internet draft. it avoids all questions involving DNS payload or format changes. it would be way easier to implement than TKEY+TSIG, not in processor cycles mind you, but in number of lines of code a DNS guy would have to write. the thing that bothers me about it is fallback, which i consider to be absolutely necessary for universal deployment. fallback has to be made unforceable by an off-path attacker. this means ignoring ICMP (which can be forged) and using long timeouts and/or multiple retries (to outlast congestion based attacks). if i could be sure that ignoring ICMP was possible on all common modern platforms, i'd be willing to suggest the following: ICMP errors must always be sent and must always be seen. that is, before any DNS/DTLS negotiation packet is sent, an ICMP error message must be crafted (in BSD we call this a "raw" socket and it's how the "ping" utility works) and transmitted. and no incoming DTLS negotiation packet would be processed unless it was preceded by an ICMP error. the specific ICMP type and subtype would be chosen pseudorandomly from among a defined set of those which can make recvfrom() return -1. in this way, anyone who isn't prepared to ignore ICMP, can't do DTLS DNS. as an optimization, once someone has proved that they can ignore ICMP by getting beyond the initial session negotiation, these messages can cease to be sent and no longer required. thus normal queries would not have them, nor would session maintainance packets (key rollovers, if any) after the initial setup is complete. what i need to know is, is there at least one common modern platform on which it is not possible to ignore ICMP messages? note, we may have to restrict the transmission of ICMP to just the responder, which is more likely to have the nec'y privileges than is the initiator; and in this case, we'd only require the reception of ICMP in the initiator. this could deserve further study if we get that far. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>