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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCC753A0924; Fri, 31 Jul 2020 05:43:53 -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 2zAKB-uTvV86; Fri, 31 Jul 2020 05:43:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 980B63A091C; Fri, 31 Jul 2020 05:43:51 -0700 (PDT)
Received: by with SMTP id d6so17456216ejr.5; Fri, 31 Jul 2020 05:43:51 -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=pifFp6t0uGYaD3EusF0WTnm6zUY3bCyFrI9tbsvboMI=; b=DL7W2SYmTA4DMLS3RKlI1r6knw546tWEFqWn9nd7c93uS00jmvv2cVkKuRe9wPrgHn 2/2HSPWw1CZZ3C3czE7QFL65rWv9wlxqiYF1mb+v7FdO2XHGeZn20S6hTAn/Qcqbv3MF XWEZROoDVLII55G41nwXur0XMca1nTlLXbAroTp+KV/jeRl6lTkK7so6UDMZ+XDQOkBr Lb/x1qtMUI+p9Kt7akphR/V9VTe6mhTBSsmrQuyuF3ayoiCHkF5xOWvuCuK7HP/oQYXr VnJusJKfw9K0tzPV7Hu7z+JEkakeLX4bjU/ghhcKsJl2UFg1kFU6X9PNolkthdZYfCh8 VefA==
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=pifFp6t0uGYaD3EusF0WTnm6zUY3bCyFrI9tbsvboMI=; b=E1VnIFodFsM1Y+mOj6QobGUtuSeY6wxFhEUpS3c2kzr5IK8igZLofteXSiZcKgDJ/z 3MqfLDvLi0dXPGnXhc4ZQz+oAzVDaq/XGXUbEdHDNCbjpjCf/eKSjzSe98xjhIAEaMOH XeIHm8LISASPQNC7xMx0gIKSiUYDtiQMxmsDDhT6VlSth45e5zDYRM/40XvP0ocIxR2n qncp7VmjVxodVVJL4MzzdC6BQ/YPZGH3ockKlwZaEjShwkvUONu3iE48RoVO+jjIY+Wl HYjLozaeqQN8EL5sTyaqmx+XMFXOL59q60un6i2OYDsMWAZUK5DTebVDlONmIk8vCMYB DB2Q==
X-Gm-Message-State: AOAM533qXgwX0UXn0d0ZppL9uoCTLuSUCSPSitR/YIo6bhRQ1mqtqAMX 1Spj9F8urE92Bfj+yjrvVDTk3Tj+P/8gefs59Nv0Z3dYgX8=
X-Google-Smtp-Source: ABdhPJyBAJkIRe50KhfoIVjYMBtwZqOFD4hsr7w9tuYQxg48ieCHDp5K0v3zqbrzgS9pnG3QIe0f9xRA04GLRWxCN9Q=
X-Received: by 2002:a17:906:c1d8:: with SMTP id bw24mr3831478ejb.91.1596199430002; Fri, 31 Jul 2020 05:43:50 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Albert Cabellos <>
Date: Fri, 31 Jul 2020 14:43:39 +0200
Message-ID: <>
To: Martin Duke <>
Cc: The IESG <>,,, " list" <>
Content-Type: multipart/alternative; boundary="000000000000041d2f05abbc2403"
Archived-At: <>
Subject: Re: [lisp] Martin Duke'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:43:54 -0000


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

Find below the specific changes and responses to your comments:

On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker <>
> Martin Duke 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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Having read this document front to back for the first time, I found it
> hard to figure out what can actually safely done over the public
internet, and
> what can be only be done in trusted environments. I realize that this is
> probably because the no-internet provisions entered late in the game. If
> were my document, I might reorganize it to make the distinction more clear
> (i.e. present the internet-safe dataplane spec and then have additional
> sections about insecure add-ons). That said, at this stage in the game
I'd be
> happy to have a new section that clarified what is what. For example
> I'm reading it correctly, which is my point)
> NEW:
> "
> Section 4 and a half. Deployment on the Public Internet
> Many 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 xTRs:
> * SHOULD set the N, L, E, and V bits in the LISP header (sec 5.3) to zero;
> * SHOULD NOT use gleaning as a method for Route Locator Selection (Sec 9);
> * SHOULD NOT use any data plane methods described in Section 10 for
> Locator Reachability, instead relying solely on control plane methods;
> * SHOULD NOT use any data plane methods described in Section 13 to update
> EID-to-RLOC mapping, instead relying solely on control plane methods.
> "
> Perhaps my text is inaccurate, but something to that effect would be very
> helpful.

We have added -almost verbatim- this to the following new section (section

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.

> Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits
> zero?

There is no field then.

> Sec 7.2 The stateful MTU design does not incorporate any security measures
> against ICMP spoofing. At the very least, the ITR needs to make sure that
> fields in the outer IP and UDP headers are hard to guess, and that this
> information is stored to verify that the ICMP message came from on-path.
> this is not possible, the design is not safe to use over IPv4.  If
> hard-to-guess information is not available to be stored deeper in the
> then it is not safe over IPv6 either.

The source UDP port is random. We have therefore added the following
statement at the beginning of section 7.7:

   An ITR stateful solution to handle MTU issues is described as follows,
this solution can only be used with IPv4-encapsulated packets:

> Sec 7.2 There is a fourth situation which can arise. If the ETR receives
> ICMP packet from an EID in its network. I have a couple of questions
about what
> should happen in this case:

In this case the EID is locally attached to the xTR. Therefore, the xTR has
a locally configured MTU to reach the EID. So what is written in the
section already covers this scenario.

> - How is this communicated to the sender of the flow that triggered the
> message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the
> EID, both, or neither?
> - Is the ETR responsible for enforcing the MTU to that EID for subsequent
> Sec 9. I don't understand what this sentence means:
> "The client-side ITR controls how traffic is returned and can alternate
> an outer-header source RLOC, which then can be added to the list the
> server-side ETR uses to return traffic."
> This would appear to be the inverse of the "Routing Locator Hashing"
> in Section 12, which provides a technique for switching destination RLOC.
> this "alternation" of source RLOC mean to be done on hashed 5-tuple basis
> each flow uses only one source RLOC)?
> If not, would this involve potentially sending packets for one flow on
> different interfaces with different path characteristics, causing packet
> reordering. Or perhaps you mean each packet is sent from the same
> with a spoofed source RLOC, which creates interesting issues for ICMP
> and the like.

No, flows are always sent to the same RLOC, per “Routing Locator Hashing”.
The section is describing a standard LISP load-balancing (same priority
weight 0), which means that flows will be load-balanced across the RLOCs.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Sec 5.3. In the DSCP discussion, please add an information reference to
> 2983, which provides guidance for DSCP and tunneling. It is not quite as
> as simply always copying DSCP to the outer packet.

Added the sentence “Guidelines for this can be found at <xref

> Sec 9. I don't understand what this sentence means:
> "The value of the 'Weight'  represents the relative weight of the total
> that match the maping entry." (s/maping/mapping, obviously)
> What is the "relative weight" of packets? Is this the number of packets,
> cumulative number of bytes, or something else?

Typo changed, thanks!

Relative weight among the defined weights (0.5, 0.25, 0,25).

> Sec 16. "If  the attacker spoofs the source RLOC, it can mount a DoS
attack by
> redirecting traffic to the spoofed victim's RLOC, potentially
 overloading it."
> This not the only problem. The attacker could also DoS by directing
traffic to
> an unreachable RLOC.

Thanks, Albert.

> _______________________________________________
> lisp mailing list