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

Dino Farinacci <farinacci@gmail.com> Wed, 29 August 2018 18:18 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 7930F130DFE; Wed, 29 Aug 2018 11:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level:
X-Spam-Status: No, score=-0.598 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, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no 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 ej59Om9CEUTn; Wed, 29 Aug 2018 11:18:22 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 21321126DBF; Wed, 29 Aug 2018 11:18:22 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id u11-v6so2655651plq.5; Wed, 29 Aug 2018 11:18:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2NGpxpOp5WZrDKoSDiuImy6twicVlXsvY8A3TFZMXA4=; b=cJ3wSZMcKUkOAxZatBO5vCK7Je/ctvUsiOupr82nvMEB/395zTXgI0d4BhiUgoVfyp 4zkxIH2DdrZhPDgoyBSUEcG4x3Sq9CQcatjU/LUWLXzloGAYZjVDkINPb+rZxild1li9 6uMEE6mUD3k2PyMGEBqeq7uP6OJsOKXqcTKJJx+eyTCYRZxUUKCJBSbyFkTzrO8apdhd PWDLRZ/jT3C5eYUdafun9cmaaFJBKYZWRGoI331UWVW9RZhz51f7N3H+kQtQWgiZ3OPk 797mdfOYmnOX5ZrUcC+2HnfEwfDz6S4JAwief1fxB7U9UJzCUehhk4u8f8gWo7jy6B4l I9uQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2NGpxpOp5WZrDKoSDiuImy6twicVlXsvY8A3TFZMXA4=; b=o8oy6P89gEh5VP2tnbHj50k3sbnzZq3Ed4++UCWWVe81RYraukZTpO+LH0AixfOzjW HFjIdLEMP0SDgiF8aagyJSjUIwkolkunfsaRsNr6zpVnGWNSVDbBvk3fJvDD6ahcIuJJ wDy2zPwWMMpbU4+F2xuBXyonzAUgM+7MpUY5t8wn86JUk94UjNr4oYf43OwuuQtyPcS2 O3q1MUurY1qVlSLUJxBy0ql9yLVtUZ71zaJ49SWFsifmxRrs+I2kLn1Fj83bC5yQSdGe 3yPMp8fG3gpoERmS8y2TGqXRcSxfR6NufG04PofW+Anu3IbOrgniHsBCOLNcmnhKzT+3 k/bg==
X-Gm-Message-State: APzg51CuChpWYdlQuicYu0MEouN4eoKIwD6VgMTOMjNbiZCtxWJwrr7I 9zOdUMxhAQ3HYouPSuImeZXLS/2G
X-Google-Smtp-Source: ANB0Vdazwuw5oZFrI7tGO/q58RZ+dEqV4I3l7Trp39iVZLpC+bmbYtZ+7bhNfvY8d4i0E+KrwoiKVw==
X-Received: by 2002:a17:902:bd86:: with SMTP id q6-v6mr190065pls.35.1535566701781; Wed, 29 Aug 2018 11:18:21 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id k8-v6sm7955925pga.80.2018.08.29.11.18.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 11:18:21 -0700 (PDT)
From: Dino Farinacci <farinacci@gmail.com>
Message-Id: <C4425CD6-B44D-479A-819A-BEFCC83E9E33@gmail.com>
Content-Type: multipart/mixed; boundary="Apple-Mail=_2025227A-6896-4A2E-B811-562029EC52AB"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 29 Aug 2018 11:18:19 -0700
In-Reply-To: <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com>
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
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> <CE7ECD23-E8A2-4D48-B752-0D246C02F27E@gmail.com> <FBA13CF2-8E44-46DA-AB5D-9082B5288F05@trammell.ch> <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/-A2egRG5ijmTC0YIPC8t74ddDoo>
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: Wed, 29 Aug 2018 18:18:25 -0000

Brian, see the second reference to RFC 8085 in the diff file below. Let me know if this could satisfy your comment. Thanks.

Dino


> On Aug 29, 2018, at 10:17 AM, Dino Farinacci <farinacci@GMAIL.COM> wrote:
> 
>> We're talking past each other here, I think.
>> 
>> There are, as I see it, two completely separate problems here:
>> 
>> (1) The document permits/recommends zero UDP checksum on IPv6 outer packets. This leaves the IPv6 header unprotected against inadvertent corruption. To prevent this, LISP should follow the guidelines in section 3.4.1 of 8085, specifically:
>> 
>>     Use of the UDP checksum with IPv6 MUST be the default
>>     configuration for all implementations [RFC6935].  The receiving
>>     endpoint MUST only allow the use of UDP zero-checksum mode for
>>     IPv6 on a UDP destination port that is specifically enabled.
>> 
>> and
>> 
>>     A UDP application MUST check that the source and destination IPv6
>>     addresses are valid for any packets with a UDP zero-checksum and
>>     MUST discard any packet for which this check fails.  To protect
>>     from misdelivery, new encapsulation designs SHOULD include an
>>     integrity check at the transport layer that includes at least the
>>     IPv6 header, the UDP header and the shim header for the
>>     encapsulation, if any [RFC6936].
>> 
>> See also Magnus' tsvart review on lisp-gpe; his issue A is basically the same problem.
> 
> This issue has come up at least once or twice every 2 years. We suggest a zero checksum no matter what the  outer header is because we wanted to be practical with respect to what implementations do. No matter what the IETF says, the industry has moved forward and not only do not check checksums for UDP based tunnels but if they wanted to they can’t because many hardware does not have the entire packet buffer in the forwarding engine that does header processing.
> 
> So I would not want to change our text at this point. We are very aware this is controversial but it is emotionally packed as well. UDP packets in all probability will not be missed forward because layer-2 chips do a very good job at CRC. So if its bit errors one worries about, that is very rare. If it is packet corruption due to MITM, that is another story.
> 
> We can make a reference to 8085 with respect to checksums but we have to craft the text carefully because I really don’t want to release a spec that doesn’t reflect reality. So if you can help us craft a couple sentences, we can consider putting it in.
> 
>> 
>> None of this, however, defends against the second problem:
>> 
>> (2) Any on-path attacker, or any off-path attacker who knows the addresses of the xTRs, can guess the current state of mappings, and can spoof packets from one of them, can send packets with valid LISP 
> 
> They cannot if the inner header is encrypted. The EIDs will be obfuscated. All that is known is that one location is sending to another location and not who is sending to who.
> 
>> headers (and, indeed, valid checksums if they so choose) which will change xTR state in ways which can lead to denial of service conditions. A cryptographic integrity check over the LISP header would prevent the on-path attacks. I *think* the nonce echo functionality can be used to prevent off path attacks, or at least allows an endpoint that suspects it is under attack to challenge
> 
> For this context, the key-id field in the LISP header is the only precious entity. All other bits could be  MITM attacked and the ETR could verify if the settings are real or not (at some expense). If the key-id field is changed, then the ETR will get decryption or ICV errors and drop packets. Yes, I know that is a DoS.
> 
> To resolve this, I’d be willing to refer to 8085 and use checksum when users believe they need to protect the UDP and LISP headers.
> 
> What do you think?
> 
>> Indeed, the security considerations section (and 7835 on which it is based) acknowledges most of this, and it seems that work is ongoing to fix this (draft-ietf-lisp-sec-15), so I guess you can simply take my comment on the second problem as encouragement to get lisp-sec done (subject, of course, to the warnings in draft-trammell-optional-security-not).
>> 
>> Cheers,
> 
> What do you think of my suggestion?
> 
> Dino
> 
>