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

Dino Farinacci <farinacci@gmail.com> Tue, 28 August 2018 16:49 UTC

Return-Path: <farinacci@gmail.com>
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 05EC1130DF9; Tue, 28 Aug 2018 09:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 T82T1le_bO31; Tue, 28 Aug 2018 09:49:18 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0A0126DBF; Tue, 28 Aug 2018 09:49:18 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id g20-v6so1009570pgv.6; Tue, 28 Aug 2018 09:49:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GGpbO0zRJjvK8xMGJ8PVnWR2vT/vxFmhw+COh7Ih78g=; b=Hbd2TRO1Jyp+r9+5qAOhvq58yzuQjz+GQ8yW9Fent6PCRAc622hBcm8RIyrT6ruR5q y5Afodz3eohTvLLPjMx9SutClRfkBTZ9uNPNn3n5nozP/r993DZXR7fml1U+olrsl98D uSG9y4LQq6RqMxv8JInsqly9RoyismbHwtTOtqrXr0iHUXjs0aKES07G/aEkbjQmoEg9 xNRH0Sr3BiF1ofmjvuXRamsKt+PWhNmKkmWdxfywff7B60RBMhWEQE9vyAgUOga6vO6r 3mCQe22u7CVYgX+jkK4o+xjVogocpXSPaHz7G0otg03Ra9li6aERECGHoeO3TpH9CAf8 IT7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GGpbO0zRJjvK8xMGJ8PVnWR2vT/vxFmhw+COh7Ih78g=; b=pt3uaQaHLsMt+J6QT2ITb07/fpxAJfIy31214ywjeX3/xkb/++OZG1N1t90rK55gtJ e1PO2t52cQ742JfWRm3ZcAA/Vo4AnLcF9YpSdYOHe/+CjQFlkFev+ftX+8W3hSv/RNMn Z9foAMAL1g+h+f3rWiAGOprRdNMxgN0g+r12f5KOE69YUdu2/2Zy6T5kaea0AWy46U+D G1MYjAxCM74asjdH9RB4HI+6fhME3q/WYcJiseSB/Hl0SJCMMhL6RsC01wARsNpzJjld zMVDZKWMmiipxCBpbUN/G2BPfHvVPv/BlnkPVI4GP4Nca/JEyUR6oRnAF0V+aHhruDeK 7lGg==
X-Gm-Message-State: APzg51CXeCI0MPGdc9em3EH84tnUB87zkfUoQDVNeT51xk2v+4g62wTI FsLPjeNpqnq7hrJ+jAQ3/Oh3OrV8
X-Google-Smtp-Source: ANB0VdY1gjxrxe5y2Xk+XhZ8ZnxiHi8kA+StiJ7VMpZx3zCniBP96Zz/a89TSVo+W2jZPO8HbKIRVw==
X-Received: by 2002:a62:591a:: with SMTP id n26-v6mr2422342pfb.94.1535474957596; Tue, 28 Aug 2018 09:49:17 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id o10-v6sm6167090pfk.76.2018.08.28.09.49.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Aug 2018 09:49:16 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>
Date: Tue, 28 Aug 2018 09:49:15 -0700
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>, Dino Farinacci <farinacci@gmail.com>, "lisp@ietf.org list" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE7ECD23-E8A2-4D48-B752-0D246C02F27E@gmail.com>
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com> <ED34F830-1FEF-42BB-BB6E-805D724AB339@gmail.com> <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch> <CF5E3C7B-E492-4EE9-A2E6-A2D823C6610F@gmail.com> <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/RRCtmN_TvZujAadoSFbEoWOf-PM>
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: Tue, 28 Aug 2018 16:49:20 -0000

> I'd suggest inserting a new paragraph after paragraph 2 of section 5, something like:
> 
> 
> NEW:
> 
> As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs across the Internet, implementors should be aware of the provisions of [RFC8085], especially those given in section 3.1.11 on congestion control for UDP tunneling.

Consider it added to Section 5 “LISP Encapsulation Details”, last paragraph.

> 
>>>>>>> (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.
>>>> 
>>>> Well RFC8061 does AEAD on the payload. All data *after* the LISP header.
>>>> The encryption is a more integrated model than IPsec, so we can be more efficient by not using extra IP headers and extra control/key exchange protocols.
>>> 
>>> Okay, that's all well and good. The LISP header itself isn't integrity protected, though?
>> 
>> It is not, unless the outer UDP checksum is used. Which we suggest to be 0 and when NATs make it non-zero, ETRs ignore it.
> 
> Ah. Okay, so two things:
> 
> (1) By "integrity protection" I mean "cryptographic integrity protection", in the sense of "preventing on-path attackers or off-path spoofers from being able to influence ITR/ETR state through crafted LISP headers to the detriment of the traffic of others". Looking over 8061, it seems to only cover confidentiality of the data-plane payload, which is extremely useful but not sufficient to prevent these attacks.

Well at this point in the generation of LISP, the only text I think to mitigate LISP header corruption is to indicate that a LISP ITR can use an outer IPsec header if protection of the UDP and LISP headers need protection. Or is that not a strong enough statement?

> The attacks seem to be well enumerated in 6830bis, but the lack of a stated mitigation beyond "be careful" seems to suggest that the mitigation is "don't use LISP", which is of course less than desirable. I'm trying to understand whether the deployment scenarios envisioned for LISP make these attacks less likely (for instance, because the ITR/ETR path itself is generally cryptographically protected with its own outer tunnel), or whether this is something that this document (or a future companion to 8061) needs to worry about.

I think so because of 8061.

> (2) Checksums provide what I'd call "corruption protection". On "setting the outer UDP checksum to zero", please be aware that this may have undesirable interactions with IPv6 headers; see also section 3.4 (Checksum Guidelines) of 8085.

If we don’t go IPsec route, we go with the checksum route. What do you think? Meaning, that if LISP header protection is desiriable, use UDP checksums. 

> Thanks, cheers,
> 
> Brian

Thanks for the commentary and discussion,
Dino