Re: [lisp] Roman Danyliw's Discuss on draft-ietf-lisp-6834bis-12: (with DISCUSS and COMMENT)
Alvaro Retana <aretana.ietf@gmail.com> Thu, 16 June 2022 13:24 UTC
Return-Path: <aretana.ietf@gmail.com>
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 7B779C14F743; Thu, 16 Jun 2022 06:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lXGXarOoknqe; Thu, 16 Jun 2022 06:23:59 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 7B9C4C14F722; Thu, 16 Jun 2022 06:23:59 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id p6-20020a05600c1d8600b0039c630b8d96so3305812wms.1; Thu, 16 Jun 2022 06:23:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=zhTOEW0ZWrZqb4TkwwYe8lRxxyd2+ldWtPDMEDWuYYY=; b=j8gXhpw6Ly8rp0wFlvP2ZNWzcV+y/ibdsCGa7upsah8uo2S7z+gZEz8U/H56MZgImr fqHBiiqkOKPH39YYmIixxsyNsY2r6p7fpneBc2F4ib36MypG2bl3OlVSpWp2GBni66cI BK4H04XNaiHkQWvNLgCMtlNeN93sh3N5Ogt5vfYTt96oAf8CMNA65orEpkdC0shy/Ndu LQi4NuEBV+iavoWsAEhMX2XtaAG4fiu+FXEFnDhqHI49RohiscHtI7MEix2IgvES2GAd IRRXGfb9V+EAqbPOx1+a5ttXchyLEbqQczH6pnsiM/oNB7DEmfeT9vVt6/FcFMk4t1g4 Wx3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=zhTOEW0ZWrZqb4TkwwYe8lRxxyd2+ldWtPDMEDWuYYY=; b=MDh4wUxKSD1SUZNB5BODNIy8c+IP9mK/1ginJWpb16oEKwU5FmwrKWhKoQw+QRUKOV uRvgJ/9e30HKg9ZwGcH8q/wXL+tmtVqueMgNGqENK/kwwvsZ6wvizH/Yrqf6Rd9YJuL3 3AvzKNey8BjcDprGCSbS4n+h7oalJkUGZeb91y7SHBZYAR2Vmyk/r+8oBXpRl3miUotK odCHJNatjuJqHU0yVkNkgXQWDlKlRrvaZDVQP1xRZ4ESL4x+Fv4IrPlmdXs890F6D+ge XON/M8tSfsuKsaPp67JhBq1vJs9IgpvmUjsL8m7JQ+/pTNUwultRvs1oLkKSo0TAZB3a oadA==
X-Gm-Message-State: AJIora+r551NioWWQTcKH3M3xBUay9yHNXCKBwSnjo//IeNPzRcWP1Q3 A0ipq+ZgtdMLC/KBmH7cDLiNzWefOqMA9STz4uQ=
X-Google-Smtp-Source: AGRyM1sSRY2M7ilA6ag5OAPvHA1yyuHXDdk94hag1tI0VhXZnWe6lTmjyCK/6T5RWN5lwJq6Em9HfPNmn68SSJn5Qok=
X-Received: by 2002:a05:600c:ac4:b0:39c:4f54:9c5f with SMTP id c4-20020a05600c0ac400b0039c4f549c5fmr4892287wmr.135.1655385837599; Thu, 16 Jun 2022 06:23:57 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 16 Jun 2022 08:23:56 -0500
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <ACF25D3F-DF8B-44E9-9C6B-0753ACB163A8@gigix.net>
References: <165410969249.3358.8914059517324092461@ietfa.amsl.com> <ACF25D3F-DF8B-44E9-9C6B-0753ACB163A8@gigix.net>
MIME-Version: 1.0
Date: Thu, 16 Jun 2022 08:23:56 -0500
Message-ID: <CAMMESswSegvpw+oTpWxfwY1xU_N_6GyXcaFC+p0hgqkRZZwApg@mail.gmail.com>
To: Luigi Iannone <ggx@gigix.net>, Roman Danyliw <rdd@cert.org>
Cc: "lisp@ietf.org list" <lisp@ietf.org>, Padma Pillay-Esnault <padma.ietf@gmail.com>, draft-ietf-lisp-6834bis@ietf.org, The IESG <iesg@ietf.org>, lisp-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d1064505e1908c62"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/fkSv-CY0De32OWUJjNI3O4hVcgM>
Subject: Re: [lisp] Roman Danyliw's Discuss on draft-ietf-lisp-6834bis-12: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 16 Jun 2022 13:24:01 -0000
Hi roman! Can you please take.a look at -13? Does it address your concerns? As Luigi mentioned, we were discussing some of the same text with Donald in the SECDIR review thread [1]. You might also want to follow up there. Thanks! Alvaro. [1] https://mailarchive.ietf.org/arch/msg/last-call/GHK4uqFcppRSSdbzvzQxQJj0p0A/ On June 2, 2022 at 7:40:50 AM, Luigi Iannone (ggx@gigix.net) wrote: Hi Roman, Thank you very much for your review. Please see my comments inline. On 1 Jun 2022, at 20:54, Roman Danyliw via Datatracker <noreply@ietf.org> wrote: Roman Danyliw has entered the following ballot position for draft-ietf-lisp-6834bis-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-6834bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- On the -11 document, I initial wrote the following: The SECDIR review by Donald Eastlake asked about handling roll-over/wrap-around of the Map Version Number. Specifically, can a “Map Version Number advance[e] … so quickly that an old version number is encountered that appears to be newer than or equal to the current version number. Why can't this happen? Or if it can, why doesn't that hurt?” It would appear that a number of the conclusions of the ITR or ETR on arriving packets in Section 7.1 and 7.2 wouldn’t be correct. I then saw the -12 document published on June 1 which added the following text to Section 7: Map Version Number incrementing and mappings' TTL MUST be managed so that an old version number will not be confused as a new version number. Thank you for adding this text. Practically, this identifies the desired intent, but doesn’t seem describe the mechanics. Yes, you are right. We were discussing this with Donald and Alvaro as well. Can more be said about how this confusion will be mitigated at the ITR/ETRs? I also don't follow how to use the TTLs here. In revision -13 the previous text has been changed in: 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 <xref target="I-D.ietf-lisp-rfc6833bis"/>). Do you consider this text enough? Consider the situation that Donald noted where the Map Version advanced so quickly that it wraps around so that: (a) the new Map Version Number value equals the old Map Version Number. If one followed the guidance in Section 7.1 of: 1. The packet arrives with the same Dest Map-Version number stored in the EID-to-RLOC Database. This is the regular case. The ITR sending the packet has in its EID-to-RLOC Map-Cache an up-to-date mapping. No further actions are needed. It would seem that the ITR wouldn’t do a Map-Request and would misroute the packet based on the old mapping. That is correct. But if you operate as suggested in the new text this situation will not happen. (b) the new Map Version Number is now smaller (but in fact fresher/newer) If one followed the guidance of Section 7.1. of: 3. The packets arrive with a Dest Map-Version number smaller (i.e., older) than the one stored in the EID-to-RLOC Database. This means that the ITR sending the packet has an old mapping in its EID-to-RLOC Map-Cache containing stale information. Per bullet #3, if there was wrap-around would the ITR in fact be sending stale mapping information? This is just me overlooking previous comments. The text should be in the same form as the second bullet. In revision -13 it is now: The packet arrives with a Dest Map-Version number older (as defined in Section 6) than the one stored in the EID-to-RLOC Database. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Donald Eastlake for the SECDIR review. I support Paul Wouter’s DISCUSS position. IMO that DISCUSS was fixed in revision -12 already. I copy at the end of this mail my answer to Paul (I did not receive anything back from him yet). Thanks again. Please let me know if revision -13 addresses your concerns. Ciao Luigi ----------------- Hi Paul, I understand the concerns, but I think you did not read revision -12 of the document. Please see inline. On 1 Jun 2022, at 17:43, Paul Wouters via Datatracker <noreply@ietf.org> wrote: Paul Wouters has entered the following ballot position for draft-ietf-lisp-6834bis-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-6834bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Changed my comments to a DISCUSS, as Donald Eastlake also pointed these out in his secdir review, and I am now convinced we need better text to address this. #1 map-version rollover is defined (to skip the 0 version) but I also see: The packet arrives with a Dest Map-Version number greater (i.e., newer) than the one stored in the EID-to-RLOC Database. Since the ETR is authoritative on the mapping, meaning that the Map- Version number of its mapping is the correct one This would imply rollover to a smaller number is not expected to occur ? The text is now: The packet arrives with a Dest Map-Version number newer (as defined in Section 6 <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-6834bis-12#section-6>) than the one stored in the EID-to-RLOC Database. Since the ETR is authoritative on the mapping, meaning that the Map-Version number of its mapping is the correct one, this implies that someone is not behaving correctly with respect to the specifications. In this case, the packet carries a version number that is not valid and packet MUST be silently dropped. #2 MUST NOT or SHOULD ? Map-Versioning MUST NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments. This sentence seems to contradict itself. I would turn the SHOULD into a MUST The first paragraph of Section 8 “Security Considerations” is now: This document builds on the specification and operation of the LISP control and data planes. The Security Considerations of [I-D.ietf-lisp-rfc6830bis <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-6834bis-12#ref-I-D.ietf-lisp-rfc6830bis>] and [I-D.ietf-lisp-rfc6833bis <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-6834bis-12#ref-I-D.ietf-lisp-rfc6833bis>] apply and, as such, Map-Versioning MUST NOT be used over the public Internet and MUST only be used in trusted and closed deployments. A thorough security analysis of LISP is documented in [RFC7835 <https://datatracker.ietf.org/doc/html/rfc7835>]. As you can see the SHOULD is already changed in a MUST. Do you consider that the above address your concerns? Ciao L.
- [lisp] Roman Danyliw's Discuss on draft-ietf-lisp… Roman Danyliw via Datatracker
- Re: [lisp] Roman Danyliw's Discuss on draft-ietf-… Luigi Iannone
- Re: [lisp] Roman Danyliw's Discuss on draft-ietf-… Alvaro Retana
- Re: [lisp] Roman Danyliw's Discuss on draft-ietf-… Roman Danyliw