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

Tom Herbert <tom@herbertland.com> Thu, 16 February 2017 23:26 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 4DCD91294E9 for <nvo3-dt-encap@ietfa.amsl.com>; Thu, 16 Feb 2017 15:26:16 -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 XM_amNAqEGI4 for <nvo3-dt-encap@ietfa.amsl.com>; Thu, 16 Feb 2017 15:26:14 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 E7C87129485 for <nvo3-dt-encap@ietf.org>; Thu, 16 Feb 2017 15:26:13 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id 11so30327664qkl.3 for <nvo3-dt-encap@ietf.org>; Thu, 16 Feb 2017 15:26:13 -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; bh=a7gICHU0zFrkWf0PBdW1ppiAeHWLcZEwHpmQl6Rcxjw=; b=dG3MVS5sPO9yCbFOxAAg/1Owsddqq8eJ2MDb8dAxoAG5UWR7cbcK5P7jub2zqWuoso RVm5jPEdHT24EcMlUjogORFw9GZV/Ecq35BFOLJPsqvqJoZNCd8esnvqE6xlHXsVG3oB Z474i6/OwZD2quqd+38GimWe132IAqmfQIy12yD0Gqe3TGPPKA3s9iFDVSc1wmi2vGHJ x5KY6pzjSDzxdVMn4/PoEYRY/HtezeW0xo+6psl9IkhbYWMETNV2tB1skW0DhPP4m3Of zhW2ndEaE41/qRgWJQrnmnPr7HhwmeppBM/+HxwP7XirojxBEvGzfcmaRfAShh+5MJYv nxwA==
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; bh=a7gICHU0zFrkWf0PBdW1ppiAeHWLcZEwHpmQl6Rcxjw=; b=Y1prgUQDqIgLiN7GVHPycDCRLXcTFX3xTdi6j9Ve+u8tyH9iwC0yQMcjvdH3yPKgFy olAAA+24C4A9adnpxzMqj0OF6mWbsOBYnFdSpaLHoqS5B2Lktmz6TS8+hzZ/+gnl6Uqu wvMxSWNh/1iaHfaJwQGdm9q+/JCfck1oxDeK+RaJ4oIvojFKrp37w/mUvibCUdqSpXnd 3hvHCjobqxZBfLp2/Hj7EuNYa/32/G45Go3B109V67WjDDp3cw4O5aFmhh84VcYvSWDF R6+5ahituFZECLUn/MyCYRNhaJTCUagjD3rdK3vIvL5eEUQN03vVp3rUwlQyUzuL4Tnz 28gg==
X-Gm-Message-State: AMke39n3qtRJVp8byBC9lyaQOZtIhMzH86VGlfxaZQ8yRT6dEfFamn+HVcZMbbGgh2nIJBSIKO0YDo+ec5VF+A==
X-Received: by 10.55.7.2 with SMTP id 2mr5461435qkh.228.1487287572977; Thu, 16 Feb 2017 15:26:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.43.227 with HTTP; Thu, 16 Feb 2017 15:26:12 -0800 (PST)
In-Reply-To: <b2dec453-46ed-3602-4c0e-92e8e3b1f3cb@isi.edu>
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> <CALx6S34oFSkQ_bL=ike_5UNxk5P3UpB2cW0F4WSz=Vp0DotLZQ@mail.gmail.com> <53f0c27c-22c0-4ce9-d05b-6de44e6aa97d@isi.edu> <CALx6S35HKupQ+vOa9HqraeOEgo9M+zGtOs4SHsuOEoVoYCV=bA@mail.gmail.com> <b2dec453-46ed-3602-4c0e-92e8e3b1f3cb@isi.edu>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 16 Feb 2017 15:26:12 -0800
Message-ID: <CALx6S36XqDYQYChewVPN5KXLFGVvYgvT7KoYhAwgo+MBcSh9ow@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3-dt-encap/gazSIdp5tNq9u5dI-0WYfvCA1Ps>
Cc: Sam Aldrin <aldrin.ietf@gmail.com>, Sami Boutros <sboutros@vmware.com>, "nvo3-dt-encap@ietf.org" <nvo3-dt-encap@ietf.org>, "nvo3-chairs@ietf.org" <nvo3-chairs@ietf.org>, "nvo3@ietf.org" <nvo3@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 23:26:16 -0000

On Thu, Feb 16, 2017 at 1:21 PM, Joe Touch <touch@isi.edu> wrote:
>
>
> On 2/16/2017 1:14 PM, Tom Herbert wrote:
>> On Thu, Feb 16, 2017 at 1:11 PM, Joe Touch <touch@isi.edu> wrote:
>>>
>>> On 2/16/2017 12:27 PM, Tom Herbert wrote:
>>>> The problems of TLVs, particularly that they are unordered, require
>>>> iterative processing,
>>> That's trivially avoided by forcing the order.
>>>
>>> As I noted before, all that is required for equivalently easy processing
>>> is that both TLVs and bitfields use only known variants in only known
>>> orders.
>>>
>> Joe, do you know of any protocols that enforce such an ordering?
>
> No, because in most cases the "T" is intended to allow arbitrary reordering.
>
I'd feel more comfortable with calling this a "trivial" solution for
TLVs if there was a working example of protocol that has implemented
it and had been successfully deployed.

> My point is just that it isn't TLV itself that affects hardware and
> parallelization; it's the potential for variation.
>
> The same variation and need for serial processing could be true for new
> definitions for previously undefined bitfields values. E.g., consider
> that the first few bits of an IP packet determine whether the addresses
> are 32 bits or 128 bits, etc.
>
Not in the same way. At question here is how the packet is parsed to
identify the protocol fields, not how individual fields are processed.
Since TLVs are unordered that means the number of discrete packet
header formats including extensions is combinatoric. Specifically, the
number of possible combinations is

SUM(K! * (N choose K)) == SUM(N! / (N-K)!) == N! * SUM(1 / K!), for K
= 0..N which approximates to e * N!.

For bit-fields the number of possible combinations is always 2^N (or
2^(N+1) to allow both plain IPv4 and IPv6)

The former function grows at a much steeper rate. For instance, with
just 8 extensions there are 109601 possible combinations of TLVs in a
packet. For bit-fields there are just 256. So without some constraints
applied to ordering, TLVs are not amenable to use with HW
parallelization techniques such as TCAM. If the problem is
unconstrained, HW processing degenerates to be iterative over the
packet (alignment and making TLVs same size don't help here). The
situation in SW is not particularly better, bit-fields processing can
be loop free, whereas TLVs will require a loop.

Susceptibility of the TLV protocol mechanism to DOS is demonstrated
when an attacker spoofs a packet containing the maximum number of
minimum sized TLVs. An attackers job is made easier if the protocol
allows TLVs that can be ignored. For instance, to attack Geneve they
could just create a list of random tiny "ignore" TLVs and set the
C-bit to ensure the receiver processes the TLVs. An obvious mitigation
to this might be to require mandatory options to appear before
ignorable options (that is introduce a weak ordering requirement).
With that the C-bit could be completely eliminated since it's just as
easy to check the type of the first option to see if mandatory options
are present. Also, if the receiver only processes mandatory options
then they know to stop processing when they hit the first
non-mandatory option. This might be sufficient defense against the DOS
attack I described, but then of course if everyone were to ignore
non-mandatory TLVs in this manner then we'd have to ask what the point
is of even including them in the protocol definition.

Admittedly, without any actual TLVs defined in Geneve all of this is
all just speculation on my part!

Tom