Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)

[Wesley Eddy <[e-mail]>]

On 9/22/2021 11:34 PM, Benjamin Kaduk via Datatracker wrote:
> (1) We incorporate some long-standing enhancements that improve the
> security and robustness of TCP (in particular, random ISN and protection
> against off-path in-window attacks come to mind), but only at SHOULD or
> MAY requirements level.
>
> For example, we currently say:
>
>     A TCP implementation MUST use the above type of "clock" for clock-
>     driven selection of initial sequence numbers (MUST-8), and SHOULD
>     generate its Initial Sequence Numbers with the expression:
>
>     ISN = M + F(localip, localport, remoteip, remoteport, secretkey)
>
> and:
>
>           +  RFC 5961 [37] section 5 describes a potential blind data
>              injection attack, and mitigation that implementations MAY
>              choose to include (MAY-12).  TCP stacks that implement
>              RFC 5961 MUST add an input check that the ACK value is
>              [...]
>
> What prevents us from making a MUST-level requirement for randomized
> ISNs?  Is it just the fact that it was only a SHOULD in RFC 6528 and a
> perception that promoting to a MUST would be incompatible with retaining
> Internet Standard status?

I don't think a MUST for the specific expression used to generate a 
random ISN is necessary since there could be other expressions that 
suffice, and there is no interoperability concern as this is totally 
local to the host.


> Likewise, what prevents using stronger normative language (e.g., MUST)
> for the RFC 5961 protections?

At the time 5961 was published there were both concerns with the IPR as 
well as alternative approaches to achieving the needed robustness, and 
the working group explicitly decided on the requirements language after 
a lot of discussion.


> (2) I think this is just a process question to ensure that the IESG
> knows what we are approving at Internet Standard maturity, though it
> is certainly possible that I misunderstand the situation.
>
> In Section 3.7.3 we see the normative statement (SHLD-6) that "when the
> when the effective MTU of an interface varies packet-to- packet, TCP
> implementations SHOULD use the smallest effective MTU of the interface
> to calculate the value to advertise in the MSS option".  This seems to
> originate in RFC 6691 (being obsoleted by this document), but RFC 6691
> is only an Informational document and has not had an opportunity to
> "accumulate experience at Proposed Standard before progressing", to
> paraphrase RFC 6410.

In this case, I believe what 6691 says is in accordance with what widely 
deployed code has done for a long time.

I would not make too much of the fact that it's Informational, as it 
wasn't changing the protocol at all, simply providing clarifications and 
correction to mis-statements in older RFCs.


> Similarly, Section 3.9.2 has (SHLD-23) "Generally, an application SHOULD
> NOT change the DiffServ field value during the course of a connection
> (SHLD-23)."  This is a bit harder to track down, as the DiffServ field
> was not always known by that name.  I actually failed to find a directly
> analogous previous statement of this guidance (presumably my error), and
> thus don't know if it had any experience at the PS level or not.

Actually this is prior advice that was widely discussed in the IETF and 
went into RFC 7657 (and the sections referenced in the clip below 
explain why in greater detail):

    o  Should use a single DSCP for all packets within a reliable
       transport protocol session (e.g., TCP connection, SCTP
       association) or DCCP connection (see Sections5.1  <https://datatracker.ietf.org/doc/html/rfc7657#section-5.1>  and5.3  <https://datatracker.ietf.org/doc/html/rfc7657#section-5.3>).


> (3) This is also a process point for explicit consideration by the IESG.
>
> Appendix A.2 appears to discuss a few (rare) scenarios in which the
> technical mechanisms of this document fail catastrophically (e.g.,
> getting stuck in a SYN|ACK loop and failing to complete the handshake).
> Does this meet the "resolved known design choices" and "no known
> technical omission" bar required by RFC 2026 even for *proposed*
> standard?

The TCPM WG has discussed these issues in the past, the referenced I-D 
explains the effect in the real-world and how it's been mitigated in 
different OSes.  There hasn't been consensus that anything needed to be 
done.


> (4) Another point mostly just to get explicit IESG acknowledgment
> (elevating one of Lars' comments to DISCUSS level, essentially).
>
> As the changelog (and gen-art reviewer!) notes:
>
>     Early in the process of updating RFC 793, Scott Brim mentioned that
>     this should include a PERPASS/privacy review.  This may be something
>     for the chairs or AD to request during WGLC or IETF LC.
>
> I don't see any evidence to suggest that such a review actually
> occurred.  Do we want to seek out such a targeted review before
> progressing?

I don't think it occurred.  It was a suggestion at the time when it 
seemed like the IETF wanted to do this for all or most documents, but it 
doesn't seem like that has continued, and in this case, I'm not 
personally clear that there is a lot of value, since this is not a new 
protocol and we haven't added any new mechanisms, options, etc. in this 
particular document that would really motivate specific review.