Re: [I2nsf] Tsvart last call review of draft-ietf-i2nsf-applicability-13

"Mr. Jaehoon Paul Jeong" <> Sun, 21 July 2019 05:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7DFB12006A; Sat, 20 Jul 2019 22:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.489
X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=1.499, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gOhgxpQ_pfCa; Sat, 20 Jul 2019 22:19:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 681E812004C; Sat, 20 Jul 2019 22:19:07 -0700 (PDT)
Received: by with SMTP id n9so36043383wru.0; Sat, 20 Jul 2019 22:19:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xj+fVFOz4AH5K7YXHx/yFU5+qaxrvl2+nqzAQSI0k0c=; b=VmZ82MAlgRX7B7osXVGGBkq+kEPYpvV+TbP0EplylFEqjXKHvxLLfk4Jlmb/zhXzJ+ SE47LQ01GL7Zx4mIgocNjxjYnxkz+Ejzgebn5DTsHa/VOv2WZ97FrKyLhlvzus5bO/hj WsBUQuZewSHAeS7Wva24pfPMERcL6uwkJUiM8ozdiOEBl+NVjdPEvaPtAIIPHprpaUyU 5WszKdFbacNmQYeUtKsV9nTIPdlP8nHuf01nPwhRXhsQ/Rqc9ICmR+UoqHnkbqAwPk9H SWl9bYctG0pinfirDtVY04WuwDhjHXhhDwhjHZgSMwtyogXjyTL8th7gj7NfAyi3NjiC 6+0Q==
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=Xj+fVFOz4AH5K7YXHx/yFU5+qaxrvl2+nqzAQSI0k0c=; b=XouXbWUWRNGFcpuAvXRsKob/3vqYVn2oB9CqaYyMs3GzOc3VzclOfQd1rsFfS+iQgy 5Kv6zQOyUBUS4A/bVF0B053RlK4daHvyywIuxOOfbPtb7dTNP9aJQ2UQxmVGP7l+grSI qtF8QlI4aaRTFFzfwfIFx0m5ix9nsLuf939eqIZq4qSBC0wsxxhJ3u5wBsK4lTorAKEd 2ofEFXNoAz7fjdwATf+pXq3lw6kcAyDeEMlvyD6R2rDjsS6Towyoq4uI7gdejMtrwlNQ 1oaKwfIlecWGs38F7aO7h3opif+3tMGyX9NzT5nj7FvXs5GahRuIPpuO0weF/UOkbdE2 Yo3g==
X-Gm-Message-State: APjAAAXs1Ti25Amz/8sQvsxxnUK+WW5tFRfoVd6UYhnp034JR+2HrDXX FRftGpfD08bOufD/WS66yChW5LoPCh4KBNQ+yL8=
X-Google-Smtp-Source: APXvYqxpqVjTMzu/6+wh8CuSdbRyMwOBjTPwg4SMXebQ71uZ2Z4AMtXexPqrQ+cTA/Ltc3MdVf1UB9QTpbD6XOnauSQ=
X-Received: by 2002:adf:e790:: with SMTP id n16mr50686911wrm.120.1563686345479; Sat, 20 Jul 2019 22:19:05 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Mr. Jaehoon Paul Jeong" <>
Date: Sun, 21 Jul 2019 01:18:29 -0400
Message-ID: <>
To: Tommy Pauly <>
Cc:, "" <>, IETF Discussion <>,,,, "Mr. Jaehoon Paul Jeong" <>
Content-Type: multipart/mixed; boundary="00000000000029c49e058e2a19d9"
Archived-At: <>
Subject: Re: [I2nsf] Tsvart last call review of draft-ietf-i2nsf-applicability-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Jul 2019 05:19:11 -0000

Hi Tommy,
I have reflected all your comments on version -14:

I answer your comments one by one with an attached revision letter.

If you have comments on this revision, please let me know.


Best Regards,

On Wed, Jul 3, 2019 at 4:26 PM Tommy Pauly via Datatracker <>

> Reviewer: Tommy Pauly
> Review result: Ready with Issues
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> discussion list for information.
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> if you reply to or forward this review.
> Document: draft-ietf-i2nsf-applicability-13
> This document provides an overview of how I2NSF can be used in conjunction
> with firewalls, deep packet inspectors, and DoS mitigation engines. In
> general, it is concerned with rules for packet-level inspection and
> interacts
> with transport protocols on path only by allowing or dropping packets. The
> impacts that these functions have on transports are not new or specific
> to this document.
> Beyond merely dropping or allowing packets, the document does describe in
> Section 4 a system that forwards packets between firewalls and web filters.
> This forwarding refers to RFC 7665 to explain the mechanism for forwarding.
> While this document does not present any particular transport-related
> problems,
> it does have some clarity and correctness issues. There are also some
> opportunities for referring to the impact of the firewalling systems on
> end-to-end transport flows. The issues primarily lie in the example of a
> time-based firewall system, in Section 4.
> Issues in Section 4:
> The text in this example refers several times to an "HTTP packet" as the
> unit
> of filtering. This term seems a bit misleading. Presumably, these are
> packets
> that comprise a TCP flow (potentially with TLS encryption) on which HTTP
> messages are being sent. It would be clearer to refer to the packet as
> being
> part of an HTTP session or connection. Later, in Section 6, the term "flow
> of
> packets" is used; I suggest using that term here as well.
> By referring to making decisions about "HTTP packets", the text implies
> that a
> new decision is being made on a per-packet basis, based on the URL. Any
> particular packet in a TCP flow being used for HTTP may not contain any
> URL,
> but may be a continuation of a message already in progress. To that end,
> the
> firewall is almost certainly doing some whitelisting or blacklisting of TCP
> five-tuples it is already tracking.
> There is also no discussion in the example about encrypted traffic. Unless
> the
> described system blocks or intercepts all TLS traffic (which I hope it does
> not), I would assume that a majority of relevant HTTP traffic would be
> encrypted using TLS. For any such https:// connection, the URL will not be
> visible to the firewall, and cannot be used for filtering. You may be able
> to
> infer the destination using the certificate in TLS versions prior to 1.3,
> or
> the Server Name Indication (SNI) in TLS, but even that may be encrypted.
> Based on this, I find it surprising that there is little to no discussion
> of
> using the remote (or destination) IP address or port of the TCP connection
> in
> the firewalling process; rather it discusses using the source/local IP
> address
> of the client machine, and the URL. Since the full URL will often not be
> accessible to a firewall, I would assume that the information about the
> remote
> endpoint is often more useful.
> Nits in Section 4:
> - I would suggest that you not capitalize "", but instead refer
> to
> "". - Replace 'current time is in business hours' with
> 'current time
> is within business hours', or similar. - Replace 'realizes the packet is
> toward
>' with 'detects that the packet is being sent to the server for
> ""', or similar. - It is unclear what types are allows for
> "dest-target"; the given string is a hostname, but much of the text refers
> to
> URLs.

Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Personal Homepage: