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

"Brian Trammell (IETF)" <> Mon, 27 August 2018 19:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3F0C130DFC; Mon, 27 Aug 2018 12:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y6OS2sJmLkSB; Mon, 27 Aug 2018 12:39:02 -0700 (PDT)
Received: from ( [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6CA13130DC9; Mon, 27 Aug 2018 12:39:02 -0700 (PDT)
Received: from (localhost []) by localhost (Postfix) with ESMTP id 5C7883406D5; Mon, 27 Aug 2018 21:39:00 +0200 (CEST)
Received: from localhost (localhost []) by localhost (ACF/6030.1484); Mon, 27 Aug 2018 21:39:00 +0200 (CEST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Mon, 27 Aug 2018 21:38:59 +0200 (CEST)
Received: from [] (account HELO []) by (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 65413780; Mon, 27 Aug 2018 21:38:59 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: "Brian Trammell (IETF)" <>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <>
Date: Mon, 27 Aug 2018 21:38:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Dino Farinacci <>
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Aug 2018 19:39:05 -0000

Hi Dino, all,

Sent from my iPhone

On 27 Aug 2018, at 19:36, Dino Farinacci <> wrote:

>> (1) Common advice to all UDP-using encapsulation designers and implementors:
>> please read RFC8085, especially section 3.1.11. As LISP's dataplane is
>> basically an application of UDP, I was surprised to see no reference to RFC8085
>> here. I believe that in the most common case LISP falls into case 1 here, but
>> implementors of LISP ITRs should at least be made aware of the other cases.
> I don’t see a section 3.1.11 in RFC 8085.

Page 16, “UDP tunnels”.

> Rather than make references, can you say what you think the issue is?

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 

>> (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.

>> nit: Section 7.1. para 7 should note that the ICMPv6 message sent is called
>> Packet Too Big, not Unreachable/Frag Needed.
> We used “Packet Too Big” for all ICMP messages including IPv4 and hence we received comments about it on how it should change it to Network Unreachable. I will fix this for IPv6.

Yeah, this is the one place where i noticed a rough edge on supporting v4 and v6. Thanks.



> Dino
> _______________________________________________
> Tsv-art mailing list