Re: [tcpm] TCP-AO: Text for New_Key Process

At Tue, 27 Jan 2009 13:34:20 -0800,
Joe Touch wrote:
> I'll kick off discussion on this point on the list.
> 
> IMO, this mechanism is not viable for TCP-AO; it requires generating
> (and consuming) TCP segments that a native TCP would not generate. I was
> under the assumption that our design space was as close to TCP MD5 as
> possible, i.e., augment existing segments with a new option, but neither
> generate nor consume new segments.

I think it's important to separate two issues:

1. How can an implementation decide when it's safe to use a newly installed
   key?
2. How can an implementation help a peer implementation make that decision.

I think it's pretty clear that the most natural way to answer question
(1) is "when you see a segment protected with that key". Unfortunately,
this creates a deadlock problem since both sides are waiting for the
other side to use the key. Thus, we need a combination of two 
methods:

1. If a node has two keys, OLD and NEW, as soon as it sees a segment
   from the peer protected with NEW, it starts sending with NEW.
2. If a node has two keys, OLD and NEW, and it's still using OLD
   it occasionally experimentally sends a segment with NEW (probing).

Taken together, these rules allow a clean transition, since both
nodes are in probing state until one node receives a packet with
NEW, at which point it switches over and the peer soon follows.

The question then becomes how the probing mechanism works. At a 
high level, there are two options:

1. Probe with packets that the TCP stack would already send.
2. Generate new segments to use explicitly as probes.

The advantage of (1) is obviously minimal impact on the stack,
but may mean that segments are lost and could unless cere is taken,
exert false congestion feedback. The advantage of (2) is that it 
is less likely to create false congestion feedback, but it requires
more changes to the stack and of course creates additional traffic
on the wire. Greg's mechanism is of course of type (2).

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm