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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Tommy,
I have reflected all your comments on version -14:
https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-14

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

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

Thanks.

Best Regards,
Paul

On Wed, Jul 3, 2019 at 4:26 PM Tommy Pauly via Datatracker <[e-mail]>
wrote:

> 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
> IETF
> 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
> [e-mail] 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 "Example.com", but instead refer
> to
> "example.com". - Replace 'current time is in business hours' with
> 'current time
> is within business hours', or similar. - Replace 'realizes the packet is
> toward
> Example.com' with 'detects that the packet is being sent to the server for
> "example.com"', 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: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>