Re: [Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'

Tom Herbert <tom@herbertland.com> Sat, 01 September 2018 18:00 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C1112F295 for <int-area@ietfa.amsl.com>; Sat, 1 Sep 2018 11:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 PJk-IaIXV73z for <int-area@ietfa.amsl.com>; Sat, 1 Sep 2018 11:00:52 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 862B3130E25 for <Int-area@ietf.org>; Sat, 1 Sep 2018 11:00:52 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id r37-v6so18025013qtc.0 for <Int-area@ietf.org>; Sat, 01 Sep 2018 11:00:52 -0700 (PDT)
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=5FSaO3hyf9y4wQNJVbX5XoOKZhkwNztGlIQBDRG73iA=; b=iT+sdnagLKKL1N+waVw1NNVlZI/6q9axTGGwpkvWmXbwcgkgfeXYzbRlrpdUTSBBeX tQwMG4xgdylhxDdclpX+VQQ9KkRrzNKuchDwPYtrFvlI3C6bLothdRKCfU84j99Lt1zB 7ASNgJycDpf4Q5j31xzO5VvLTJHpv3LAXLCL1BwSP4/90VPCoPIFmdxsfn5DaTiQQR61 mQFKupmxsh9BoMssYXL4pHAs5KwaktaPGNSBthXqt8imUXPUWI4HlSzDx9vYlTtS20Iv Ogxsf2kO6+OnieGzCs3pmfJX03DWvgQsl7diaWDMS5XxYzDIkdux29O7c6UxMnrha5oX fv/g==
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=5FSaO3hyf9y4wQNJVbX5XoOKZhkwNztGlIQBDRG73iA=; b=EMK/Tto3Oo9BXSLOe7wfndDLmsZ7Fpc67E5GCZYdcqWRMs5amHfTvqs2kzLM4UMFww EbTudyuZ+v1MLYzcVBPW8SmN+Ce3fau5uQ/7dS63hwXcdyAEmgCPPEpp5yDR6zvX70vp 4EY8E8mLBU9aqCYbM1v78s4NdsEU9DdVYE+hK5lAWEN876GiZo5CgynKnll5d5qDJ98m 6oFNT7XOoDFijjwhzvs9IadDQPZHiF/ap9mIQVi6ouq2mP34815QrundOyXiFVICakOj ohAVN0ZlPxYD7pFIwNvPuLudBlkKzfApjG8/lJ5zRf9WYDoQsWL2nw1sLzupxXW+e660 BLgw==
X-Gm-Message-State: APzg51BfvMCuDGysWpw32z56P1ZEwUpTr3i2MS2sXVAJlTH5AszqYVnY PcZmPYZgpMwDsFJDvpdBfb9GpaPan5e/liCkfP/Z9A==
X-Google-Smtp-Source: ANB0VdbwdBM2OdH6xi+c9w0tY8S9DkrQF35dqZnbZQFYPqJWoeibb4N1jQOXKbu6aLePsZv/Azlx+dVIKPQ677Un9uU=
X-Received: by 2002:a0c:fa08:: with SMTP id q8-v6mr19146201qvn.179.1535824850688; Sat, 01 Sep 2018 11:00:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:aed:24fa:0:0:0:0:0 with HTTP; Sat, 1 Sep 2018 11:00:49 -0700 (PDT)
In-Reply-To: <5f0785d6-3a3e-6df7-9b82-989fd4f78219@strayalpha.com>
References: <f1cf017dec464a8c8d2cd0dc3e6d60db@XCH15-06-08.nw.nos.boeing.com> <CALx6S378juGPjuM0eB=tG8GizJ+5tnY8n6Zr+buKvY=469KbeA@mail.gmail.com> <b3bdd6ff7ec94dbda572a49eb1e019d8@XCH15-06-08.nw.nos.boeing.com> <5f0785d6-3a3e-6df7-9b82-989fd4f78219@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 1 Sep 2018 11:00:49 -0700
Message-ID: <CALx6S359UhJuMVGZqb2GmyY23-R9NCtYcXHsk-LhhRJOEXPMhw@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, "Int-area@ietf.org" <Int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/VqEYQQ0LRTcHgwGpNG710bqlXpM>
Subject: Re: [Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Sep 2018 18:00:54 -0000

On Fri, Aug 31, 2018 at 7:16 PM, Joe Touch <touch@strayalpha.com> wrote:
> Hi, all,
>
> On 8/30/2018 8:29 AM, Templin (US), Fred L wrote:
>
> Section 3.2.1:
> Final paragraph beginning: "IP protocol number 59 ("No next header") can be
> set
> to indicate that the GUE payload does not begin with the header of an IP
> protocol."
> The example given was GUE fragmentation, but would that not represent a
> departure from the way things are done for IP fragmentation? I believe in
> IP fragmentation the protocol field contains the same value for both initial
> and non-initial fragments. Is there a reason for the departure here?
>
> Yes. GUE allows a node to skip over the GUE header to inspect the
> encapsulated payload, For instance, a firewall may be looking for an
> inner IP destination in an encapsulated packet. The GUE payload is
> interpreted based on the protocol in the Proto/ctype field. So if the
> payload is not a parseable IP protocol (like it would be for a
> non-first GUE fragment), then 59 is used to avoid devices trying to
> parse it.
>
> I am OK with ipproto-59. In hindsight, maybe IP fragmentation should have
> adopted a similar convention when it was specified so many decades ago.
>
> FWIW, IP fragmentation copies the IP header in each fragment because that
> field is part of the context for the ID field; i.e., ID MUST be unique
> within src/dst/proto. If fragments had a different proto field, it would
> undermine that context.
>
Hi Joe,

The GUE fragmentation option includes a orig-proto field to hold the
protocol of the reassembled packet. That needs to be matched in all
fragments along with srd/dst and ID, Also the protocol field in the
GUE header of the first fragment must also match. So the ID space is
basically defined the same way as IP fragmentation.

Tom

> Joe