Re: [tcpm] draft-ietf-tcpm-tcp-auth-opt-00

[Joe Touch <[e-mail]>]

Adam Langley wrote:
>> 2.2. TCP-AO Option
> 
> [snip]
> 
>> The MAC is computed over the following fields in the following order:
> 
> Currently AO is suggesting the same serialisation as TCPMD5:
>   sig = MAC(key, pseudoheader + header + data)
> 
> I suggest, instead, that the default serialisation be:
>   sig = MAC(key, H(data) + pseudoheader + header)
> 
> When the TCP stack is getting data from userspace, it generally knows
> the MSS and splits the data into packets right away. With the
> suggested serialisation, the data can be hashed as it's copied and the
> hash stored with the data. This saves traversing the data again at
> transmit time to calculate the MD5 signature. The latter is no less
> secure, I believe, and opens up possibilities for optimisation so
> should be a clear gain.

The current algorithm is optimized for the most common case, where 
TCP-AO is implemented inside the stack, and the hash is computed just 
before the packet is emitted. The same is true on the receiving end - 
i.e., in both cases, the data is processed as a single stream, whichis 
why the order is [pseudoheader, header, data]. This works well for both 
software implementations inside the stack and hardware as well.

The above is optimized assuming that the hash is computed during a copy 
operation that may or may not occur (e.g., it would not in a zero-copy 
stack), and further assumes that the copy is performed one MSS at a time 
(vs. copying the entire write() call argument, i.e., copy-on-write). 
It's not clear that optimizing the algorithm for this corner case is 
desirable, especially given the impact on more traditional 
implementations (i.e., the extra header copies/moves).

...
> Additionally, the draft already mentions an Option Kind Exclusion List
> and I'd suggest another option: that the pseudoheader be omitted and
> the source/destination ports in the TCP header be zeroed. This would
> allowed the signature to be robust to most (all?) NATs. The NAT
> workaround suggested in section 7 is impractical for many uses and a
> significant fraction of hosts are now imprisoned behind NATs.

I'd like to hear what others think of this. My view is that NATs do 
other things to TCP packets (e.g., rewrite sequence numbers, modify TCP 
options) that TCP-AO should probably detect as attacks. An earlier 
version of this work did consider replacing these values (addr/port 
pairs), not zeroing them out - i.e., replacing them with values 
determined during key exchange. I would prefer that to zeroing them out, 
though.

> Currently unspecified is a nonce for the packets. Modern MAC
> functions, based on polynomials (such as [1]), can have the very
> pleasing property of being provably within a factor as secure as
> another function (like a block cipher). However, they often require
> nonces as inputs.
> 
> A trivial solution would be to keep a 64-bit counter, increment it for
> each transmission and transmit it along with the signature. However,
> we'll struggle to fit that all in the options space; esp for SYN
> packets. Next we could consider taking the seq number as the lower
> 32-bits of a 64-bit counter. However, that doesn't guarantee that two
> different messages wouldn't be transmitted with the same nonce. We
> could just transmit the bottom (say) 16-bits of the nonce, but a
> prolonged outage could knock the endpoints out of sync. I don't have a
> good solution here.

TCP already includes a 16-bit counter - the sequence number. The use of 
longer counters that retain the high-order bits of that number were 
discussed in Philadelphia. The key problems involve retransmission at 
the edge of counter wrap; a goal of TCP-AO is to avoid modifying the TCP 
protocol itself. As you note, there didn't seem to be a good solution here.

...
> Also, is encryption of the payload considered out-of-scope for this spec?

Yes. Payload encryption is provided by SSL.

oe

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm