Re: rfc4941bis: temporary addresses as "outgoing-only"?

Gyan Mishra <> Tue, 11 February 2020 00:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A95AB1208A2 for <>; Mon, 10 Feb 2020 16:18:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oOxtKCenhfVd for <>; Mon, 10 Feb 2020 16:18:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8636F12089F for <>; Mon, 10 Feb 2020 16:18:04 -0800 (PST)
Received: by with SMTP id b15so1937115iln.3 for <>; Mon, 10 Feb 2020 16:18:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e2zffOEiJ4aFdZ/yJYkBK5Ju7GWAAcADs3W/mGorTYc=; b=QI9YtseI3weGFJj8CuV6UVDyeqjIkhNHsSlkN1Mcti3oDPjSW3L57l1g/EgQb4Ra1c FYvAv3GCB8Yamrv2wHDdFHqe5OffOxhjmQK0B9emfG3XTAGo6ptLkSAZXEusW9rFR0Us T9BfcEEEqn8R8Yn1QMfB1gj5cV2zAilWVqJDcb29WF0cf0jxdk27JQ1Gc49+AL7nEWso lRi2N5Z3x3u4dOnEPB5A/AHyIzDlsFXfq5yiA8RhOOy0biUmuER4MZEtP0Za2PgoIF25 XDyYSkY/wu7HJwVQJXWhZXjznama68zsTp/Cw5DDBBhF11FcgFy0wuSJJckMlai7jkpM Yebg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e2zffOEiJ4aFdZ/yJYkBK5Ju7GWAAcADs3W/mGorTYc=; b=iXdAVnVWm+ndP0Q93urfOb9SVNlkmi7XzIzqGi09ji4jjZmMwUq2S+UV3tyv4RCKML 5u1fbYXUPprc/rBzXqJersT9cwn4+ns64oCcqCrmiEJseRCKyHRiTAx3FmSnEeBNIJY7 gPQjZ/ySOEsOJPwTn9zo694h9bTEjpxH6WTYd+8B7mS8605y7Qf6uOsXSahprIHzWJb3 mUKm+vyHz/DkGoHpNhZZghyEDF3dWvgkkcDB1FC/6jkWH6zzBL9BwmPtqZUhPu9ZtWSr SNBBLBYjUGJ/3AvtzX76tgg+D2y45efBFLVmbLchguWzlkXLeFHB+48g+S1+GRLsMMhr eweA==
X-Gm-Message-State: APjAAAVte30fU/JtFUbeoifhD4bY4jSkABPr4TTfgBr39w0Yx3W1+hTM i9wrwU21LRz8bMTDSk0jn+HFLX4e1GJoLgs+RG0=
X-Google-Smtp-Source: APXvYqwoI4BJRXXpLQyXTw07vFWzHAMpqQ+pFJRy7v61wOV+74HU/s85RD7AlsFwIg4wqWhF9eDUGJuWt96MwULaaGM=
X-Received: by 2002:a92:350d:: with SMTP id c13mr4210897ila.205.1581380283653; Mon, 10 Feb 2020 16:18:03 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Mon, 10 Feb 2020 19:17:52 -0500
Message-ID: <>
Subject: Re: rfc4941bis: temporary addresses as "outgoing-only"?
To: Fernando Gont <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000000fe3e4059e41ca2c"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Feb 2020 00:18:08 -0000

On Mon, Feb 10, 2020 at 11:12 AM Fernando Gont <>

> Folks,
> Since we are at it, I wonder if rfc4941bis should say anything about the
> use of temporary addresses for incoming connections. (see
> ).
> (e.g., "an implementation MAY....")
> Particularly for connection-oriented protocols, hosts that prevent
> incoming connections on temporary addresses reduce exposure even when
> their temporary addresses become "exposed" by outgoing sessions.
> i.e., if the model is that temporary addresses are employed for outgoing
> connections, unless a host uses temporary-only, there's no reason to
> receive incoming connections on temporary addresses. (e.g., browsing the
> web or sending email should not be an invitation for folks to e.g.
> port-scan you).
> The caveats here are:
> 1) If a host does temporary-only, these are the only addrs you have, and
> hence they should allow incomming connections
> 2) It could be easily done for connection-oriented protocols such as
> TCP, but not so easily (if at all possible) for e.g. connectionless
> protocols.
> As noted in
> , *in theory* there are other ways in which the same effect could be
> achieved... so one could certainly argue that this policy should not be
> enforced on the addresses, but rather we should have a more appropriate
> API that could allow apps to e.g. bind() subsets of all the available
> addresses.
> Thoughts?

  I agree it below makes sense excerpt from the bottom of that section.  So
with temporary address enabled are you stating that the “stable” address is
what we want to use but based on OS implementations they may not always be
the case due to lack of API support.  Is the issue with default source
address selection used which may differ from OS to OS and in that case is
it possible the temporary address could be bound to services thus exposing
the host to attacks.  Kind of defeats the purpose of having a temporary

It really sounds like we desperately need API development.

Binding services only to stable addresses provides a clean separation
   between addresses employed for client-like outgoing connections and
   server-like incoming connections.  However, we currently lack an
   appropriate API for nodes to be able to specify that a socket should
   only be bound to stable addresses.

> Thanks!
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------

Gyan  Mishra

Network Engineering & Technology


Silver Spring, MD 20904

Phone: 301 502-1347