Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00

[Joe Touch <[e-mail]>]

On 1/10/2011 12:11 PM, Fernando Gont wrote:
> Hi, Joe,
>
>>> Yes, I'll be backing out SHA-256 and will go back to recommending MD5.
>>> -- As already noted on this list, this change was political rather than
>>> technical.
>>>
>>> So I assume that this would address your concern and you'd be game for
>>> std track, right?
>>
>> The specification of the PRF needs to be more detailed. I.e., state how
>> the hash is padded, byte order, and what portion of the output you're
>> using (since MD5 hashes are too long).
>
> How come that you don't deem this one as an implementation detail that
> should not concern us?

The question is really "what is this document requiring".

Is your intent to say "use MD5", and figure the rest our yourself?

If so, why bother using the "+" operator, or putting the time value 
outside the hash?

Either such details matter or they don't; if they don't, you need to 
explain why they don't. You don't *need* to spec it out to the bit level 
if that doesn't matter, but you do need to explain why you spec out some 
parts and not others.

>>>>       - this is a new algorithm, which, IMO, is experimental at best
>>>>       the alg proposed in Sec 2 is predictable for a given socket
>>>>       pair; that seems inconsistent with the security concerns that
>>>>       drive this doc
>>>
>>> Joe, this document is about mitigating blind attacks. If you know the
>>> socket pair, you can predict the ISN, unless you were able to see the
>>> ISN of a previous connection for that socket pair -- which is a
>>> completely different threat-model, that this document does not (and
>>> doesn't aim to) address.
>>
>> If knowing the socket pair means you can predict the ISN, then this doc
>> shouldn't be discussing the need for a random component or the time value.
>
> Sorry, let me rephrase: With the proposed algorithm, you can only
> predict an ISN if you know the socket pair *and* you know the ISN of a
> previous connection between the source host and the destination
> endpoint. -- But this is *intentional*.
 >
> -- We do want the ISNs to be monotonically increasing across connections

The alg you gave is monotonically increasing across connections within a 
socket pair. Presumably that's what you mean, right?

> -- hence the predictability to an *on* *path* attacker.
>
>
>>>> 2) the impact of this doc on TIME_WAIT isn't sufficiently addressed
>>>>
>>>>       most machines simply don't keep TW around as long as they
>>>>       are required; they also sometimes use a single pseudo-random
>>>>       generator across all connections; this needs to be considered
>>>>       in more detail
>>>
>>> So now you care about running code? -- It's surprising that you're
>>> raising this, instead of declaring them as bugs and be done with it.
>>
>> I'm concerned about the performance impact of declaring this a SHOULD.
>
> It's a SHOULD not a MUST. So, if anything "what are the reasons for not
> implementing this? -- Performance"?

1) per-connection computational overhead

2) the need to retain per-socketpair state for TW (vs., e.g., some 
*known* implementations that do otherwise to reduce the state needed to 
avoid TW reuse).

>>> Anyway, this document is not about the TIME-WAIT state. And proper
>>> references are included where appropriate (e.g., the reference to the
>>> CPNI TCP security document)
>>
>> If the result of this SHOULD impacts TW performance, then yes, it is
>> about TW state.
>
> Can you clearly state what your concern is? -- I just don't follow.
>
> And... What does RFC 1948 have to do with TIME-WAIT performance?

If you generate ISNs that are monotonic within a socket pair, but are 
otherwise arbitrary across different socket pairs, you NEED to keep the 
TWs per socket pair. If you want to keep less TW state, you can use a 
different mechanism.

>>>> 3) the doc should discuss how it can be implemented on a machine that
>>>> doesn't know absolute time
>>>>       even TCP's timestamps don't need to be absolute, but if a
>>>>       machine always boots the same way with the same info, it
>>>>       will reuse sequence numbers unless it has a persistent clock,
>>>>       coordinates time with another party, or has persistent state;
>>>>       none of these are necessarily true, e.g., for small devices
>>>
>>> C'mon, Joe: initialize that timer to a random value, and be done with it.
>>
>> Stand-alone boxes don't necessarily understand 'random' - if they reboot
>> and execute the same code in the same order, their 'random' is
>> deterministic. You need to address that. This relates to the other
>> concerns about some TCP mods that require state in home routers - it's a
>> valid concern. You're declaring a SHOULD; you need to explain what you
>> assume is available.
>
> Ok, my proposed text would be:
> "This specification assumes the host supports a random() function that
> provides random numbers as in, e.g. ISO C random() function."
>
> If you have anything better, please post it.

The point is that some boxes that use that function will generate the 
same value upon reboot. The fact that neither you nor I have a solution 
to this is the point - your requirement is making an assumption which is 
not true.

> That aside: What would be your concern about the node re-using the same
> ISNs? (even assuming connections are established at the same time since
> the node was bootstrapped... because you're assuming this, right?) --
> Would an off-path attacker be able to predict them? And, if not, why are
> you still concerned about it?

You need to address what your algorithm requires and what it does not. 
If you can demonstrate that there's no ill effect, then you can explain 
that, e.g., you DON'T really need the random call.

Joe