Re: [lisp] Last Call SECDIR Review of draft-ietf-lisp-6834bis-11

Luigi Iannone <ggx@gigix.net> Wed, 01 June 2022 14:07 UTC

Return-Path: <ggx@gigix.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12145C15AAD4 for <lisp@ietfa.amsl.com>; Wed, 1 Jun 2022 07:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDslTfSdVuEv for <lisp@ietfa.amsl.com>; Wed, 1 Jun 2022 07:06:59 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB83C14CF0F for <lisp@ietf.org>; Wed, 1 Jun 2022 07:06:59 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id d26so2498784wrb.13 for <lisp@ietf.org>; Wed, 01 Jun 2022 07:06:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v69RzmfzbUMG7fbRyVAZkaKEE/X6Lr6FpLDIUTzSUVc=; b=QOVQexNRUSVXCJJFSreXO/2nk8ChuY1Zkcc8ZY2Vo8MgR8adfsKU5/bavH3CkdJNyO uNTRVvrjuY8CXaJQ1ZMm5TZVwV3x9f+2caw0ND+hHJgKa8ejNVvsv4/4FbkeVr+bchIP uQntEK56Uo34KtwQMJeUndBYaIsfyIbpegADzQ8RNlBD3d1da/Osmi0r4WaNdkh1va9N EkR5VMA58Ha73hXESgyBY1k/gWnzlkwp9n1VVhKd0uNAxol9+EoWJ+jT5znyzCNx5j6l nwtYaYnmfzUlSWNCRSZ4TZjpLF59aKqgn02mxIuojANZ+M69FrKSnnv1okqPULlqGR4j G7mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v69RzmfzbUMG7fbRyVAZkaKEE/X6Lr6FpLDIUTzSUVc=; b=7GwCO4S90gv2NY6x1EWsgAjZfUffLWmy6ldObHIVukNTK+C9SWMDPdJcRMJNLzvwRe LSbcig7+3mCgikoNsWhTyXZzQRrg0Y5QcqKlKlXBcfMHQS1XlC4noyDm7M2Ybgor5gbW kERONTNSQBhhEgL4Svn24hcKAgIcHjphODNGDz7UaJoe3GHuWKhdFMCIUmcOljxOpBgr 7a0AvYzjB5ayka+VvZ7C6uPdXhrzpDSIlaTDWGP+sWUm/uHsetzK3UaqVmrAt+Rq73FV d0tc6POOGUlUMsRdf3QV3g3DsPp633QSdpynoLXlEWNwTBvsd3c11kalRlTAtyvjjknQ BrtQ==
X-Gm-Message-State: AOAM533CJlX9Are3BRpT4FUB0knwIr9uU9AOa5IML0bUR2/hRwnC5ipD tWitofv/W+Or7t/hPfGs5+kEWQ==
X-Google-Smtp-Source: ABdhPJwG/DjEftHOYjiSKMO404/AQ1ujZmL7Y9t2KGYKI/zU+iy8b8yj+MVjdNcIxnJXZ76Uck0N9g==
X-Received: by 2002:a05:6000:1786:b0:20e:6267:5700 with SMTP id e6-20020a056000178600b0020e62675700mr53146194wrg.600.1654092417424; Wed, 01 Jun 2022 07:06:57 -0700 (PDT)
Received: from smtpclient.apple ([37.166.188.51]) by smtp.gmail.com with ESMTPSA id ay16-20020a05600c1e1000b0039b17714eb2sm2156133wmb.34.2022.06.01.07.06.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jun 2022 07:06:56 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <1DC6ADC3-3C4B-4B35-886D-473D46ECAF7D@gigix.net>
Date: Wed, 01 Jun 2022 16:06:55 +0200
Cc: Donald Eastlake <d3e3e3@gmail.com>, secdir <secdir@ietf.org>, Last Call <last-call@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-lisp-6834bis.all@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1A548CA-44F0-4ECD-BC57-DF17DF8FD7DA@gigix.net>
References: <CAF4+nEE0UrAhSkUzbWbaoZKvHE_LFs6zmbda3nie=M-EN-XDeg@mail.gmail.com> <542A2E95-C536-43A3-B500-A85D76A62579@gigix.net> <CAF4+nEFHzKCgLBWMT2-WTO0T0vgxpYV1bndsz4HofNKvpYt-2w@mail.gmail.com> <D37B519F-D27B-4584-ADF9-3414968E657A@gigix.net> <CAMMESsxV1RtNebENfx=fkxkz3cCPjK_SbzO6_SzZRtkPFjBuxA@mail.gmail.com> <1DC6ADC3-3C4B-4B35-886D-473D46ECAF7D@gigix.net>
To: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/6SDuW0fnEYeyQoHa0oxkrLILhNY>
Subject: Re: [lisp] Last Call SECDIR Review of draft-ietf-lisp-6834bis-11
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2022 14:07:03 -0000


> On 1 Jun 2022, at 15:46, Luigi Iannone <ggx@gigix.net> wrote:
> 
> Hi Alvaro,
> 
>> On 1 Jun 2022, at 15:29, Alvaro Retana <aretana.ietf@gmail.com> wrote:
>> Nice sentence, but what does it mean?  What action should the
>> implementation take to satisfy "MUST be managed"?  From Luigi's
>> initial response (above), it sounds like the time between changes (TTL
>> ?) has to be long enough...  Please spell some of this out.
>> 
> 
> What if we change to:
> 
> Mapping updates, and their corresponding Map Version Number MUST be managed so
> that  a very old version number will not be confused as a new version number (because of the circular numbering space).
> 

Or may be:

Mapping updates, and their corresponding Map Version Number MUST be managed so
that  a very old version number will not be confused as a new version number 
(because of the circular numbering space). To this end simple measures can be taken, like 
Updating a mapping only when all active traffic is using the latest version, or waiting sufficient time
to be sure that mapping in LISP caches expire, which means waiting at least as much as the mapping Time-To-Live (as defined in 6833bis)   

Any preference?



> Or you consider it too vague?
> 
> Ciao
> 
> L.
> 
>> Thanks!
>> 
>> Alvaro.
>