Last Call Review of draft-ietf-i2nsf-applicability-13
review-ietf-i2nsf-applicability-13-tsvart-lc-pauly-2019-07-03-00

Request Review of draft-ietf-i2nsf-applicability
Requested rev. no specific revision (document currently at 18)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2019-07-08
Requested 2019-06-24
Authors Jaehoon Jeong, Sangwon Hyun, Tae-Jin Ahn, Susan Hares, Diego Lopez
Draft last updated 2019-07-03
Completed reviews Genart Last Call review of -13 by Francis Dupont (diff)
Tsvart Last Call review of -13 by Tommy Pauly (diff)
Assignment Reviewer Tommy Pauly 
State Completed
Review review-ietf-i2nsf-applicability-13-tsvart-lc-pauly-2019-07-03
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/A3Si_LMfyNk8DSTqEX6TSe7cdAc
Reviewed rev. 13 (document currently at 18)
Review result Ready with Issues
Review completed: 2019-07-03

Review
review-ietf-i2nsf-applicability-13-tsvart-lc-pauly-2019-07-03

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
tsv-art@ietf.org 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.