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