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

Dino Farinacci <farinacci@gmail.com> Wed, 29 August 2018 17:17 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 5D5D7130E71; Wed, 29 Aug 2018 10:17:05 -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 5O8eIRSsSJF3; Wed, 29 Aug 2018 10:17:03 -0700 (PDT)
Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 82F80124C04; Wed, 29 Aug 2018 10:17:03 -0700 (PDT)
Received: by mail-pf1-x442.google.com with SMTP id k19-v6so2583073pfi.1; Wed, 29 Aug 2018 10:17:03 -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=57dVu+CxkSbgJrPpGVY1VPcxSDkxtyl08TmRaxzniVY=; b=Q5yo2RFcQZ/9TGmgeARXs7edq7u3HxnWUeBc2Do2issk36BlhjVd5uQyLgamxxc8MS CNSxjwAhiQQHox2KluYOE9tQaCGyQYKDb3/QUAt0C2bcYoF0KOZ4iKcdLhMWWfI5ai4t wb6tlBOHXmU/H5CRhU7VzAANTxzCgblt+X3nTIiQdkVcms+Lq9HoyAwhb3t+efvF6wl6 ldvpjT7wLP8nZ+/AmVLoc0avRe70hpwFIjPDgUvHJ1KVzhpLMx2UwpW2EP2ZKZ5q9Pkn 1R9M/dCpKaPPZuS7USaF3uRH4XJ4/6CoNwM8AP8eM78GZogKOlYo6G3yUDKUltfcvAQY KvAQ==
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=57dVu+CxkSbgJrPpGVY1VPcxSDkxtyl08TmRaxzniVY=; b=ARNGfYdmcPswV2FTugH9VXMWGRa/jjO4CvRUDJhyC32Bm+uXzfvRGijYzPx7CcjfQV QhLe90D9KBhStCXi/1E9+YJ7159s+iNthlFCg3yLrMHdSlz4fhyqdwbDG/XIJ2xp4dsx DMI89LVkHI2YZVoSVm3+/NYiIDFV8+Gc2IbqcZhoeb+trA7XmGgSTNOt3kXnQChxS7j4 mbi/xt2jChd/Zcy+lAHUUxTC+dkdj2dignXb1nsAgICzuYkYjVWfdxDxzgkhwICdi+tW jwxJxwy8h8aHfw5jzj8g2+tP7Iv4livLPMjOeEpy2H1CzFG89dnYCT7piZp0T6ZfY9vf rFPA==
X-Gm-Message-State: APzg51CGJdZm8G9Ck1zEW6EeXSPap4jcd+qSS+kODfhX1TaU1g7dSH6n BwcdMWXgPnf9WL70plZZyuI9bwua
X-Google-Smtp-Source: ANB0VdZDnO8AkqTo45IB4bdRLcH4RxlWtMnlF2f/+3t6MA/aQiJpy89eyEGNwFQIi7U1c+x2pYEGqw==
X-Received: by 2002:a63:41c1:: with SMTP id o184-v6mr6560330pga.297.1535563023156; Wed, 29 Aug 2018 10:17:03 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id d22-v6sm16684049pfm.48.2018.08.29.10.17.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 10:17:02 -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: <FBA13CF2-8E44-46DA-AB5D-9082B5288F05@trammell.ch>
Date: Wed, 29 Aug 2018 10:17:01 -0700
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@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> <CE7ECD23-E8A2-4D48-B752-0D246C02F27E@gmail.com> <FBA13CF2-8E44-46DA-AB5D-9082B5288F05@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/fdSoWZWvoCCSJ8pPsX_7uH2r_Ic>
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 17:17:05 -0000

> 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