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

"Brian Trammell (IETF)" <ietf@trammell.ch> Mon, 27 August 2018 19:39 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F0C130DFC; Mon, 27 Aug 2018 12:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6OS2sJmLkSB; Mon, 27 Aug 2018 12:39:02 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA13130DC9; Mon, 27 Aug 2018 12:39:02 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5C7883406D5; Mon, 27 Aug 2018 21:39:00 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.1484); Mon, 27 Aug 2018 21:39:00 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Mon, 27 Aug 2018 21:38:59 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.78]) by switchplus-mail.ch (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)" <ietf@trammell.ch>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <ED34F830-1FEF-42BB-BB6E-805D724AB339@gmail.com>
Date: Mon, 27 Aug 2018 21:38:59 +0200
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, ietf@ietf.org, lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch>
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com> <ED34F830-1FEF-42BB-BB6E-805D724AB339@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/Pmj9OyFozpmWsmVv_eV_iqiGWY0>
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=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 <farinacci@gmail.com> 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.

Cheers,

Brian

> Dino
> 
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art