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

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

On Tue, Jul 8, 2008 at 9:49 PM, Joe Touch <[e-mail]> wrote:
> 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).

I don't believe that it would involve moving any extra data, you just
update the hash context with chunks in a different order. Although I
feel it's very low cost when not used and useful where it can be used,
it is fundamentally just a trick and not that important.

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

Although some NATs do change seq numbers, I've only heard it used for
FTP PORT commands. By not including the sequence numbers in a hash,
you are really reducing the power of the signatures, but it would
still have some use (against blind sweeps of the sequence space, for
example), so it shouldn't be dismissed out of hand.

Since the option exclusion list is so general, it would seem
inconsistent if the spec was to be inflexible here. NATs which change
ports and IPs are now, sadly, almost ubiquitous and cannot be ignored.

The most general solution would be for applications to specify a 20
byte mask and a single bit to determine if the pseudoheader is to be
included. Then the TCP header for the hash is: (header & mask) |
(filler & !mask) where "header" is the header on the wire and "filler"
is key-dependent material. (Basically, a zero bit in the mask means
"replace this bit with a bit from the filler"). The bits corresponding
to the TCP checksum should probably be forced to zero by the kernel.

Since only applications can decide what should be considered an
attack, that covers all the cases, it's fast and easy to do in
hardware.

The filler needs to be 20 bytes, so I'd suggest iterating H(key),
H("\x00" + key), H("\x00\x00" + key) etc until 20 bytes have been
generated. For SHA1, only one iteration is needed. For MD5, only two.
("+" is a concatenation operator 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 security properties of these functions usually depend strongly on
the condition that no two messages be transmitted with the same nonce.
If the seq number were to be taken as the bottom 32-bits of a nonce
counter, we could still hit the situation where two different packets
were transmitted with the same nonce. For example, a host acking data,
but not transmitting any itself. If we included both seq and ack in
the nonce, then I believe the retransmitted ACKs with and without SACK
options could still break this.

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

I don't see that's a big problem: The host maintains a belief of the
high 32-bits (H) of the counter and the last low-32 bits that it saw
(L). For each packet with a new sequence number (S):
  If the distance from L..S is < S..L (mod 2**32) then assume
out-of-order reception; if L...S crosses a rollover, decrement H. L <-
S.
  Otherwise, if S..L crosses a rollover, increment H. L <- S

This can be confused by massive reordering. However, that just leads
to the packet being rejected and it's probably been retransmitted
anyway. Also, if a huge number of packets were lost the hosts could be
knocked out of sync. Some additional logic could cope with this
(assume it might have happened and check the MAC for another sequence
number), but I believe that the window would have to be about 2GB big
for this to happen.

So, I believe the non-uniqueness problem is much greater.

Cheers


AGL

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