Re: [lisp] Murray Kucherawy's Discuss on draft-ietf-lisp-sec-27: (with DISCUSS and COMMENT)

Luigi Iannone <> Thu, 30 June 2022 12:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8CFBC15C7CA for <>; Thu, 30 Jun 2022 05:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T0b5KBzqnKo6 for <>; Thu, 30 Jun 2022 05:47:09 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id EB596C15A74D for <>; Thu, 30 Jun 2022 05:47:09 -0700 (PDT)
Received: by with SMTP id l2-20020a05600c4f0200b0039c55c50482so1648808wmq.0 for <>; Thu, 30 Jun 2022 05:47:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cq0JGAKhi0CVFctKW2Tj56X5NCzj3+eiM7XWJ6zO0zo=; b=rvGx/LmYrlW7xu/TwovUOXURGMF39QQJpRz2J8uaJyCP6yiRO1Q8vCD85rmYVs5Plb tLMH94Hwb0wb9M0Gq/zCQxBWESaVNZXedsHIEVcpi1BBJsSqpmGO0iWw578yLLLF0doU AqJ1fTWDXMUSGc0jD+peQaBTszleVJXBITLDhB3+5Zt6edmufKhJSZy2cpYcWxSD5nko nm+puZavQIzWu8OUUQkqRHiXo+n7C0K2TvOW7CTt7fHi7HXufxyJC+8kkwd4fAMYtp6y 4OCIH0ulJNhbY0vMUBpi+qUuXoC5qpr+zgU+KqtnYhS5HlwCClGP5UsVDYrGWOKPiBYk qBdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cq0JGAKhi0CVFctKW2Tj56X5NCzj3+eiM7XWJ6zO0zo=; b=Q/iagjT1PtCfXHt35ecdRjk/BUA3Tp9ELFcmHmESWFR0UUMjV3AsfNVFHjxtSreUJJ p7pPJzm9VkjY7f0NCNJqIdZPDyQvy4+Bm7X6XAc9m9VfnwhwnvRXUiQ1OXmWjwk0nMOU uXy3sUiuNnidO2SK7ucjRC7ECGM8MeXm3okrOlDkVxiQDPAalFVPZm0jtb8sYAo6hXQd rpo5N7u90LIk4r2bb9T+X7Gj1FenZ5X2YSEb/jF1oPuW1hUvWUWKG4A3oPb7kxlvCeiC ZSF4WL9PSN1lr6zmwUD65YryBEl4k2Yo9FC1ZOmvwAdtKRy6MA45Gtxbc3SqB3O4fuRO psGQ==
X-Gm-Message-State: AJIora+NupNlt5NSrecKbMyJD1rAgYYJtmz5wePkFMYAIE1CYxhOn0Ad wdKyLiV5XdThp63lUk0EpC6e+A==
X-Google-Smtp-Source: AGRyM1u1KAMWNAtRGdVqZzVr0j93lwxMY3mspKOwmkgj4jXiE0rnnwc0pcBVlFlBk6vbVaZheWFsYQ==
X-Received: by 2002:a05:600c:19c9:b0:39c:72fc:9530 with SMTP id u9-20020a05600c19c900b0039c72fc9530mr10093616wmq.88.1656593227550; Thu, 30 Jun 2022 05:47:07 -0700 (PDT)
Received: from ([]) by with ESMTPSA id x1-20020a1c7c01000000b003a02b135747sm6657614wmc.46.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jun 2022 05:47:06 -0700 (PDT)
From: Luigi Iannone <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0DDCA01E-A986-4A12-BD72-C80277180B84"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Thu, 30 Jun 2022 14:47:05 +0200
In-Reply-To: <>
Cc: The IESG <>,,,
To: Murray Kucherawy <>
References: <>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <>
Subject: Re: [lisp] Murray Kucherawy's Discuss on draft-ietf-lisp-sec-27: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jun 2022 12:47:12 -0000

Hi Murray,

Thanks a lot for your review.
Please see inline.

> On 30 Jun 2022, at 09:29, Murray Kucherawy via Datatracker <> wrote:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-lisp-sec-27: 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 
> for more information about how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Sections 8.1 through 8.5 all create registries with "Specification Required"
> rules.  RFC 8126 says this about "Specification Required":
>   As with Expert Review (Section 4.5), clear guidance to the designated
>   expert should be provided when defining the registry, and thorough
>   understanding of Section 5 is important.
> Only Section 8.5 includes any such guidance.  Is none needed for the other
> four?

Actually all of them need guidance which is basically the same and could be provide at the beginning of the IANA section.

>  Also, I'm having trouble understanding the advice that Section 8.5 does
> give.

The beginning of the IANA section  can be:

IANA is requested to create the sub-registries listed in the
following sections in the "Locator/ID Separation Protocol (LISP)
Parameters" registry.

New values beyond this document have to be assigned according to  the 
"Specification Required" policy defined in [RFC8126]. 
Expert review should assess the security properties of newly added 
functions, so that encryption robustness is remains strong.
For instance, at the time of this writing the use of SHA-256-based functions is 
considered to provide sufficient protection. Consultation with security experts may be needed.

Does the above text look good to you or do you have any suggestion of a better formulation?

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I concur with John; this was generally well-done and easy to understand.  Nice
> work.  A couple of suggestions:
> In Section 6.1 has:
>   E: ETR-Cant-Sign bit.  This bit is set to 1 to signal ...
> I think you mean "If this bit is set to 1, it signals ..." or something
> similar.  Taken literally, the current text means you always set it to 1, but I
> don't think that's what you meant to say.

You are right: it should read:

E: ETR-Cant-Sign bit. If this bit is set to 1, it signals to the ITR
            that at least one of the ETRs authoritative for the EID prefixes
            of this Map-Reply has not enabled LISP-SEC.

> I think the fifth paragraph of Section 6.4 is missing a period or something.  I
> found it hard to parse toward the end.

   The ITR-OTK is wrapped with the algorithm specified by the OTK
   Wrapping ID field.  See Section 6.5 <> for further details on OTK
   encryption.  If the NULL-KEY-WRAP-128 algorithm (see Section 8.4 <>) is
   selected, and no other encryption mechanism (e.g.  DTLS) is enabled
   in the path between the ITR and the Map-Resolver, the Map-Request
   MUST be dropped, and an appropriate log action SHOULD be taken.
   Implementations may include mechanisms (which are beyond the scope of
   this document) to avoid log resource exhaustion attacks.

Two commas and a period were missing…. Does it read better?