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

["[e-mail]" <[e-mail]>]

Hi, Ben,

Notes interspersed below.

Joe
—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Sep 30, 2021, at 2:36 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> 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.

Yes, but TCP is decidedly old work. We are always ultra-careful to move its goalposts slowly...

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

Consensus on QUIC != consensus on TCP, for the reason stated above.

Remember that one axiom of TCP is “think twice before changing TCP, then don’t”, as a rule (I noted this as far back as IETF 60 in 2004 on this very issue). There are exceptions, of course, but they’re typically a lot more contentious and conservatively considered than for new protocols.

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

It doesn’t prevent us from acting, but AFAICT *we have not yet acted*. Although we encourage randomization, it is never a substitute for true security and should not be done at the expense of interoperability - which is especially important for TCP.

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

Agreed, but we have not - at least on this point. If we do, we really need to send this back to the WG for that - and if we allow readjudication of this point, what else?

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

Part of what needs to be considered is what you’re asking from legacy endpoints and why. Again, TCP is not QUIC.

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

I don’t know why you have this position; if the ISN of new connections can be predicted based on old ones, then all new connections after the first one after reboot can be attacked.

>  ...We only need
> one secret key that serves to decorrelate the phase of that clock

Clock? Again, you must be thinking of some other system. TCP does not start with a strict requirement of a clock. It requires only timers.

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

Randomized ISNs are useful only when I know enough about a connection to attack BUT I can’t see any traffic from that connection - and I want to perform such an attack. These attacks are typically relevant for high-value connections, e.g., BGP, where taking down a connection has consequences. We haven’t seen evidence of people attacking end system connections this way; the only benefit is to crash the connection, which can be retried. 

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

MUSTs that are local to endpoints IMO belong in BCPs, not protocol standards. They don’t define anything that prevents other systems from working.

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

That may be true, but would need to be confirmed, not just inferred.

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

There are many others, e.g., IPsec, TCP-AO, as well as simply fixing the application to not be so disrupted by an interrupted connection. For BGP, that means not dropping routes simply because the TCP connection fails (which, IMO, was never a good assumption - TCP connectivity should never have been used to infer IP reachability).

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

SHOULD is still stronger than MAY. Right now, it’s probably SHOULD where interrupting connections matters and “don’t waste your time” most everywhere else.

> In particular, it seems that the IETF consensus has
> evolved since the publication of RFC 5961,

Call me when that RFC is updated with stronger language. That didn’t happen yet, so you have (IMO) no basis for this claim.

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

It would need to be a very carefully crafted SHOULD, e.g., SHOULD for BGP, except where BGP has been fixed to not be susceptible to this issue, which should have already happened, so maybe not so much SHOULD as COULD….

(i.e., it’s not like BGP stood still either).

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

We did this already in rfc4953, in Sec 3.

I think that’s the end of my comments, or at least were you continued discussion on them.

---