IETF Logo Mail Archive

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

Fernando Gont <fgont@si6networks.com> Tue, 11 February 2020 05:38 UTC

Return-Path: <fgont@si6networks.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 A4D8912006B for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 21:38:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 RDk2Bv82ZSXc for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 21:38:46 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82AB120041 for <6man@ietf.org>; Mon, 10 Feb 2020 21:38:45 -0800 (PST)
Received: from [192.168.1.29] (host138.200-117-192.telecom.net.ar [200.117.192.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9898A86B57; Tue, 11 Feb 2020 06:38:40 +0100 (CET)
Subject: Re: rfc4941bis: temporary addresses as "outgoing-only"?
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6MAN <6man@ietf.org>
References: <3217323b-3d8b-bf75-b5b0-ffdd01ee1501@si6networks.com> <CAO42Z2xtvjo_RO7kNsFCi4=S0TJKRest-8fEkvnwbC3rBNAj0A@mail.gmail.com> <ac38ca41-a148-470a-d2ba-26649f77e2f8@gmail.com> <992cb8c9-f360-44f1-89fe-ec9b1abd0846@si6networks.com> <CAO42Z2yXxPzhVOyE6NTgn1hHactQXZ0CRsyWZqWjBYEX3b_y9g@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <65587adb-d7f8-5457-b51a-82a9b8582ff7@si6networks.com>
Date: Tue, 11 Feb 2020 02:38:32 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAO42Z2yXxPzhVOyE6NTgn1hHactQXZ0CRsyWZqWjBYEX3b_y9g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tICqnOCHCcIXP-ifasxsSm5i-tg>
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 05:38:49 -0000

On 11/2/20 02:18, Mark Smith wrote:
> On Tue, 11 Feb 2020 at 15:32, Fernando Gont <fgont@si6networks.com> wrote:
>>
>> On 10/2/20 19:17, Brian E Carpenter 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.
>>
>> That's what I had in mind.
>>
> 
> So if we want to support adhoc peer-to-peer file transfers between
> e.g. smartphones via NFC/Bluetooth/Adhoc Wifi, then stable addresses
> are required, even if the file transfer takes say 30 seconds, well
> within the valid lifetime of the RFC4291bis temporary addresses?

I see your point. And if one were to implement this policy, yes, stable 
addresses would be required.

That said, it is clear to me that this is out of scope for this document 
(I just wanted to check with the group). Once again, if we had 
appropriate APIs, applying this sort of policy host-wide wouldn't even 
make sense.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

v2.23.0 | Report a Bug | By Email