Re: Magnus Westerlund's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

Fernando Gont <fgont@si6networks.com> Thu, 22 October 2020 14:52 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 26CFE3A0F7F; Thu, 22 Oct 2020 07:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Level:
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 jVmWiRdNW6mK; Thu, 22 Oct 2020 07:51:57 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3003A0F0F; Thu, 22 Oct 2020 07:51:53 -0700 (PDT)
Received: from [10.0.0.134] (unknown [186.19.8.47]) (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 9DE25283707; Thu, 22 Oct 2020 14:51:49 +0000 (UTC)
Subject: Re: Magnus Westerlund's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-rfc4941bis@ietf.org, 6man-chairs@ietf.org, ipv6@ietf.org, Ole Trøan <otroan@employees.org>
References: <160335500152.2379.13344186464354332427@ietfa.amsl.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <db074a10-8feb-3fc3-4e1a-910674e8628d@si6networks.com>
Date: Thu, 22 Oct 2020 11:44:21 -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: <160335500152.2379.13344186464354332427@ietfa.amsl.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/Vh_R_Ew-tfeDf7f6ybkKuCWoSDM>
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: Thu, 22 Oct 2020 14:52:02 -0000

Hello, Magnus,

Thanks so much for your review! In-line....

On 22/10/20 05:23, Magnus Westerlund via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I understand that this is an update of an older document resolving several
> important issues. However, what was advanced traffic analysis 10 years ago is
> not as advanced today. The security consideration discuss some of the weakness.
> To me it appears that there are significant risks of correlation old temporary
> address passed preferred life time with the new preferred temporary address.

How would you do this at the address level? (caveat: if you do it at an 
upper layer, I'd probably say that this is mentioned both in the 
Security Considerations and in the discussion on persitent IDs earlier 
on in the document).


> Especially if an attacker can trigger an endpoint reconnecting to a site where
> the previous temporary address was used and thus correlate the attempt to force
> reconnection combined detected use of a new temporary address to the same
> destination. It might even be another destination but associated with the same
> remote site.

If the correlation happens at a higher layer, that's indeed possible -- 
but out of the scope of this particular work.



> I have not putt this on discuss level, but my impression is that although
> beneficial the strength of its protection might be overstated in the various
> statements.

Please do let us know if you think that there's more that is to be 
added, and if you have any suggestions.

Thanks!

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