Re: [Dots] Role reversal in RFC7252

Carsten Bormann <cabo@tzi.org> Tue, 12 November 2019 06:58 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2106120132 for <dots@ietfa.amsl.com>; Mon, 11 Nov 2019 22:58:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOgyUtGbeakn for <dots@ietfa.amsl.com>; Mon, 11 Nov 2019 22:58:45 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047691200A4 for <dots@ietf.org>; Mon, 11 Nov 2019 22:58:45 -0800 (PST)
Received: from [192.168.217.102] (p548DC893.dip0.t-ipconnect.de [84.141.200.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47Bz9b11JjzyrG; Tue, 12 Nov 2019 07:58:43 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313622C7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Tue, 12 Nov 2019 07:58:42 +0100
Cc: "dots@ietf.org" <dots@ietf.org>
X-Mao-Original-Outgoing-Id: 595234720.930106-2c87a742a733ef02be595ce7992e5c4f
Content-Transfer-Encoding: quoted-printable
Message-Id: <EF3006CC-D9A3-47E5-AA80-FF21701750EC@tzi.org>
References: <787AE7BB302AE849A7480A190F8B93303135F7FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7A790E73-62A3-46CE-B821-25B315CBC269@tzi.org> <787AE7BB302AE849A7480A190F8B9330313622C7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/fCyXVfgAQ9rpU1zrag_XRihAxYo>
Subject: Re: [Dots] Role reversal in RFC7252
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2019 06:58:48 -0000

On Nov 12, 2019, at 07:40, <mohamed.boucadair@orange.com>; <mohamed.boucadair@orange.com>; wrote:
> 
> Hi Carsten, 
> 
> Fully agree if we model an endpoint as both a client and server.
> 
> The concern I had is when we want to model an endpoint solely as an “client" (or as a server).

The question is why you would want to do this.

The main point about a server is that its transport address (IP address + port number) needs to be known to talk to it.  (The client implicitly indicates its transport address in a request, and it only needs to be stable up to a response — which may include an observe notification later.)

So if your clients are hopping around on different addresses, role reversal requires the server-now-client to know the current one.  In a keep alive situation, I’d expect that to be the case, so there is very little against role reversal.

(I’m assuming DOTS environments are NAT free.)

Grüße, Carsten