IETF Logo Mail Archive

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

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Mon, 10 September 2018 15:21 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14C8130DE3 for <tsv-art@ietfa.amsl.com>; Mon, 10 Sep 2018 08:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P-kgMRzE0_S for <tsv-art@ietfa.amsl.com>; Mon, 10 Sep 2018 08:21:15 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8A31277BB for <tsv-art@ietf.org>; Mon, 10 Sep 2018 08:21:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; 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 mue-88-130-61-249.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.249) by kuehlewind.net 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)" <ietf@kuehlewind.net>
In-Reply-To: <153538054829.30074.15428909912816972228@ietfa.amsl.com>
Date: Mon, 10 Sep 2018 17:20:11 +0200
Cc: TSV-ART <tsv-art@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A2D8BFEF-FD95-453A-B6E6-AFEBDDE605A9@kuehlewind.net>
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com>
To: Brian Trammell <ietf@trammell.ch>
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <20180910152012.6306.61397@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/TR21_jAr2xNIfcYBCTkJp1BjGkY>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=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!

Mirja



> Am 27.08.2018 um 16:35 schrieb Brian Trammell <ietf@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
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art

v2.23.0 | Report a Bug | By Email