IETF Logo Mail Archive

Re: [nbs] NBS and TCP connection identification

Christian Vogt <christian.vogt@ericsson.com> Mon, 27 September 2010 22:17 UTC

Return-Path: <christian.vogt@ericsson.com>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC573A6BCF for <nbs@core3.amsl.com>; Mon, 27 Sep 2010 15:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.132
X-Spam-Level:
X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 m+XLpUREwEr9 for <nbs@core3.amsl.com>; Mon, 27 Sep 2010 15:17:11 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 411213A6DD7 for <nbs@ietf.org>; Mon, 27 Sep 2010 15:16:18 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o8RMUQWH008556; Mon, 27 Sep 2010 17:30:27 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.214]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 27 Sep 2010 18:16:51 -0400
From: Christian Vogt <christian.vogt@ericsson.com>
To: Erik Nordmark <erik.nordmark@oracle.com>
Date: Mon, 27 Sep 2010 18:16:50 -0400
Thread-Topic: [nbs] NBS and TCP connection identification
Thread-Index: Acteka8pWiQvUZRBTVK76XgyH1/+AA==
Message-ID: <7C68FB7A-3FE5-481B-A995-EDEB636C6A26@ericsson.com>
References: <4C97D9A8.2050001@oracle.com> <ACE9611A-9107-46EC-ADD2-56E553DC1C3A@ericsson.com> <4C9826D0.2060703@oracle.com>
In-Reply-To: <4C9826D0.2060703@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nbs@ietf.org" <nbs@ietf.org>
Subject: Re: [nbs] NBS and TCP connection identification
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Sep 2010 22:17:15 -0000

Erik Nordmark wrote:

> Clearly the responder can't do a forward lookup when it receives a SYN packet, because that can be used to DoS the responder out of existence.


We thought about this and figured that one could approach the problem in one of the following two ways:

- Have the responder perform a forward DNS lookup as long as the responder has the resources to do so -- i.e., as long as the responder is not under attack.  If the responder does not have the resources, it will deliver a synthesized DNS name, not the initiator's real DNS name, to the application.  This synthesized DNS name will encode the initiator's IP address.

- Have the responder always deliver a synthesized DNS name to the application.  The API could additionally give the responder the possibility to translate this synthesized DNS name to the initiator's real DNS name, if one is registered in the DNS.  Since the latter would be an application-triggered action, it wouldn't imply the security threat in question.

Do you have a preference on one of these two approaches?

- Christian

v2.23.0 | Report a Bug | By Email