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

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

Hi, Ben,

Notes below…

Joe

> On Feb 25, 2022, at 1:00 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> Hi Wes,
> 
> I'm also sorry for the slow response -- your note arrived during a
> particularly busy time, and since I was going to have to swap in a bunch of
> state on the document to reply, I needed a bigger chunk of time in order to
> produce something useful.
> 
> On Sun, Jan 09, 2022 at 11:02:12PM -0500, Wesley Eddy wrote:
>> Hello, I'm looping back on this thread, since we need to close the loop 
>> on the DISCUSS points, and address the other COMMENT contents.  Sorry 
>> for the rather slow response, but I've finally been able to process 
>> everything from your review:
>> 
>> 
>> On 9/22/2021 11:34 PM, Benjamin Kaduk via Datatracker wrote:
>>> Benjamin Kaduk has entered the following ballot position for
>>> draft-ietf-tcpm-rfc793bis-25: Discuss
>>> 
>>> ...
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> Many thanks for taking on the task of producing a roll-up update for the
>>> core TCP specification!  I am sure it was a lot of work, but I am happy
>>> to see it done.
>>> 
>>> That said, I do have a few points that I would like to have a bit more
>>> discussion on before the document is published; I'm happy to see that
>>> Warren already linked to
>>> https://www.ietf.org/blog/handling-iesg-ballot-positions/  on the topic
>>> of what a DISCUSS position can (and cannot) mean.
>>> 
>>> (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?
>>> 
>>> Likewise, what prevents using stronger normative language (e.g., MUST)
>>> for the RFC 5961 protections?
>>> 
>>> It seems to me that these mechanisms are of general applicability and
>>> provide significant value for use of TCP on the internet, even though
>>> they are not fully robust and do not use cryptographic mechanisms.  If
>>> there are scenarios where their use is harmful or even just not
>>> applicable, that seems like an exceptional case that should get
>>> documented so as to strengthen the general recommendation for the
>>> non-exception cases.
>> 
>> On this question, I don't know if you (Ben) agreed, but the final 
>> message I saw was from Joe:
>> 
>> https://mailarchive.ietf.org/arch/msg/tcpm/vDCi0xAf1Iayzsb4BS6DwlW3nhY/
> 
> That is the final message I see as well, where Joe included the statement
> "Remember that one axiom of TCP is “think twice before changing TCP, then
> don’t”, as a rule", which didn't really seem like a great sign that
> continuing the conversation was likely to be productive, so I wanted to
> wait and hear your thoughts as well before sending further replies.
> 
>> I think your question would be a good one to bring up in TCPM for future 
>> work, but the working group was trying to avoid such changes in this 
>> document.
> 
> I would like to see some stronger justification for pushing this change to
> future work rather than incorporating it now.

The primary issue is IOT devices. Requiring a clock or strong randomization simply isn’t always warranted.

> In essence, I think that we require a fairly strong justification to
> publish an Internet Standard in 2022 that says it's okay to adopt a data
> model where a host has a global piece of state that it freely sends to
> anyone who asks, where that piece of state can be used to attack/disrupt
> all new connections that host makes, as opposed to just connections on the
> 5-tuple that asked.

That’s not quite what’s happening. Just because the ISN doesn’t use either a clock or strong randomization doesn’t mean it can be guessed for new connections.

> The actual scope of utility of an ISN is local to an individual 5-tuple,
> not global to a host, and false sharing of ISNs across connections adds
> risk.  

You need to consider the overall risk, which is:

a) that you open a connection and learn an ISN
AND
b) that you can attack other connections to that host (i.e., as an off-path attacker), notably by knowing the entire 4-tuple

(On-path attackers can simply watch whatever ISN you PRF anyway).

The latter still needs to be “in window” at least, so the vulnerability is already somewhat mitigated.

Finally, the vulnerability is one that can be mitigated by the end system, e.g., by using a clock. So at best, it shoots itself in the foot.

I see no good reason to raise the bar for IoT implementations simply to prevent them from doing something with such local impact.

> My stance as SEC AD is that the IETF should produce protocols that
> are as secure as possible *subject to any constraints on them*.

Let’s please be clear that this is NOT *security*. Security would be TCP-AO or IPsec (as noted in RFC6528, sec 4).

> Here, we
> have the constraint of retaining compatibility with the existing deployment
> base (which is a very compelling constraint!), so you do not see me
> advocating for mandatory tcpcrypt (for example).  But I want to see some
> explanation of what harm or risk there is in saying that the ISN is always
> produced with the PRF of the 5-tuple (okay, 4-tuple since the protocol is
> always TCP), to motivate a divergence from the more-secure behavior and
> thereby justify retaining the behavior currently in the draft.  What
> constraint are we subject to that prevents doing the right (security-wise)
> thing?

We already have RFC6528 that specifies this as a SHOULD.

My question to you is “what has changed since 2012 that makes you think this is now appropriate for a MUST”.

AFAICT, that’s where the burden of proof is, not on us to defend keeping a SHOULD.

Joe