Re: [lisp] Roman Danyliw's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)

Albert Cabellos <> Fri, 31 July 2020 12:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46F663A0916; Fri, 31 Jul 2020 05:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HBkgUNjIJsF6; Fri, 31 Jul 2020 05:33:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAAB53A0912; Fri, 31 Jul 2020 05:33:57 -0700 (PDT)
Received: by with SMTP id di22so15075211edb.12; Fri, 31 Jul 2020 05:33:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Yq847ROyEAnnINaHBkiA1BVQsXXXf0boOtbXn3FuVo=; b=oX/x981TCW+MvoHhofj1M++3GhUd3/guD9dfXTtITdxQso4mzgypwUL749n39g+LqI 3gO9kZIQfj5k1xKn/ZtxIJS30bHsOCFsRXbYWoGn3eSy+gsXtnqpae/e+NRVq87a5dGi mrxmsPL6wIOTuaxWRQxPq2Xz4lf0a+5E0/BCRH8K407Rq/0coFlJ1xVQzq9vFR/ttzwu V+/IWh2C6IEt/nhTKl06LV3LIfGj0bvsTnkfpfj6f7G6AMmrnOQEievQrkQVrHUjpuAk BHSiJMmnLWb+S7ZR+90dIbsMpam8kHHWzsJa8RNKiZJxVW/2QgE4Ay9DJ197kkZZReWC 4TNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Yq847ROyEAnnINaHBkiA1BVQsXXXf0boOtbXn3FuVo=; b=JycA8ABEBPfqXjQ5UPrEeImVyCfNgrCU0b87WqvOkUmJDfFHNh7hJcjKIcaduyrfbl paH7Xqrw7tKHm9opwmqDqYrEmH5GHQrkQ7TEmrK2COtQ6d1EddKdvVGgeiiq2dm9NKzd of+i4dKXydILHPa3TRq0OCPvDwSVmAa1DJvmhqAvZH2EGKvSD04FdYqtCmqPA3d05KEN 5vySX9s0tAwJV1IEIqOjzrtfXEVP8F9FJNIsWc1mrrs5gNIriEpjSI3R09gtsNL92Udt 7ENlPbuwu+5YrJpq/iJWipF8RQn0M3RsCdA0DR0MMYAJhuRlGM8WZZb3Ls2TRg2w2FnN 1Z5A==
X-Gm-Message-State: AOAM532SflMev6PUyMNZes94a5W1pkVOi7q+SzbNkvDSPwQj+eEFObI3 YFiwYEYhUzpCbE4uCLTUl4/8ukt2JwNyaTB2FgQk5kAH22U=
X-Google-Smtp-Source: ABdhPJyLp72ldfaXRSM+7Ck98woyqkjIsyDQ28MiIiKoZc/SFBRJDhKXDMxIi9QpFhp1Ssxx3udNMPPG8lSVORdl4cg=
X-Received: by 2002:a50:af86:: with SMTP id h6mr3798270edd.132.1596198836336; Fri, 31 Jul 2020 05:33:56 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Albert Cabellos <>
Date: Fri, 31 Jul 2020 14:33:45 +0200
Message-ID: <>
To: Roman Danyliw <>
Cc: The IESG <>,,, " list" <>, Luigi Iannone <>
Content-Type: multipart/alternative; boundary="000000000000a17c6f05abbc0045"
Archived-At: <>
Subject: Re: [lisp] Roman Danyliw's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
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: Fri, 31 Jul 2020 12:34:00 -0000


Thanks for your comments, we have updated the draft accordingly (-28):

Find below the specific changes and responses to your comments:

On Wed, Jul 8, 2020 at 12:04 AM Roman Danyliw via Datatracker <> wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-lisp-rfc6830bis-32: 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 IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ** Section 1.1. The applicability statement of “large set of cooperating
> entities seeking to communicate over the public Internet or other large
> underlay IP infrastructures” seems inconsistent with many of the protocol
> mechanics described.  Specifically, most of the capabilities in the LISP
> (Locator-Status-Bits, Echo-nonce mechanism, Map-Versioning, Instance ID)
> the “Gleaning mechanism” are explicitly noted as not being suitable for
> Internet use.  This section needs to be explicit that only a subset of the
> protocol is suitable for the Internet.  Likewise, it should be clearer
> what is assumed elements of the closed network are trusted for what
> behaviors.

 We have added this to the following new section (section 4.1):

4.1.  Deployment on the Public Internet
   Several of the mechanisms in this document are intended for
   deployment in controlled, trusted environments, and are insecure for
   use over the public Internet.  In particular, on the public internet
   o  MUST set the N, L, E, and V bits in the LISP header (Section 5.1)
      to zero.
   o  MUST NOT use Locator-Status-Bits and echo-nonce, as described in
      Section 10 for Routing Locator Reachability.  Instead MUST rely
      solely on control-plane methods.
   o  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
      as described in Section 13 to update the EID-to-RLOC Mappings.
      Instead relying solely on control-plane methods.

> ** Section 16. Per “Locator-Status-Bits, echo-nonce and map-versioning

> NOT be used over the public Internet and SHOULD only be used in trusted

> closed deployments” -- not disagreement.  However, under what
> would they be used on the internet to warrant a SHOULD NOT instead of a
> stronger MUST NOT?

Gleaning, Locator-Status-Bits, echo-nonce and Map-Versioning elevated to

> ** Section 8.  Per “Participants within a LISP deployment must agree on
> meaning of Instance ID values.  The source and destination EIDs MUST
belong to
> the same Instance ID.”  Could parties agree that the Instance ID is
802.1Q tags
> and send those across the internet?  Recommend stronger cautionary
language on
> using Instance ID.

We don´t want to specifically restrict communications between different
Instance IDs, this is up to the deployer. Yes, Instance ID can be used to
carry 802.1Q tags, this is an example stated in the document.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you for being responsive to the prior security feedback from the
> (and thanks to Kyle Rose for performing it) and Security ADs in the
return of
> this document to the telechat.
> I support Martin Duke’s DISCUSS position and endorse the creation of a
> dedicated section covering which protocol features should not be used on
> internet.
> **  Section 4.0.  Per “… this document recommends that a maximum of two
> headers …”, should a normative RECOMMENDED be used here instead?

Changed, thanks

> ** Section 5.3. Per “However, the same nonce can be used for a period of
> when encapsulating to the same ETR.”, should this be bounded, even
> qualitatively?

I have removed this sentence, so the same nonce can not be used when
encapsulating to the same ETR.

> ** Section 9.
>       A
>       "gleaned" Map-Cache entry is only stored and used for a few
>       seconds, pending verification.  Verification is performed by
>       sending a Map-Request to the source EID (the inner-header IP
>       source address) of the received encapsulated packet.
> -- Is there any more precision that could be provided about the cache
> beyond “a few seconds”
> -- Should normative language be provided that this cache should be aged
> verification performed?

Changed to:

 “A "gleaned" Map-Cache entry is only stored and used for a RECOMMENDED
period of 3 seconds, pending verification.  Verification MUST be performed
by …”

> ** Editorial Nit
> -- Section 13.2. Typo s/synzhronization/ synchronization/

Changed, thanks!