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

Benjamin Kaduk <kaduk@mit.edu> Thu, 30 September 2021 21:36 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8053A1510; Thu, 30 Sep 2021 14:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-5v3v2B2KGD; Thu, 30 Sep 2021 14:36:55 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03BD3A14C1; Thu, 30 Sep 2021 14:36:53 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 18ULaems011467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Sep 2021 17:36:46 -0400
Date: Thu, 30 Sep 2021 14:36:40 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Wesley Eddy <wes@mti-systems.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tcpm-rfc793bis@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Michael Scharf <michael.scharf@hs-esslingen.de>, "touch@strayalpha.com" <touch@strayalpha.com>
Message-ID: <20210930213640.GR98042@kduck.mit.edu>
References: <163236803976.28405.5643771942452620510@ietfa.amsl.com> <ead80c3b-431a-53a5-79dc-b7347127e22c@mti-systems.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ead80c3b-431a-53a5-79dc-b7347127e22c@mti-systems.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/H2nqu_ADSAiGHmIfB_85DG81VfA>
Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2021 21:37:08 -0000

Hi Wes, Joe,

Sorry for the slow reply -- I've been a bit fogheaded this week and wanted
to be sure that I was clearheaded when writing on this topic, as it seems
particularly important to be communicating clearly.

On Thu, Sep 23, 2021 at 11:16:20AM -0400, Wesley Eddy wrote:
> 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, [...]

To be clear, my primary question here is "are randomized ISNs MUST-level
required?".  That can be separated from "is the specific quoted expression
the MUST-level way to do it?" (though I see a number of factors that
suggest that the quoted expression is in fact the correct expression, which
we can discuss later if needed).  In particular, randomized ISNs serve to
provide protection from off-path attacks, which is basically a baseline
requirement for new IETF work, these days.

I see Joe's message saying that "[t]his update does not attempt to change
existing IETF consensus", but that also merits a bit of unpacking.  The
previous standards-track documents that have content rolled into this
document had consensus when published, of course, and in the absence of
other data points we must assume that such consensus continues to hold.
However, I see several other data points that have appeared since the
publication of the documents in question, and as I consider all those data
points I see a very real possibility (note: not certainty) that the current
text of this document does not actually reflect current IETF consensus.  If
we consider, for example, QUIC, a protocol in some ways highly analogous to
TCP, the design considerations for QUIC could be said to include "encrypt
everything you can, and randomize the things you can't encrypt".  Even the
inclusion of a single unencrypted ("spin") bit in QUIC was done only after
extensive and controversial discussion, as an optional feature that is
forbidden from being always on, to allow for a reasonable anonymity set
that obscures which endpoints have specifically disabled it.

In light of the historical context and deployed reality, "encrypt
everything you can" for TCP means "encrypt nothing" (at least as part of
the core protocol spec), but that does not prevent us from acting on
"randomize everything else".  So, while I see Joe's note about not
attempting to re-adjudicate consensus on these points while producing this
document, I'm not sure that we can avoid some level of re-adjudication.
Even producing clear guidance on when it is safe/appropriate to ignore the
recommendation (e.g., use predictable ISNs) might suffice to reconcile the
apparent conflict, in the form of more specific guidance that overrules the
otherwise-conflicting general advice.  I might be able to help suggest some
text of this nature if appropriate, but will need a bit more of guidance
for search queries to find the relevant content in the archives than "long
threads in the archives for the RFCs that were 'rolled in'".  (IETF LC?
WGLC?  Earlier?)

I note additionally (responding to Joe's remark about needing RNGs on all
TCP endpoints, including IoT and legacy devices), that randomizing the ISN
does not require an ongoing source of new random numbers.  On the contrary,
in order to provide the required clock-derived behavior, we specifically
need to *not* get fresh randomness for each TCP connection.  We only need
one secret key that serves to decorrelate the phase of that clock for each
potential connection (4-tuple) and render the phase unpredictable to off-path
observers.  The necessary properties seem to be present even if this secret
key is set once at device provisioning time and never changed subsequently
(though of course best practices would include the ability to change it
later).

I would very much like to hear your thoughts on whether randomized ISNs as
a concept are MUST-level required, and (if not) in what circumstances
non-randomized ISNs are appropriate.

> suffice, and there is no interoperability concern as this is totally 
> local to the host.

When you say "no interoperability concern" that seems to be arguing that
because there is no required behavior for interoperability, then we cannot
put a MUST-level requirement; i.e., that we only use MUST-level
requirements when required for interoperability.  I reject that argument;
we make MUST-level requirements "all the time" when required for, e.g.,
security, even if correct behavior cannot be validated by the peer and is
thus not a strict requirement for interoperability.

> 
> > 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.

The IPR claim appears to be https://datatracker.ietf.org/ipr/421/ which was
made in 2004, some 18 years ago.  It doesn't list an application or patent
number so as to definitively conclude that the IPR has expired, but given
the typical US patent lifetime of 20 years from filing date, it may not
even still be in force by the time this document is published as an RFC.

If there are potential alternate approaches, then it seems we should
consider having the primary normative guidance relate to functionality,
with a specific mechanism given as a known way to satisfy that guidance.
(This is analogous to the proposed "MUST randomize ISNs" above vs "MUST use
this specific formula".)

But neither of those seem conclusive on the question of "stronger normative
language than MAY" for protection against blind in-window attacks, since
the "SHOULD" level is between "MAY" and "MUST", if "MUST" is for some
reason inappropriate.  In particular, it seems that the IETF consensus has
evolved since the publication of RFC 5961, and so I feel a need to attempt
to resolve the apparent disparity between what was in 5961 (and thus is
currently in this draft) and the subsequent evolution of what the IETF
seeks to provide in our protocols.

Joe points out that this behavior is not always relevant for all
implementations, which would support "not MUST" but still seems consistent
with "SHOULD".  Additionally, my sense is that it can be very valuable to
enumerate cases where these mechanisms are known to not be relevant, to aid
implementors in deciding whether or not to implement this functionality.

> 
> > (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.

To be clear: I agree with you!
I just wanted to confirm that the IESG as a whole does, too, and per our
discussion last week, that seems to be the case.

> 
> > 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>).

Thanks for the specific pointer.  This particular text does look familiar
to me, so maybe I did find it, and just wasn't sure if the transformation
to "SHOULD NOT change" was mechanical.

Regardless, my stance here is the same as for the previous point, and this
should be considered resolved.

> 
> > (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.

[The IESG seemed okay with proceeding with the current state of things]

> 
> > (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.

Thanks for conveying your recollection of (non-)history.

We discussed this in the IESG meeting, and also didn't see much value in
trying to get a formal review here.  For one, there isn't a formal review
venue that's chartered for that type of review, and it also seems that the
privacy issues with TCP are quite well-known, and the penultimate paragraph
of the security and privacy considerations section already acknowledges
that.

So in short, this point can also be considered resolved.


Thanks again for all the replies so far; I'm also curious if you plan to
reply to the COMMENT section as well.

-Ben