Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15

Dino Farinacci <> Mon, 27 August 2018 21:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7CBD130DE8; Mon, 27 Aug 2018 14:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 HPv-y0M0HZao; Mon, 27 Aug 2018 14:29:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55165124BE5; Mon, 27 Aug 2018 14:29:07 -0700 (PDT)
Received: by with SMTP id h79-v6so168746pfk.8; Mon, 27 Aug 2018 14:29:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Oq1cJpikosjtSrJX3/wzGsbWFYtlih981KqcfcARU5E=; b=ZLCNGsZDGG1vyXRVzTPsbE1uxyjc4qYApDGjT82S7ISRLrnQVIQXxJqkPdK/nzilFe jBSA7waYXEpTBaiKugo6J4a6e+OKx4otu76DWEwBfgF9/70NTof2zGgh/Z++Afr7bq2G YrljqZRhmug+0l8dyD20i2s2m/tSxPvGNPIqiEWvpnF0h4iTfGSKURmR3K5xjdndj9r1 jXuxaUff69SexYF28tpJ1tCO6J1Mz/wkp7yj9MpuCSWDMnIClIvgslxfAw8EqWGPb8UJ 4OOqfNeFRxoc/g/ymWeCePoFYRmfPspYRdXi+EwQlw1M9dhd1ZWO4UjCgiWhM111suGc /+Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Oq1cJpikosjtSrJX3/wzGsbWFYtlih981KqcfcARU5E=; b=YKIVFE70x0/DDLvKSCc2D8K7SXeY8Rs69wuA3mFmq35yNpPk5s/EpJWXLNeza56keJ HgAjaXq3D3J7VV4ReCneuqZ5hhdkUH4QgymtsRBxI8jTdGn7U+ivtSsFQihIEvBI/SBh paaXx+AYZlnodW/2x79ieQHtg9y/kexoCZecElbTfLVOb8cRxFP34XUG6OiFAfu30XvC lOhEiuS8IwaF4V8rLaj2T4R6Nzvho97Fu9enAES+aXR2S0GMGDux+uaPNoJmCS+6vCyV T8ryi6hp/GHYwTM7SM2yYCGazNPcEbgLD2YSBjY6sbTbxE9R6IXOlbiQgtLRj1sPKUMJ u2WQ==
X-Gm-Message-State: APzg51BwhcNTytnhosAAUa4CRnuP9oQdSZ2Bh0S1vuMKPARlQrAGTgGl Cry2xKwnF4F3mb+8a/Emqn0=
X-Google-Smtp-Source: ANB0VdbAQTOY67THMFRNu/1G6mpyBsA98/zu3Vjjh9SjuhSfMvBJ4/zqJMAexJlPPCyjiraZ3B8Y5Q==
X-Received: by 2002:a65:4384:: with SMTP id m4-v6mr13612465pgp.265.1535405346836; Mon, 27 Aug 2018 14:29:06 -0700 (PDT)
Received: from ?IPv6:2603:3024:151c:55f0:c1b3:bc4c:9028:ff3b? ([2603:3024:151c:55f0:c1b3:bc4c:9028:ff3b]) by with ESMTPSA id f6-v6sm257675pff.29.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 14:29:06 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Mon, 27 Aug 2018 14:29:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: "Brian Trammell (IETF)" <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
X-Mailman-Version: 2.1.27
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: Mon, 27 Aug 2018 21:29:42 -0000

>> LISP’s data plane is a UDP tunnel, and as such there are congestion control issues that must be considered. LISP inplementors and deployers using LISP to carry a mix of traffic that is not predominantly"
> sorry, ate an interrupt, sorry about that.
> ... "congestion controlled itself (i.e., carried by any IETF transport) need to be aware that the ITR is ultimately responsible for not causing undue congestion, for example, using a circuit breaker.”

Well I hear you, but you know there is a lot of technology developed that uses UDP tunneling. And in this case, it isn’t used like a traditional transport whereby a node is originating traffic. In this case, a LISP router is forwarding packets just like any other IP router forwarding IP packets.

>> I am not sure what more we can say. There is an depth discussion about DSCP fields and how to use ECN. Basically copies the inner values to the outer header equiv values.
> Concretely, I'd add a pointer to RFC 8085, especially section 3.1.11.

But I am not sure what supporting text we should put around the reference. Please advise.

>>>>> (2) This is not transport-specific. Reading the document, it struck me that the
>>>>> design of the protocol has a few inherently unsafe features related to the fact
>>>>> that its wire image is neither confidentiality- nor integrity-protected. I
>>>>> think that all of the potential DDoS and traffic focusing attacks I could come
>>>>> up with in the hour I spent reviewing the document are indeed mentioned in the
>>>>> security considerations section, but as the security considerations section
>>>>> does not give any practical mitigation for dataplane overload attacks, it seems
>>>>> to be saying that RLOC addresses shouldn't be Internet-accessible, which as I
>>>>> understand it is not the point of LISP. I haven't seen a secdir review on this
>>>>> document yet, but I'd encourage the authors to do everything it asks.
>>>> RFC 8061 goes along with RFC6830bis. It addresses data-plane confidentiality.
>>> I haven’t read 8061 yet, but I probably should before continuing this thread.
>>> I will say that I’m far less concerned about LISP header confidentiality than I am about LISP header integrity, given the opportunities for on-path meddling and off-path spoofing. If the common solution to both is something like sticking everything on the ITR-ETR path in IPSec then this is less of a concern.
>> Well RFC8061 does AEAD on the payload. All data *after* the LISP header.
>> The encryption is a more integrated model than IPsec, so we can be more efficient by not using extra IP headers and extra control/key exchange protocols.
> Okay, that's all well and good. The LISP header itself isn't integrity protected, though?

It is not, unless the outer UDP checksum is used. Which we suggest to be 0 and when NATs make it non-zero, ETRs ignore it.