Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team

Tom Herbert <tom@herbertland.com> Thu, 16 February 2017 20:28 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: nvo3-dt-encap@ietfa.amsl.com
Delivered-To: nvo3-dt-encap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5C1129531 for <nvo3-dt-encap@ietfa.amsl.com>; Thu, 16 Feb 2017 12:28:00 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 siTuIj9-CqG4 for <nvo3-dt-encap@ietfa.amsl.com>; Thu, 16 Feb 2017 12:27:59 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 2677F12941A for <nvo3-dt-encap@ietf.org>; Thu, 16 Feb 2017 12:27:58 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id x49so24734818qtc.2 for <nvo3-dt-encap@ietf.org>; Thu, 16 Feb 2017 12:27:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jBkiBrWJZ/NLM/XrlBEdZsmN3N3UAdZ0bo5sQpCW1nU=; b=yMswenx2d3KsQjfWa24yOS7Xya30g7u+Sl9jtyffJNgaSljuGWRACZw/EbawVdXF70 ohgS8btNBTM8Kup2BCN2xte9Xe1+1CcLtnXmua4UL5EyGJ3ha8E2dyYTtIIi4GIIP2lr +zeDJNJiiRi19sP4bI0KOYOdROc6z1h7PqywKt6JKGeRoc70Sr4T79vG8mYAbyHCJ/n3 XsgyRhBpGikntR04E4UoiIZNyn4de1k7FynQw0QFVqQFW9HbNm2VrzHwmoJSfeJ5cZD1 sLFaBIjPqOqTgW5xZE+kYzUYWiUoJ1RClUuHej1VrbJPp/KYHDL18kHilNJFZ/XDeRt8 hSJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jBkiBrWJZ/NLM/XrlBEdZsmN3N3UAdZ0bo5sQpCW1nU=; b=K5MsEBZQAQjMmG5Lj4eGTUq0c3ULaf5QD0dV1+Kn2eaYTICVhC2IUE2+Zf6nNaDfc2 S1oq6F2GsHpSSLpoaNyxnwwRt3w3aUn2ewYyAH8voJPTpUMDM73mAU0gA56gBZc+9Tej TNoq0y5bxfsqcYwjybfpSk0sc3flwSDszPyeiyxuxdcyqCyNL/jMcZyW+HeWgHgOhBR+ J2HrrydisYp7Eln4ar6UXKCH2IWQ7rKDA3l76DmvWenpnLMLKzFWDCKYVNhI4MdXshdD wZX11xZqe9QgDCzBD7IaUBJvWh+02zAKsIhwIyv7rgHHOkPyuSLeQxbLzwSYII1kvPxb KEbg==
X-Gm-Message-State: AMke39lmVYugjk8v78ZWXI98c4Z4xVUUZswSYgvNb2OjMX6bqHniLJbYMOopnoNSliC12L4juDBtpv5tyctrSw==
X-Received: by 10.200.46.162 with SMTP id h31mr3931458qta.164.1487276877043; Thu, 16 Feb 2017 12:27:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.43.227 with HTTP; Thu, 16 Feb 2017 12:27:56 -0800 (PST)
In-Reply-To: <65CC369B-CB65-40FC-8F7E-A805B554B8FD@vmware.com>
References: <CA+C0YO0yz4KBe=w+EXHVBA=XWErRAtTzdCNsca7h-BjJ2Bwdxg@mail.gmail.com> <CALx6S37AeS8QEtm1SJsFe9dAnEoCdPZodPJyr7jfYxxEnM040g@mail.gmail.com> <F80D14D0-57B0-4768-9405-4AF99526E439@vmware.com> <CALx6S35eYxWXCK3TsESedJ8g3zQDWHYyyJXObAJ4VMnC9Q1aQQ@mail.gmail.com> <65CC369B-CB65-40FC-8F7E-A805B554B8FD@vmware.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 16 Feb 2017 12:27:56 -0800
Message-ID: <CALx6S34oFSkQ_bL=ike_5UNxk5P3UpB2cW0F4WSz=Vp0DotLZQ@mail.gmail.com>
To: Sami Boutros <sboutros@vmware.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3-dt-encap/PFt-pcn-eb85QB01-YOINCbbAQg>
Cc: Sam Aldrin <aldrin.ietf@gmail.com>, "nvo3@ietf.org" <nvo3@ietf.org>, "nvo3-dt-encap@ietf.org" <nvo3-dt-encap@ietf.org>, "nvo3-chairs@ietf.org" <nvo3-chairs@ietf.org>
Subject: Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team
X-BeenThere: nvo3-dt-encap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Private mailing list for internal NVO3 Encapsulation Design Team discussions <nvo3-dt-encap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3-dt-encap>, <mailto:nvo3-dt-encap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3-dt-encap/>
List-Post: <mailto:nvo3-dt-encap@ietf.org>
List-Help: <mailto:nvo3-dt-encap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3-dt-encap>, <mailto:nvo3-dt-encap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2017 20:28:00 -0000

> In the security section you provided text for, we talked about the
> possibility of authenticating the tunnel header and payload via extensions
> to address concern of spoofing VNI and payload security.

Please look at draft-herbert-gue-extensions, that draft realizes the
"possibility of authenticating the tunnel header and payload". These
extensions could, along with the others in that draft, be considered a
good set of fundamental extensions. They could be implemented as TLVs
in Geneve. One caveat though-- processing order of extensions is
important. For instance, it makes sense to authenticate the header
before decrypting the payload. Processing order in GUE is not an issue
since bit-fields allow random access at O(1). This is harder with
TLVs. Searching for one particular TLV is an O(N) operation for number
of TLVs in packet, searching for M of them becomes O(M * N). There are
known techniques to get the search back to O(N), but they tend to be
somewhat complex. One common method is to build a scoreboard in one
walk over the TLVs and then processing them in order from the
scoreboard-- this is how we implement options processing in TCP.

> If you think we need to beef the text more to discuss how C bit could help?
> Or how can we withstand DOS attack? Please suggest some text?
>
The problems of TLVs, particularly that they are unordered, require
iterative processing, and are susceptible to DOS are well known. I and
others have raised these issues as serious technical concerns of
Geneve several times for quite some time now (please look through all
the discussion in nvo3 list). Not only that, there are high profile
low level dataplane protocols that have included TLVs, notably IP
options and IPv6 EHs, for which TLVs have never achieved widespread
use. It's not like we don't want to use these, in fact just last week
we proposed some good use cases for HBH options in Facebook network,
but we also seem to get tripped up by some deployed devices that don't
handle them. If you look at the discussion on v6ops you'll see a
similar story, a lot of service providers disallow IPv6 EH because
they are a known DOS vector.

Answers to how to these problems have yet to be forthcoming. The
proposed answers usually seem to involve imposing ordering
requirements on TLVs, as the draft alludes to in the discussion of
using a control plane to enforce order. But that inevitably leads to
more complexity, more error handling, and in the case of this draft
creates dependencies of the dataplane on a control plane that has yet
to be defined.

> However, wouldn’t discussing a solution such as (1) defining TLV(s) and (2)
> Exact operational characteristics be out of scope of this draft?
>
This not about knowing exact operational characteristics for the
protocol, the problem is without any implementation at all we don't
know anything about how these protocol mechanisms will function or if
they are even feasible (except that we could try to extrapolate from
experiences with similar deployed protocols as I mentioned, but then
that doesn't seem to bode well for Geneve).


Tom