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
- [lisp] Tsvart last call review of draft-ietf-lisp… Brian Trammell
- Re: [lisp] Tsvart last call review of draft-ietf-… Dino Farinacci
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Brian Trammell (IETF)
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Dino Farinacci
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Brian Trammell (IETF)
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Dino Farinacci
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Brian Trammell (IETF)
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Dino Farinacci
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Dino Farinacci
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Spencer Dawkins at IETF
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Dino Farinacci
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Brian Trammell (IETF)
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Dino Farinacci
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Dino Farinacci
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Brian Trammell (IETF)
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Dino Farinacci
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Brian Trammell (IETF)
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Dino Farinacci
- Re: [lisp] [Tsv-art] Tsvart last call review of d… Brian Trammell (IETF)