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

[Tommy Pauly via Datatracker <[e-mail]>]

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.