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

"Brian Trammell (IETF)" <ietf@trammell.ch> Wed, 29 August 2018 09:36 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251AA130E4F; Wed, 29 Aug 2018 02:36:42 -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 6RfqqTN_c1_V; Wed, 29 Aug 2018 02:36:40 -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 EDDC6130E44; Wed, 29 Aug 2018 02:36:39 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F37D2340211; Wed, 29 Aug 2018 11:36:34 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.16720); Wed, 29 Aug 2018 11:36:34 +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; Wed, 29 Aug 2018 11:36:34 +0200 (CEST)
Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 65598371; Wed, 29 Aug 2018 11:36:34 +0200
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <FBA13CF2-8E44-46DA-AB5D-9082B5288F05@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_5A7B1021-7CB0-43A5-BFDD-3F90F24D5161"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 29 Aug 2018 11:36:33 +0200
In-Reply-To: <CE7ECD23-E8A2-4D48-B752-0D246C02F27E@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: Dino Farinacci <farinacci@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>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/f4Uh8ZmaEz6fNJDV4iwx1HsEWu4>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Aug 2018 09:36:42 -0000

hi Dino,

> On 28 Aug 2018, at 18:49, Dino Farinacci <farinacci@gmail.com> wrote:
> 
>> 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.

Looks good, thanks!

>> 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?

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.

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 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

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,

Brian

>> 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