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

"Mirja Kuehlewind (IETF)" <> Mon, 10 September 2018 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A14C8130DE3 for <>; Mon, 10 Sep 2018 08:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7P-kgMRzE0_S for <>; Mon, 10 Sep 2018 08:21:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A8A31277BB for <>; Mon, 10 Sep 2018 08:21:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; b=kYYD0rtQwTa1i1zHErCRgN5r4N1977sd6bdENCSpkYtIktSAE0PqPlK2KQ3BY8Agntj6iX7iHDK1SMn2s3npVPscS/Ne67aeBz84lX4tjja5opNGQKjkk8erHM7XBMjkb3AVsQm8mV8kuFjgMKk9/2xmQVKds9RnYdfc4FSTXSU=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 6311 invoked from network); 10 Sep 2018 17:20:12 +0200
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 Sep 2018 17:20:12 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <>
In-Reply-To: <>
Date: Mon, 10 Sep 2018 17:20:11 +0200
Cc: TSV-ART <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Brian Trammell <>
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <>
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Sep 2018 15:21:17 -0000

Hi Brian, hi ART!

Given the reviewed document below still has a discuss-worthy issue with ECN decapsulation, I though I send a quick pointer to rfc6040 to the ART list for future reference!

Thanks for the review and discussion already! That's super helpful and I hope the sec AD (based on the SEC-ART review) will continue the privacy discussion!


> Am 27.08.2018 um 16:35 schrieb Brian Trammell <>ch>:
> Reviewer: Brian Trammell
> Review result: Ready with Issues
>> From a transport standpoint, this document is basically OK -- I suspect that
> there are probably more transport-relevant issues to consider on 6833bis, but I
> did not review it. Two issues with the dataplane:
> (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.
> (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.
> nit: Section 7.1. para 7 should note that the ICMPv6 message sent is called
> Packet Too Big, not Unreachable/Frag Needed.
> _______________________________________________
> Tsv-art mailing list