Subject: Re: [tcpm] tcp-auth-opt issue: replay protection

From: Joe Touch <[email-masked]>
Date: Fri, 01 Aug 2008 11:44:19 -0700

Adam Langley wrote:
...
|> | So, two salient points:
|> | 1. When the sequence number is in the region of 0 (more precisely
|> |    while there are unacked segments on both sides of the region),
|> |    then the sides must maintain two keys and arrange to use
|> |    the appropriate one.
|>
|> Eric - can you explain "arrange to use the appropriate one"?
|
| I believe Eric is discussing the case where the keys change because of
| a rollover. Since packets may be reordered, a host past to remember
| both the keys for the previous period and the keys for the current
| period in case a reordered packet comes in. It's unclear, to me, which
| key retransmitted packets would use.

IMO: retransmitted packets would use the currently active keyID (even if
different from what was previously transmitted).

The ESN they would use would depend on the sequence number in the packet
(it can't depend on anything else, AFAICT). Using your 'nearness'
algorithm should suffice for that.

Joe

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 6 Aug 2008 14:32:02 +0300

> different from what was previously transmitted).

I agree. TCP retransmits previous data, not previous segments.

Lars (as an individual contributor)
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 06 Aug 2008 06:37:34 -0700

At Wed, 6 Aug 2008 14:32:02 +0300,
> I agree. TCP retransmits previous data, not previous segments.

I agree it should be permissible to use the new key-id, but
should it be required? I don't know a lot about
TCP stack implementations, but do any of them currently save
existing packets and just retransmit them? That's legal, right?
If so, this would break that.

I would argue that if we are to use internal key rollover to handle
seqno rollover that you then use the old key even when you retransmit. [0]
Otherwise, you end up with ambiguity about which key is in play.

-Ekr

[0] Incidentally, this is an argument for ESNs, I believe. If you
have a key-id transition at the same time as a seqno rollover, you
might have ambiguity about whether the key had rolled over in
between in the face of packet loss.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 6 Aug 2008 17:06:14 +0300

On 2008-8-6, at 16:37, ext Eric Rescorla wrote:
> should it be required?

I don't think we need to require that the new key be used. I was  
trying to argue that we shouldn't require that the old key be used.

> I don't know a lot about

I don't think saving sent segments makes a lot of sense. It may work,  
but ACK/SACK and timestamp information of the old packets would be out  
of sync relative to the current connection state, so I'd expect there  
could at the very least be inefficiencies. Unless I'm misremembering,  
all the stacks that I'm familiar with create a new segment for  
retransmitting lost data with TCP control information that accurately  
reflects the current connection state.

Lars

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 6 Aug 2008 07:57:05 -0700

> I don't think saving sent segments makes a lot of sense. It 
> may work, but ACK/SACK and timestamp information of the old 
> packets would be out of sync relative to the current 
> connection state, so I'd expect there could at the very least 
> be inefficiencies. Unless I'm misremembering, all the stacks 
> that I'm familiar with create a new segment for 
> retransmitting lost data with TCP control information that 
> accurately reflects the current connection state.

FWIW :
Since you are talking about implementations, stacks which care about
efficiency would still use the same old packet (assuming no
re-packetization needs to be done) and will simply re-do the necessary
fields (timestamps, ACK/SACK, MD5 etc.,) and transmit the packet.
Clearly, the ammount of work you need to do to fix-up the packet for
retransmission depends on how many options are there and how much
information has changed. [Again you don't expect the IP options to be
changed in between retransmissions]. This is different from fetching a
new packet and copying the data and fixing up all the information, which
is less efficient.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Aug 2008 08:03:38 -0700

Eric Rescorla wrote:
| At Wed, 6 Aug 2008 14:32:02 +0300,
| Lars Eggert wrote:
|> On 2008-8-1, at 21:44, ext Joe Touch wrote:
|>> IMO: retransmitted packets would use the currently active keyID
|>> (even if
|>> different from what was previously transmitted).
|> I agree. TCP retransmits previous data, not previous segments.
|
| I agree it should be permissible to use the new key-id, but
| should it be required? I don't know a lot about
| TCP stack implementations, but do any of them currently save
| existing packets and just retransmit them? That's legal, right?
| If so, this would break that.

<indiv hat on>
Does anyone know what happens to other options? I.e., aren't timestamps
recomputed, SACK options recalculated, etc.? It seems like the options
need to be revisited when a segment goes out the door anyway, and a
stack that just replays segments is what might be considered "broken"...

Joe

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Wed, 6 Aug 2008 10:12:05 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Joe Touch
>Sent: Wednesday, August 06, 2008 11:04 AM
>To: Eric Rescorla
>
>Eric Rescorla wrote:

I think you're 100% correct in assuming the options are recreated for
retransmissions.  The only stacks I've seen that store segments in
order to do a retransmission are oddball ones for teeny-tiny systems,
and they don't do any TCP options in those stacks anyways, so they
definitely would not be concerned with the Auth Option.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Adam Langley" <[email-masked]>
Date: Wed, 6 Aug 2008 08:48:00 -0700

> stack that just replays segments is what might be considered "broken"...

I can speak for the Linux stack:

Buffers are kept around for retransmissions, but the buffers only
maintain the segment data. TCP and IP headers are recreated without
any reference to any previous transmissions.

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 6 Aug 2008 12:55:13 -0400

> any reference to any previous transmissions.

That's also true of most TCP offload solutions I've seen.
Fundamentally, it is easier for almost all implementations
to keep a descriptor of a transmitted segment around (and
not allow the client to re-use its buffer) than it is to
keep a full copy of the formed TCP segment around. After
all, even in networks with atrocious drop rates the typical
TCP segment will NOT be retransmitted. Since retransmission
is the exception MOST implementations would rather redo
the TCP header construction than use memory to remember
exactly what they did last time. It's easier to just remember
enough so that you will generate the same output.

Specialized designs and/or prototypes are more likely to
do things like follow strict layering where they might
actually store the entire frame to simplify interfaces.
But those designs, in my experience, will be the exception.

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Aug 2008 11:37:49 -0700

<indiv hat on>
I am hoping a TCP-AO implementation could be made in one of two
localized places:

	a) localized to where existing TCP options are handled

	b) localized to a bump in the stack between TCP and IP

Solutions that require modifying code throughout the TCP stack would be
less useful than something that supports the above, AFAICT.

Joe

---

From: Ron Bonica <[email-masked]>
Date: Fri, 08 Aug 2008 13:32:19 -0400

> I agree it should be permissible to use the new key-id, but

I think that implementations SHOULD use the new key, but MAY use the old 
one, too. Either should work, so long as the receiving system doesn't 
delete the old key too quickly after having obsoleted it.

                                 Ron