Subject: [Tsv-art] Tsvart last call review of draft-ietf-i2nsf-applicability-13

From: Tommy Pauly via Datatracker <[email-masked]>
Date: Wed, 03 Jul 2019 13:26:23 -0700

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
[email-masked] 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.

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sun, 21 Jul 2019 01:18:29 -0400

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

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 21 Jul 2019 23:05:02 -0500

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

I see that in several places the new text refers to "obtained from the
certificate in TLS versions prior to 1.3 [RFC8446] or the Server Name
Indication (SNI) in a TCP-session packet in TLS", but as Tommy attempted to
note, when draft-ietf-tls-esni becomes available, even the SNI value will
be encrypted and not visible to the network.

-Ben

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 22 Jul 2019 11:02:10 -0400

Hi Ben,
Thanks for your clarification.

I will reflect your comments in the revision as follows:

OLD:
   Thus, the IP address(es) corresponding to the target URL
   needs to be obtained from the certificate in TLS versions prior to
   1.3 [RFC8446] or the Server Name Indication (SNI) in a TCP-session
   packet in TLS.

NEW:
   Thus, the IP address(es) corresponding to the target URL
   needs to be obtained from the certificate in TLS versions prior to
   1.3 [RFC8446] or the Server Name Indication (SNI) in a TCP-session
   packet in TLS versions without the encrypted SNI [tls-esni].
...
   [tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
   "Encrypted Server Name Indication for TLS 1.3",
   draft-ietf-tls-esni-04 (work in progress), July 2019.

Is this change fine to you?

If it is okay to you, I will submit the revised version.

Thanks.

Best Regards,
Paul