Re: [Int-area] Intdir early review of draft-ietf-intarea-gue-06

Tom Herbert <> Tue, 05 March 2019 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 955A6130DC8 for <>; Tue, 5 Mar 2019 11:50:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qE-jUn_Oeeba for <>; Tue, 5 Mar 2019 11:50:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA05A129508 for <>; Tue, 5 Mar 2019 11:50:28 -0800 (PST)
Received: by with SMTP id z39so10256938qtz.0 for <>; Tue, 05 Mar 2019 11:50:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=847T6IxPxZh71KRkHygFAI4JXdb1uCldcoeJldCcoCs=; b=EjLV9+fGwaZ0+B8+NgdV8aou3JUA2edobL/SzBFyc37McCmjf6Qaz5E7Kdfj67B9Y9 Qs76nV0EvAqrQY9lnvsoArwNB26TLdYI0F9QSJwJd7yDCIbrVF7WUg9BU75E/4E2vqQc KZUHhzMPVXooyChW/6cU/OiG0qFMkylHuKz7dFJklEkMbQgnSJw9+GIt64+Q8wqulful vHyCkQlPjwU+5+yl7OGvsKVoxMSUeA62ToAnsJ+paf6qq8ovl52WfvG6/n4wUFao++49 airlmqxJ11CPPy6PxgMbqWM58o9CWYFTGQGy7MgPeM/jNn+dkErI1diWpsn6NYSteeBk mgag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=847T6IxPxZh71KRkHygFAI4JXdb1uCldcoeJldCcoCs=; b=Aa//rv4C6P2QCvd9Kn3v5zzHuW6zB+1Rvja3sz5ort0GIuyP0xGxCqPR8WGzgnXCT8 0K75aSeP74YDqSHjXYGjOarX/HSrX/O2rSzuXUVceFesENnpplnLU3716RjU1xZStMpy DqkbzrAKX5QFCKuEtEB0Pk2f3ZWRn2bf4kIHx1YwFCqQBryaw+fEjwBdUVqPVOADH9LO 63YQpLs+fZSmslzEixrBvvF+q+OWHxbOn1+bTTzwl3o886cFupToHGm0ZVu+QDPBe/9f UJsGQnlBALHAsHKH0SMzohaw16QCGAXumwEoTnFZ5n5iJIz4XWAO6hLUq7Hi7OBbR6N7 X6eA==
X-Gm-Message-State: APjAAAVAxyElAboJjWB3mmxVi+KxSebz/s2w9wbH2RHIoWpluTID+t+Z 98+hBq5zRfSffY/nPOtRbQe3W0nOWXTN1Awv9zmDiQ==
X-Google-Smtp-Source: APXvYqyIY++rWVjW8dMz5j/LnmB1au47ulsIo/I5yhfJUNhwgWIiW6ErX4QS3ja6piRfVFjTlgNjYP5BUZnMdH1+F3Y=
X-Received: by 2002:ac8:2c5a:: with SMTP id e26mr2770990qta.189.1551815427813; Tue, 05 Mar 2019 11:50:27 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 5 Mar 2019 11:50:16 -0800
Message-ID: <>
To: Charles Perkins <>
Cc:,, int-area <>, IETF-Discussion <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Int-area] Intdir early review of draft-ietf-intarea-gue-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Mar 2019 19:50:33 -0000

Hi Charlie, thanks for the review!

On Thu, Feb 28, 2019 at 7:00 PM Charles Perkins <> wrote:
> Reviewer: Charles Perkins
> Review result: Almost Ready
> This document needs an applicability statement which includes the assumptions
> and the reasons it might be useful.  Deliverability needs to be expanded.

I will add an applicability statement.

> Reasons why middleboxes would be unlikely inspect GUE fields might be included.
See comment below.

> For instance, the discussion in second paragraph of 5.11.1 belongs in the
> applicability statement.

> It should also be explained why arbitrary GUE extensions are less likely to be
> filtered out compared to IPv6 destination options.

I'll clarify the requirements about middle boxes parsing and
processing GUE headers and make it clear MUST NOT to do this and a
SHOULD NOT for inspecting GUE header. However, as long as GUE is in
plaintext and sent to a well-known port number there's nothing we
could do to prevent middlebox inspection or this sort or filtering if
someone really wants to do it. In fact the draft assumes inspection
will happen and sets requirements for it. Authentication of the GUE
header would at least be a way to detect if middelboxes modify the

> ============================================== The document assumes close
> familiarity with deployment scenarios that seem to be characterized by acronyms
> such as RSS, aRFS, TSO, LRO, etc.  While I am pretty familiar with a lot of
> encapsulation techniques, I had to study the meaning of these acronyms.  If it
> is intended to effectively restrict the intended audience, that is O.K., but
> otherwise more background is needed along with relevant citations.

I'll add some referecences, however note that this is in the appendix
(although Appendix A doesn't have the blurb about just being
informative so I'll add that).

> ============================================== [GUEEXTENS] is cited in a way
> that places a normative dependency on [GUEEXTENS].  So, [GUEEXTENS] belongs in


> the Normative References. ============================================== I have
> a large number of specific comments which I will post shortly in the form of a
> rfcdiff-generated file.