Reviewer: Joseph Touch
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.
Note that this review focuses on transport issues. The document's content has
not been otherwise reviewed.
Overall, there is little transport-related content in this document. As a YANG
model, there are no transport issues.
The model itself does refer to transport protocols by name. The list is
sufficiently complete.
The only key issue is the reference to ways of blocking protocols. The
"identity reject" entry below describes a variety of ways of blocking transport
protocols, buthese examples have issues. It is important that this document be
updated to give correct advice, even if in such examples.
...For example, a TCP packet is rejected with
TCP RST response or a UDP packet may be rejected with an
ICMPv4 response message with Type 3 Code 3 or ICMPv6 response
message Type 1 Code 4 (i.e., Destination Unreachable:
Destination port unreachable)."
It is not entirely clear from the rest of the context of this document, but if
this filtering occurs anywhere other than the destination IP address of these
packets then ICMP messages from routers should be used, not those from hosts.
I.e., if the issue is packets to/from a NFV service, then host errors are
appropriate, but if the issue is packets relayed through an NFV service, then
router errors should be used instead.
Additionally, assuming host errors are intended, the entry mentions ICMPv4 Type
3 Code 3 (Destination port unreachable) and ICMPv6 Type 1 Code 4 (also
Destination port unreachable), where it appears that ICMPv4 Type 3 Code 10 and
ICMPv6 Type 1 Code 1 (both “administratively prohibited”) seems more
appropriate.
That entry also incorrectly refers to use of TCP RST. TCP RST should be
reserved for actions of the receiver TCP protocol engine based on state errors,
and emitting that message requires that endpoint’s TCP to enter TIME-WAIT for
that socket pair (RFC 9293, Note 3 in Sec 3.3). It should never be issued by a
third party that might not be in a position to maintain those TIME-WAIT states.
It is also not clear it is appropriate to reject connections using this
technique, i.e., as a substitute for host ICMPs.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
