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

Mark Smith <markzzzsmith@gmail.com> Tue, 11 February 2020 02:10 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8803E1200B6 for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 18:10:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 mor0b2qv5GI8 for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 18:10:31 -0800 (PST)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B474C12008C for <6man@ietf.org>; Mon, 10 Feb 2020 18:10:31 -0800 (PST)
Received: by mail-oi1-x22c.google.com with SMTP id d62so11298789oia.11 for <6man@ietf.org>; Mon, 10 Feb 2020 18:10:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uVykGo0hCDMTG/Lx72i3488aAa6d6mYArKvLCn8+RgM=; b=q8Tmm5ZVWrM3n+OKR8NSHJGfXIh0b8MpHseP6e8duktm+l242HtEVYYf+TfF8F/0sO Q8qT0QAa0Gtme+iuTzbNt3gGa6c1abUEhir1fYyE8kNJiptRU/rwCyMAjF5LWi9F2Xxo eWZh4VJ40yCwcEG0NmXN27sC7XGUfKcz9lqsSqcOqAg1jkG2i9j0U0d2ES1GwBqSBQ4M 4v1w/EcRXs85m8BH3f223/bIqOB1oAEYoEG2z1PUyJ1trk+dVWldRaMeEQS83UCHp2yy 7NqmMrDf948Y/YVq2+h8a7jPHdyAS56IUA6KWA4UvDcEnZcU5dZLPV88iCZizkj3oZsW V82Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uVykGo0hCDMTG/Lx72i3488aAa6d6mYArKvLCn8+RgM=; b=Vn9Gb9cJWU4xbGCedrOa/ZifNsl6/E1CF4s01DicDE3Ukx6VjKHzc9JrEU9tkibXuO cYmCQo9Iqu73GedMunBWR/GC7qcEUcEu4X6ckPxrcthLjsCWzgapUaVAevUcHjKfdds+ p5ESQ9DyEPw5oLws+bFH6iF9mKRZAXKR94AhatKeXEou3ynYzU96zECL0LG1UaNh+gMI CRWyCRQ8Ge00eFvke9qF6WbInVjK+vQufkP/BjRza5hnbgNbIyqjar0S/iAC8O5Z46cv +jleWohiH9nOhDRQ18Dx5WTCV5ZS53ENi4yfdi9dVtLhGXKhEPkmm2JHl/KLAbRe2qLp WB7Q==
X-Gm-Message-State: APjAAAUjHZmskW2eVLxv994FQkqccZuLA84Fiu4OdRzZ+trwc007SUkV 47AFXhmrcJdbZjwAPop91d1/zCSiqgIw4/jr0m0=
X-Google-Smtp-Source: APXvYqzs51jYTEVHOKn6+oPgxYkvZ8FTLbCA4I8/PeEk9DDG7LougYR9gYcKep2M6OVxlX3I5vaIKbRFQ5FYQ1sBuzs=
X-Received: by 2002:aca:62c4:: with SMTP id w187mr1484740oib.38.1581387031029; Mon, 10 Feb 2020 18:10:31 -0800 (PST)
MIME-Version: 1.0
References: <3217323b-3d8b-bf75-b5b0-ffdd01ee1501@si6networks.com> <CAO42Z2xtvjo_RO7kNsFCi4=S0TJKRest-8fEkvnwbC3rBNAj0A@mail.gmail.com> <ac38ca41-a148-470a-d2ba-26649f77e2f8@gmail.com>
In-Reply-To: <ac38ca41-a148-470a-d2ba-26649f77e2f8@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 11 Feb 2020 13:10:18 +1100
Message-ID: <CAO42Z2xjOQV6yF8m203B33+dm5Ha1c126ukW=oRSUd2OSa0O6w@mail.gmail.com>
Subject: Re: rfc4941bis: temporary addresses as "outgoing-only"?
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Fernando Gont <fgont@si6networks.com>, 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003cabeb059e435ca9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/R7rzBx6LIujTiiXMoFWtI4W8Q3w>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2020 02:10:33 -0000

On Tue, 11 Feb 2020, 09:17 Brian E Carpenter, <brian.e.carpenter@gmail.com>
wrote:

> On 11-Feb-20 09:46, Mark Smith wrote:
> >
> >
> > On Tue, 11 Feb 2020, 03:13 Fernando Gont, <fgont@si6networks.com
> <mailto:fgont@si6networks.com>> wrote:
> >
> >     Folks,
> >
> >     Since we are at it, I wonder if rfc4941bis should say anything about
> the
> >     use of temporary addresses for incoming connections. (see
> >
> https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-04#section-4.3
> ).
> >     (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).
> >
> >
> > This would prevent peer-to-peer connections between end-user devices, as
> it means devices become clients only, and they therefore cannot provide a
> temporary server/service.
>
> If a node has a stable address as well as a temporary address, that isn't
> the case.


True, however one of the goals of this update is to allow temporary address
only nodes, removing the assumption that hosts with temporary addresses
will also always have a stable address.


However, I think it is rather out of scope for 6man to regulate this point.


Yes, I agree it is out of scope for 6man.

Although it is common to imagine devices as "clients" or "servers", those
definitions are really only application layer roles and definitions. A
device might be a client for one running application and a server for
another.

It may also be a peer for another running application, because it both uses
and provides services to other instances of the application residing on
other hosts.

At the transport and network layers below, end points are peers.


Regards,
Mark.



What might be good, but is also probably out of scope,
> is a socket option to allow/disallow incoming connections to temp
> addresses, and a socket error code if they are disallowed and an upper
> layer tries to bind a socket to a temp address.
>
>     Brian
>
> >
> > So, for example, ad hoc file transfer applications like AirDrop couldn't
> work on a temporary address only and client-only end-user device.
> >
> > https://en.m.wikipedia.org/wiki/AirDrop
> >
> >
> > Peer-to-peer application communications architectures have the node
> effectively act as both a client and server at the same time, providing and
> receiving service concurrently.
> >
> > A temporary "server"/service is useful and valid, the privacy issue for
> end-user devices comes about if the server/service had a permanent unique
> address or IID.
> >
> > Forcing end-user devices to be clients only is actually the fundamental
> constraint that NAT has imposed on IPv4. Certain applications for which
> peer-to-peer communications architectures would be better are forced to
> adopt a client/server communication architecture just to be able to work in
> the presence of NAT.
> >
> > Regards,
> > Mark.
> >
> >
> >
> >
> >
> >     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
> >
> https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-04#section-4.3
> >     , *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?
> >
> >     Thanks!
> >
> >     Cheers,
> >     --
> >     Fernando Gont
> >     SI6 Networks
> >     e-mail: fgont@si6networks.com <mailto:fgont@si6networks.com>
> >     PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
> >
> >     --------------------------------------------------------------------
> >     IETF IPv6 working group mailing list
> >     ipv6@ietf.org <mailto:ipv6@ietf.org>
> >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >     --------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
>