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

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Tue, 13 Jan 2009 23:50:18 -0800

Folks,
resend...

Neither I nor Joe have received ANY feedback on this New_Key process. 
Can people pls do a quick review and reply to me, Joe, and list with 
comments? Joe is trying to get a next version out.

Many thanks,
Gregory.

At 01:18 AM 12/19/2008, Gregory M. Lebovitz wrote:
>Hey Joe, and all.
>Below is pasted my first crack at the text for the New_Key Process. 
>All input welcome.
>Gregory
>
>==New_Key Process:
>
>[Suggest you place text about new_key at the end of section 6 in -02]
>
>One big difference between TCP-AO and TCP MD5 is that TCP-AO allows 
>for the change of a TSAD entry -- and thus the corresponding change 
>of a conn_key -- during a connection, without having to drop the 
>connection. This allows for an HMAC algorithm or TSAD_key change 
>without a connection loss. This behavior is very beneficial for the 
>optimal operation of applications with long lived connections, such 
>as BGP. The process of moving from one key to another is called "New_Key".
>
>X.1  New_Key Design Goals
>The following are the design goals of the New_Key process:
>
>  - Both sides will move to the new TSAD entry as fast as possible, 
> assuming both peers are configured with the new TSAD entry at 
> (almost) the same time. This provides the security benefit of being 
> able to move immediately off a key believed to be compromised to a 
> newly defined key.
>
>  - Support a potentially long time lag between when each peer is 
> configured with the new TSAD entry. This time could be as long as 
> two or three weeks, depending on maintenance processes and change 
> windows for both sides.
>
>  - Impact the operation and performance of the application using 
> TCP as little as possible. Cause zero, or very little, application 
> data loss or delay.
>
>  - Modify the TCP stack itself as little as possible.
>
>  - Ensure that neither side transitions completely to the new TSAD 
> entry prematurely, before the other peer has the new TSAD entry and 
> is ready to use the new TSAD entry.
>
>  - Ensure that neither side erases an old TSAD entry prematurely. 
> Implementations will hold both the old and new TSAD entries in 
> memory long enough to employ the new TSAD entry as soon as 
> possible, while still being able to properly process any straggler, 
> out-of-order segments that might arrive having been processed with 
> the old TSAD entry, even after the new TSAD entry is already in use 
> by both sides.
>
>  - Avoid moving to the use of a new TSAD entry prematurely, 
> i.e.  before the other peer is prepared to use the new TSAD entry.
>
>
>X.2 Use Cases Supported
>There are two main cases that New_Key must address. The first is the 
>case where a new TSAD entry (KeyID, MAC type, key length, TSAD_key; 
>see section 6) is configured onto both peers during a connection's 
>life. The TSAD entry may have arrived into the peers' states either 
>by manual configuration, or by some automated key management 
>exchange. Regardless the method, a new TSAD entry is installed into 
>each peers' respective state while the previous TSAD entry is already in use.
>
>[NOTE:  There is an assumption being made here that at some point in 
>the future, when a key management protocol has been defined for 
>TCP-AO, that mechanism will leverage the conn_key derivation 
>mechanism described here in TCP-AO. This means that instead of 
>negotiating ISN's and conn_keys directly, the key management 
>protocol will simply negotiate a TSAD entry, and TCP-AO will use 
>that TSAD entry according to this specification to derive its conn_keys.]
>
>The second use case involves a chain of pre-configured TSAD entries. 
>In this case, the two sides choose and exchange out-of-band a series 
>of TSAD entries to be used over time. Each TSAD entry will also have 
>the time at which the key will begin to be actually used to 
>authenticate segments, and how long the key is to be used. This 
>information is all exchanged out-of-band, and then configured into 
>each device respectively. The chains may be quite long, like 64 or 
>128 entries. The TSAD entries, the order of use, and start times, 
>must all match on both sides. The TSAD entries are then used in 
>sequential order. In this use case, the new TSAD entry is known on 
>both sides well ahead of the actual New_Key event. The key chain 
>mechanism provides a way to limit the lifetime of a particular key's 
>use on the wire. Limiting a key's lifetime protects against a 
>successful brute force guessing attack. The idea is that the 
>connection has already moved on to a new TSAD entry by the time the 
>attacker, who has been working offline to guess the key, succeeds. 
>Key chains do not protect against the termination of an employee who 
>had access to the TSAD entries. In such a case, the entire key chain 
>is assumed to be compromised, and a whole new key chain SHOULD be 
>put into use. The concept of key chains, their benefits and 
>limitations are discussed more thoroughly in the Security 
>Considerations section.
>
>
>X.2 New_Key State Machine
>
>There are three states in the New_Key state machine: SINGLE-TSAD, 
>PROBING, and TSAD-OVERLAP. The states are shown below in Figure X.
>
>X.2.1 SINGLE-TSAD
>
>The SINGLE-TSAD state is the beginning and ending state of the 
>New_Key process. It is the state in which there is one and only one 
>TSAD entry actively in use for both sending and receiving segments. 
>When a new TCP connection using TCP-AO first begins, the New_Key 
>process is initialized to the SINGLE-TSAD state.
>
>For the purpose of this explanation, the starting TSAD used in 
>SINGLE-TSAD state will be called "TSAD-X". The new TSAD entry 
>activated will be referred to as TSAD-Y.
>
> From SINGLE-TSAD it is only possible to move to PROBING state. The 
> move from SINGLE-TSAD to PROBING occurs when a new TSAD entry, 
> TSAD-Y, becomes active. According to the use cases described above, 
> a TSAD-Y becomes active when one of the following events occurs:
>
>   o  It is manually entered and activated on the device for an 
> existing connection
>   o  It is received into state as a result of a key management 
> protocol negotiation
>   o  It is the next TSAD entry in a chain, and it's start time 
> equals the current
>      time
>
>It is most common to transition into SINGLE-TSAD state from either a 
>new connection initialization, or from the TSAD-OVERLAP state (as 
>described in section X.2.3). There also exists one condition under 
>which the state may transition to SINGLE-TSAD from PROBING. This is 
>described at the end of section X.2.2 PROBING.
>
>
>                     +---------------+
>                     |               |
>                     |  SINGLE-TSAD  |
>                     |               |
>                     +------/*-------+
>                          //  \\
>      New TSAD-Y          //      \\
>     Entry Activated  //          \\      Deactivate
>                    //              \\    previous TSAD-X
>                  //                  \\  entry
>                //                      \\
>              //                          \\
>      +-----//-----+                   +----\-----------+
>      |            |                   |                |
>      |  PROBING   +-------------------+  TSAD-OVERLAP  |
>      |            |                   |                |
>      +------------+                   +----------------+
>                       Receive Packet
>                      Processed with
>                       TSAD-Y entry
>
>
>                       Figure X.
>                       New_Key State Machine
>
>
>X.2.2 PROBING
>
>The PROBING state is the second state. The goal of the PROBING state 
>is for a host A, "Alice", to signal to its peer, host B, "Bob", that 
>Alice has TSAD-Y installed and active, and is ready to use it. If 
>Bob does not have TSAD-Y then any segments sent by Alice with 
>TSAD-Y's KeyID will be discarded. Discarded segments may cause 
>retransmission and delays in the application processing. So Alice 
>wants to avoid sending application data with TSAD-Y before she is 
>certain Bob has TSAD-Y. Once Alice has TSAD-Y activated she cannot 
>yet be certain that Bob also has TSAD-Y installed and activated for 
>the following reasons:
>
>   o  Bob's administrator may not have gotten around to installing TSAD-Y yet
>   o  If using a key chain, the clocks on the two devices may be out 
> of sync such
>      that start time for Alice is not the same absolute time as 
> start time for Bob
>
>Therefore, Alice will send a probe segment, processed using the 
>TSAD-Y, to signal to Bob that she is ready to begin using TSAD-Y. 
>She will repeat this probe periodically. (The specifics of this 
>probing mechanism are described below in Section X.3.) Before Bob 
>has TSAD-Y he will not be able to process these probes, and he will 
>discard them.
>
>Once Bob has installed and activated TSAD-Y, Bob will himself 
>transition from SINGLE-TSAD to PROBING state. Bob will then send a 
>probe processed with TSAD-Y to Alice. Further, Bob will be able to 
>successfully process Alice's next probe sent using TSAD-Y.
>
>Once Alice has successfully received and processed a segment from 
>Bob that was sent using TSAD-Y, she transitions immediately to 
>TSAD-OVERLAP state. The time spent in PROBING state may be very 
>short, especially if Bob has already activated TSAD-Y and has just 
>sent a probe. Alice may not have even sent a probe yet. That's okay. 
>Once Alice successfully processes a segment from Bob using TSAD-Y 
>she knows (a) that she has the correct TSAD-Y, that (b) Bob has the 
>correct TSAD-Y, and (c) they are both prepared to begin sending and 
>receiving all following segments with TSAD-Y.
>
>It is only possible to move into PROBING from the SINGLE-TSAD state, 
>as described above in X.2.1. PROBING is distinct from SINGLE-TSAD in 
>that now there exists a second active TSAD, TSAD-Y, along with 
>TSAD-X. In PROBING, only probe segments are sent using TSAD-Y. All 
>other segments are sent using TSAD-X. Most segments received will be 
>processed using TSAD-X. Once the first received segment is 
>successfully processed using TSAD-Y, the state transitions to TSAD-OVERLAP.
>
>TSAD-OVERLAP is the most probable state that will be entered when 
>exiting PROBING.
>
>However, under one unlikely condition the state will transition from 
>PROBING to SINGLE-TSAD. In the case where:
>
>   o  a life-time has been configured for TSAD-X, AND,
>   o  that life-time expires while in PROBING state, AND,
>   o  TSAD-Y is still active, AND,
>   o  no other TSAD has yet been activated, THEN,
>   o  the only active TSAD remaining is TSAD-Y.
>
>Even though Alice has not yet successfully received TSAD-Y segments 
>from Bob, if a life-time is exceeded, the expired TSAD MUST be 
>de-activated in order to follow the configured security policy. This 
>would force the state back to SINGLE-TSAD state, with TSAD-Y being 
>the only activated TSAD entry. This condition -- where TSAD-X 
>expired before segments were received processed by TSAD-Y -- SHOULD 
>be logged, and the administrator alerted. Assuming the security 
>policy mandates the use of TCP-AO on this connection, segments MUST 
>be sent processed with TSAD-Y. Received segments MAY continue to be 
>processed with TSAD-X. However, if Bob does not activate TSAD-Y, 
>then the TCP connection will soon timeout, because Bob will discard 
>the TSAD-Y processed segments he receives.
>
>X.2.3 TSAD-OVERLAP
>
>The TSAD-OVERLAP state is the third state. Like PROBING, both the 
>old TSAD-X and the new TSAD-Y are both activated. The main 
>distinction between PROBING and TSAD-OVERLAP is that in TSAD-OVERLAP 
>the new TSAD, TSAD-Y, is the only one used for sending all segments. 
>In this state, TSAD-X is used only for processing received segments 
>that may arrive with TSAD-X's KeyID. Such straggler segments may 
>arrive because they were sent out onto the wire before the 
>transition from PROBING to TSAD-OVERLAP occurred, and are just now arriving.
>
>Once the state transitions to TSAD-OVERLAP, a counter is initialized 
>to 512. The counter decrements once per second, so TSAD-X will 
>overlap TSAD-Y for just under nine minutes. Upon reaching zero, the 
>prior TSAD, TSAD-X is de-activated. At this point the entire TSAD-X 
>entry, including its conn_keys, MAY be deleted from state. The 
>TSAD-OVERLAP counter MAY be configurable on various implementations.
>
>[Author's Thought: I have no idea if this is the best way to do this 
>timer. I chose seconds because that is how TCP does it's exponential 
>back-off timer for retransmission, the max of which is ~9 minutes, 
>from what I read in Stevens, Ch 21.  TCP gurus are welcome to refine 
>the overlap timer mechanism based on practical experience]
>
>Once TSAD-X is deactivated, the state transitions to SINGLE-TSAD. At 
>this point, TSAD-Y is the one and only active TSAD entry for both 
>sending and receiving segments.
>
>
>X.3 Probe Mechanism
>
>This section specifies the probe mechanism used in PROBING state 
>(section X.2.2).
>
>The probe is a single TCP segment sent with:
>
>   o  the TCP-AO option using TSAD-Y, AND
>   o  any other tcp options present (per section 3.2, point 4), AND
>   o  with no TCP data, AND
>   o  marked with a sequence number unmistakably smaller than the currently
>      appropriate sequence number. Precisely, where the current 
> sequence number that would otherwise be used is "S", and the probe 
> segment's sequence number is "P", P is 1024 less than S, or
>
>           P = S - 1024
>
>   [Question 1: TCP guru's, is 1024 the best number?]
>
>   [Question 2: given the empty TCP data, will we need to add 
> padding here to meet the minimum 64 byte IP packet size?]
>
>The probe is crafted so that no real application data will be lost 
>if the probe fails. This protects the performance of the application 
>being authenticated in TCP. The probe is transmitted with an old, 
>stale sequence number so that if the receiver, Bob, is unable to 
>process the probe, and discards it, there will be no perceived skip 
>in the proper sequence flow, and no retransmission required.
>
>Alice starts a standard exponential back-off timer for transmitting 
>the next probe(s). If no segment has been received with TSAD-Y, then 
>the next probe is sent 1.5 seconds later. After this the timeout 
>value is doubled for each following probe, with an upper limit of 64 
>seconds; i.e. at 3, 6, 12, 24, 48, 64, 64, 64, etc. seconds apart. 
>If at any point a segment is received that was crafted using TSAD-Y, 
>then the timer is terminated, and state is transitioned to TSAD-OVERLAP.
>
>Bob receives the probe segment, and responds in one of two ways.
>
>   (1)  IF Bob has NOT activated TSAD-Y, THEN
>
>        Bob will not recognize the KeyID in the probe segment, and 
> will silently discard the segment. Since the segment has a stale 
> sequence number, absolutely no interruption occurs to the application flow.
>
>   (2)  IF Bob HAS activated TSAD-Y, THEN
>
>        Bob will recognize the KeyID in the probe, and process the 
> segment using TSAD-Y. Assume this is the first segment received 
> with TSAD-Y; when the authentication verification processes 
> correctly Bob will state transition to TSAD-OVERLAP state. 
> Henceforth Bob will transmit all segments using only TSAD-Y. Bob's 
> TCP stack then parses the segment and reads the stale sequence 
> number. TCP responds naturally with an ACK. That ACK will naturally 
> contain the sequence number of the last received data segment prior 
> to the segment with the stale sequence number, the probe. That ACK 
> is processed using TSAD-Y, and transmitted. Thus, zero interruption 
> to the normal application flow occurs as a result of the probe segment.
>
>Once Alice receives either (a) a TSAD-Y processed ACK to her probe, 
>or (b) a TSAD-Y processed probe from Bob, she transitions to TSAD-OVERLAP.
>
>
>+++++++++++++++++++++++
>IETF-related email from
>Gregory M. Lebovitz
>Juniper Networks
>g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Jan 2009 13:34:20 -0800

Hi, all,

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.

The goal appears to be synchronization of the use of new keys. It seems
like this can be achieved operationally, e.g., as follows:

	both sides start with master key A

	both sides insert master key A with KeyID=5

	both sides connect as expected

To enable a rapid synchronization of the next key:

	both sides also reinsert master key A with KeyID=6

At this point, either KeyID=5 or KeyID=6 will work, but both sides use
KeyID=5 (by configuration).

Now let's assume we want to add a new key for that connection, but also
to coordinate its use.

	both sides receive master key B (out-of-band)

	both sides insert master key B with KeyID=7

Either side, upon inserting master key B, starts using KeyID=6. Note
that there is no loss of packets, because 6 was there back when 5 was.

Both sides monitor the keys being received; when keyid=6 is received,
then they can start using KeyID=7.

I.e., this can be done entirely with an external KMS local to each
endpoint, without requiring the KMS's to communicate. I.e., this is
automated, but doesn't require a protocol.

To some extent, this restores some of the intent of Bonica's "K" bit,
but there's no need for an explicit bit, and there's no limit to how
quickly the keyID changes happen (i.e., no need to sync when the bit
needs to be cleared or for how long).

We can put this into the doc, but IMO, it's not necessary at all. It's
completely isolated to the KMS anyway. I had already updated the API to
be able to return samples of the received KeyIDs, FWIW...

Joe

Gregory M. Lebovitz wrote:
>> for the change of a TSAD entry -- and thus the corresponding change of
>> a conn_key -- during a connection, without having to drop the
>> optimal operation of applications with long lived connections, such as
>> BGP. The process of moving from one key to another is called "New_Key".
>>
>> X.1  New_Key Design Goals
>> assuming both peers are configured with the new TSAD entry at (almost)
>> the same time. This provides the security benefit of being able to
>> move immediately off a key believed to be compromised to a newly
>> defined key.
>>  
>> configured with the new TSAD entry. This time could be as long as two
>> or three weeks, depending on maintenance processes and change windows
>> for both sides.
>>  
>>  - Impact the operation and performance of the application using TCP
>> as little as possible. Cause zero, or very little, application data
>> loss or delay.
>>  
>> entry prematurely, before the other peer has the new TSAD entry and is
>> ready to use the new TSAD entry.
>>  
>> Implementations will hold both the old and new TSAD entries in memory
>> long enough to employ the new TSAD entry as soon as possible, while
>> still being able to properly process any straggler, out-of-order
>> segments that might arrive having been processed with the old TSAD
>> entry, even after the new TSAD entry is already in use by both sides.
>>  
>>  - Avoid moving to the use of a new TSAD entry prematurely, i.e. 
>> before the other peer is prepared to use the new TSAD entry.
>>  
>>
>> X.2 Use Cases Supported
>> life. The TSAD entry may have arrived into the peers' states either by
>> manual configuration, or by some automated key management exchange.
>> Regardless the method, a new TSAD entry is installed into each peers'
>> respective state while the previous TSAD entry is already in use.
>>
>> TCP-AO, that mechanism will leverage the conn_key derivation mechanism
>> described here in TCP-AO. This means that instead of negotiating ISN's
>> and conn_keys directly, the key management protocol will simply
>> negotiate a TSAD entry, and TCP-AO will use that TSAD entry according
>> to this specification to derive its conn_keys.]
>>
>> each device respectively. The chains may be quite long, like 64 or 128
>> entries. The TSAD entries, the order of use, and start times, must all
>> match on both sides. The TSAD entries are then used in sequential
>> order. In this use case, the new TSAD entry is known on both sides
>> well ahead of the actual New_Key event. The key chain mechanism
>> provides a way to limit the lifetime of a particular key's use on the
>> wire. Limiting a key's lifetime protects against a successful brute
>> force guessing attack. The idea is that the connection has already
>> moved on to a new TSAD entry by the time the attacker, who has been
>> working offline to guess the key, succeeds. Key chains do not protect
>> against the termination of an employee who had access to the TSAD
>> entries. In such a case, the entire key chain is assumed to be
>> compromised, and a whole new key chain SHOULD be put into use. The
>> concept of key chains, their benefits and limitations are discussed
>> more thoroughly in the Security Considerations section.
>>
>>
>> The SINGLE-TSAD state is the beginning and ending state of the New_Key
>> process. It is the state in which there is one and only one TSAD entry
>> actively in use for both sending and receiving segments. When a new
>> TCP connection using TCP-AO first begins, the New_Key process is
>> initialized to the SINGLE-TSAD state.
>>
>> move from SINGLE-TSAD to PROBING occurs when a new TSAD entry, TSAD-Y,
>> becomes active. According to the use cases described above, a TSAD-Y
>> becomes active when one of the following events occurs:
>>
>>   o  It is the next TSAD entry in a chain, and it's start time equals
>> the current
>>      time
>>
>> Alice has TSAD-Y installed and active, and is ready to use it. If Bob
>> does not have TSAD-Y then any segments sent by Alice with TSAD-Y's
>> KeyID will be discarded. Discarded segments may cause retransmission
>> and delays in the application processing. So Alice wants to avoid
>> sending application data with TSAD-Y before she is certain Bob has
>> TSAD-Y. Once Alice has TSAD-Y activated she cannot yet be certain that
>> Bob also has TSAD-Y installed and activated for the following reasons:
>>
>>   o  If using a key chain, the clocks on the two devices may be out of
>> sync such
>>      that start time for Alice is not the same absolute time as start
>> time for Bob
>>
>> TSAD-Y, to signal to Bob that she is ready to begin using TSAD-Y. She
>> will repeat this probe periodically. (The specifics of this probing
>> mechanism are described below in Section X.3.) Before Bob has TSAD-Y
>> he will not be able to process these probes, and he will discard them.
>>
>> Once Alice has successfully received and processed a segment from Bob
>> that was sent using TSAD-Y, she transitions immediately to
>> TSAD-OVERLAP state. The time spent in PROBING state may be very short,
>> especially if Bob has already activated TSAD-Y and has just sent a
>> probe. Alice may not have even sent a probe yet. That's okay. Once
>> Alice successfully processes a segment from Bob using TSAD-Y she knows
>> (a) that she has the correct TSAD-Y, that (b) Bob has the correct
>> TSAD-Y, and (c) they are both prepared to begin sending and receiving
>> all following segments with TSAD-Y.
>>
>> that now there exists a second active TSAD, TSAD-Y, along with TSAD-X.
>> In PROBING, only probe segments are sent using TSAD-Y. All other
>> segments are sent using TSAD-X. Most segments received will be
>> would force the state back to SINGLE-TSAD state, with TSAD-Y being the
>> only activated TSAD entry. This condition -- where TSAD-X expired
>> before segments were received processed by TSAD-Y -- SHOULD be logged,
>> and the administrator alerted. Assuming the security policy mandates
>> the use of TCP-AO on this connection, segments MUST be sent processed
>> with TSAD-Y. Received segments MAY continue to be processed with
>> TSAD-X. However, if Bob does not activate TSAD-Y, then the TCP
>> connection will soon timeout, because Bob will discard the TSAD-Y
>> processed segments he receives.
>>
>> X.2.3 TSAD-OVERLAP
>>
>> The TSAD-OVERLAP state is the third state. Like PROBING, both the old
>> TSAD-X and the new TSAD-Y are both activated. The main distinction
>> between PROBING and TSAD-OVERLAP is that in TSAD-OVERLAP the new TSAD,
>> TSAD-Y, is the only one used for sending all segments. In this state,
>> TSAD-X is used only for processing received segments that may arrive
>> with TSAD-X's KeyID. Such straggler segments may arrive because they
>> were sent out onto the wire before the transition from PROBING to
>> TSAD-OVERLAP occurred, and are just now arriving.
>>
>> to 512. The counter decrements once per second, so TSAD-X will overlap
>> TSAD-Y for just under nine minutes. Upon reaching zero, the prior
>> TSAD, TSAD-X is de-activated. At this point the entire TSAD-X entry,
>> including its conn_keys, MAY be deleted from state. The TSAD-OVERLAP
>> counter MAY be configurable on various implementations.
>>
>>   [Question 2: given the empty TCP data, will we need to add padding
>> here to meet the minimum 64 byte IP packet size?]
>>
>> The probe is crafted so that no real application data will be lost if
>> the probe fails. This protects the performance of the application
>> process the probe, and discards it, there will be no perceived skip in
>> the proper sequence flow, and no retransmission required.
>>
>> the next probe is sent 1.5 seconds later. After this the timeout value
>> is doubled for each following probe, with an upper limit of 64
>> seconds; i.e. at 3, 6, 12, 24, 48, 64, 64, 64, etc. seconds apart. If
>> at any point a segment is received that was crafted using TSAD-Y, then
>> the timer is terminated, and state is transitioned to TSAD-OVERLAP.
>>
>>        Bob will not recognize the KeyID in the probe segment, and will
>> silently discard the segment. Since the segment has a stale sequence
>> number, absolutely no interruption occurs to the application flow.
>>  
>> segment using TSAD-Y. Assume this is the first segment received with
>> TSAD-Y; when the authentication verification processes correctly Bob
>> will state transition to TSAD-OVERLAP state. Henceforth Bob will
>> transmit all segments using only TSAD-Y. Bob's TCP stack then parses
>> the segment and reads the stale sequence number. TCP responds
>> naturally with an ACK. That ACK will naturally contain the sequence
>> number of the last received data segment prior to the segment with the
>> stale sequence number, the probe. That ACK is processed using TSAD-Y,
>> and transmitted. Thus, zero interruption to the normal application
>> flow occurs as a result of the probe segment.
>>       
>> Once Alice receives either (a) a TSAD-Y processed ACK to her probe, or
>> (b) a TSAD-Y processed probe from Bob, she transitions to TSAD-OVERLAP.
>>       
>>
>> +++++++++++++++++++++++
>> IETF-related email from
>> Gregory M. Lebovitz
>> Juniper Networks

---

From: Lars Eggert <[email-masked]>
Date: Wed, 28 Jan 2009 13:24:54 +0200

On 2009-1-27, at 23:34, Joe Touch wrote:
> I was under the assumption that our design space was as close to TCP  
> MD5 as

That's my recollection as well, and hopefully it's in the minutes of  
the WG meeting where we adopted the work item. The idea was to be as  
lightweight (in terms of changes to TCP) as possible, and changes to  
the state machine, etc. seem rather heavyweight.

Lars

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Jan 2009 08:27:56 -0800

At Tue, 27 Jan 2009 13:34:20 -0800,
> 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

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Jan 2009 08:57:56 -0800

>    it occasionally experimentally sends a segment with NEW (probing).

I've already shown a way to achieve this without requiring the use of
the NEW key, i.e., that used two KeyIDs with the OLD key, using the
change in the KeyID to inform the endpoints. I've also described in that
email a way to achieve this using the current API, without asking TCP-AO
to generate new packets or to do anything conditional _inside_ TCP-AO;
this can (and, IMO, should) all be accomplished with an external
mechanism, with __no__ impact on the stack.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Jan 2009 09:53:45 -0800

At Wed, 28 Jan 2009 08:57:56 -0800,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:

I read your mechanism, but I'm not sure it works.

The basic unit of operation here isn't keys but key-ids. It's true that
in your example key-id 6 refers to the same key as key-id 5, but that's
not something that the stack should be observing. In other words,
if you get a packet with key-id 6 and you only have key-id 5, you should
reject it, not try the key corresponding to key-id 5, so we've reduced
this to a previously unsolved problem.

If your point is that at the time I install key-id 5 I also install a
dummy key-id 6, and use that purely for signalling, I agree that that
would work, but it strikes me as extremely kludgy. There's no natural
connection between the switch from 5-6 and the switch from 5-7. So, 
no, I don't favor that approach.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Jan 2009 09:58:20 -0800

Eric (et al.),

Eric Rescorla wrote:
> not something that the stack should be observing.

The stack doesn't observe it; the stack reports it if asked to an
external process.

> In other words,

I've reduced the problem to a configuration solution, not a TCP-level
protocol mechanism. If you remove aspects of the solution (i.e., if you
don't install a key with two keyIDs), then the solution obviously won't
work. That doesn't reintroduce the unsolved problem; it reverts to the
unsolved problem when not solved (which is a tautology).

> would work, but it strikes me as extremely kludgy. 

It allows side A to tell side B when side A has a new key installed,
without causing any packets to fall on the floor on side B (note that
retransmissions, if received, could open the congestion window
inappropriately).

The mechanism I proposed achieved with no modifications to the TCP stack.

The other mechanisms suggested all have the property of also using the
KeyID value as a signal. The only downside of the mechanism I proposed
is that is inefficient in the use of the KeyID space - however, the
space is large enough that this isn't an issue.

> There's no natural
> connection between the switch from 5-6 and the switch from 5-7.

Why should there be? IMO, it's up to the endpoints to decide how and
when to switch keys; key change coordination needs to be _enabled_ by
TCP-AO, but not provided by it. IMO, that's a KMS issue - whether
automated at the endpoints, or via a protocol.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Jan 2009 10:13:41 -0800

PS - I can add the description of  my suggestion below in "how to
synchronize key rollover" if desired; IMO, it's outside the scope of the
document except to demonstrate that the mechanisms in the document are
sufficient to achieve key rollover sync.

FYI, the only change to TCP-AO needed for the mechanism I described was
to report a recently received KeyID (as a sample) when requested. That's
a very low hurdle to enable key rollover, IMO, vs. in-mechanism probing
systems.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Jan 2009 22:55:00 -0800

At Wed, 28 Jan 2009 09:58:20 -0800,
> The stack doesn't observe it; the stack reports it if asked to an

As I've indicated before, I think this whole external process thing
is overcomplicating matters. Key management daemons are a bug,
not a feature, and it would be much better if things could
be constructed so the TCP-AO module would do everything. 

> The mechanism I proposed achieved with no modifications to the TCP stack.

Yes, by laying the burden on some as yet nonexistent key management
mechanism.

> space is large enough that this isn't an issue.

That's far from the only downside.

For one, consider what happens if key 7 is misconfigured. In Greg's
system, everything works fine, because packets with MAC failures are
dropped. In your system, the 5-6 transition is used to signal the
availability of 7, but if that transition fails the connection just
falls over.

> automated at the endpoints, or via a protocol.

Again, I don't agree. TCP-AO should work fine without some additional
KMS, and that includes having unsynchronized key changes work correctly.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Jan 2009 07:15:15 -0800

> Yes, by laying the burden on some as yet nonexistent key management

We can bury the mechanism I suggest inside TCP-AO if desired, but I
think that just ends up making it even more heavyweight. Automated key
management is a mechanism that does not need to be inside TCP-AO - we
were given that direction by the ADs from the start.

> dropped.

I cannot believe TCP-AO needs to handle misconfigured keys. This is
supposed to be a lightweight mechanism.

> In your system, the 5-6 transition is used to signal the

It's trivial to handle misconfigured keys in a similar fashion in the
mechanism I proposed - when you get keyID6, you switch to using keyID7;
if you don't get ACKs after some timeout, you revert back. Again, this
can be done without burying the mechanism inside TCP (you can do it by
sampling the keyIDs received).

> KMS, and that includes having unsynchronized key changes work correctly.

TCP-AO *supports* key management; it doesn't include it. Synchronizing
key changes is key management.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Jan 2009 07:52:51 -0800

At Thu, 29 Jan 2009 07:15:15 -0800,
> were given that direction by the ADs from the start.

I don't consider this to be automated key management, and I don't
think it's very productive to argue about the direction from the ADs
gave us. My understanding from the discussion in MSP was that there
was general WG consensus that the protocol ought to include some
mechanism for automatic switchover of manually configured keys
without real-time coordination. The minutes aren't as explicit
as one might like but sort of reflect this when they say: 

"***ACTION*** GL will write the text up explaining all of this"

That isn't to say you need to love Greg's mechanism, but if you
think the WG shouldn't do this sort of thing at all, I think we
need a more meta discussion, perhaps requiring more time 
in SFO.

> supposed to be a lightweight mechanism.

I agree it should be a lightweight mechanism, but as I took it your
argument is that we don't need an in protocol switchover mechanism
because it could be done with the external mechanism you propose.
My point is that your external mechanism is inferior in this 
respect, which motivates an internal mechanism.

This isn't the only downside, however. Your mechanism also entails
significantly more user intervention in the switchover process
to install these dummy keys. I don't consider that a feature.

> sampling the keyIDs received).

Well, you've now sort of reinvented the mechanism I originally
suggested and which is in Greg's message, but this is worse IMO because
substantial numbers of packets may be lost at one time before you can
switch over. Granted, this only happens with misconfiguration but it
makes misconfiguration quite bad. And the logic around failure also
becomes quite complicated. How long do I wait before I decide the
other side has screwed up? 

> key changes is key management.

This seems like a definitional argument. As I said at the beginning, 
it was my read of the discussion in MSP that the WG agreed there
should be such a mechanism. I think that having one would be a good
thing. If that's key management, then make the most of it.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Jan 2009 09:16:36 -0800

Hi, Eric (et al.),

To others - it might be useful to weigh in on this discussion...

> At Thu, 29 Jan 2009 07:15:15 -0800,
...
> "***ACTION*** GL will write the text up explaining all of this"

Greg was a proponent of it, and we were all interested in hearing what
he was thinking; I don't recall anything beyond interest in seeing the
details. Upon examining it in detail, it involves coupling directly with
TCP exchanges in a way I think is out of scope based on what I recall
the ADs saying - they can certainly remind us of what they're thinking
now...

> need a more meta discussion, perhaps requiring more time 

My view is that TCP-AO MUST support a mechanism for key coordination -
which I believe was consensus in the design team at least.

I prefer TCP-AO not to include that mechanism internally, to keep things
simple. That's just a preference, though.

I do think that mechanisms that couple tightly to a particular segment
exchange should be out of scope, however.

...
> suggested and which is in Greg's message,

Not really; the difference is that in my example side A can tell side B
it's ready to switch keys without ANY impact to side B; side B can
switchover when its ready. Further, my mechanism does not require tight
coupling with TCP segments being exchanged - it can be done through the
API, with zero impact to the TCP implementation.

> but this is worse IMO because
> switch over. 

Yes, packets are lost when you switchover and the key is wrong in my
mechanism. However, NO packets are lost when the key is right, vs.
Greg's mechanism which loses all probe packets until the other side is
ready. The impact of the lost probes depends on the variant used; if no
new TCP segments are generated, then the lost probes impact TCP's
congestion control. If new TCP segments are generated, the
implementation needs to be tightly coupled with TCP (which, again, I was
expecting we were trying to avoid).

> Granted, this only happens with misconfiguration but it

IMO, that's the benefit - it's up to the user, not the TCP-AO
implementation to decide that.

Joe

---

From: Brian Weis <[email-masked]>
Date: Thu, 29 Jan 2009 16:18:26 -0800

The message below summarizes the problem nicely.

> on the wire. Greg's mechanism is of course of type (2).

Probing implies "using a key optimistically", whereby the sender is  
taking a substantial risk that the peer does not yet have knowledge  
of that key. I don't particularly like either option above since they  
are both highly likely to result in significant change to the  
operation of the TCP session.

Joe mentioned a third approach. Summarizing the discussion, rather  
than "probe" with segments that the TCP stack would already send, his  
approach would add a signal to TCP segments noting that a new master  
key was available. This helps a peer implementation make the decision  
to move to a new key (i.e., the problem we're trying to solve)  
without actually using the new key. This can break the deadlock  
without the actual use of the new key.

I favor this approach, but not the mechanism. Joe's idea consumes one  
extra KeyID value for each real KeyID. The example given was to  
allocate both KeyID 5 and KeyID 6 when using KeyID 5. Signaling the  
presence of a new key comes by moving to KeyID 6. But overloading  
KeyIDs is not ideal -- in particular, recall that KeyID values are  
chosen by some external entity (e.g., a human or some automated key  
management system). I'm really not confident that a human will always  
appreciate that they can only configure "odd" KeyID values, for  
example. Furthermore, in order to guarantee interoperability I  
believe that this would have to be described in TCP-AO. We would want  
to avoid different implementations have different conventions, and  
not be able to set the same KeyIDs! This could be a fair amount of  
addition to TCP-AO.

A better approach is to steal a bit from the KeyID field, and give it  
the meaning "I have a new KeyID". This is an explicit marking with a  
clear meaning. There's no reason the KeyID has to consume 8 bits --  
KeyIDs should be associated with a single peer, and even 7 bits worth  
of simultaneous KeyIDs should be more than enough. A system  
configured with a new KeyID for that peer sets the "new KeyID bit"; a  
system which also has a new KeyID begins use of it when it sees that  
bit set. As far as I can tell, stealing this bit has a negligible  
effect on the current definition of TCP-AO.

Some further comments addressing other discussion in this thread:

- No external entity has to be present in this approach.

- It's true that the two systems could have made an error in stalling  
a new set of policy, and automatically switching to a new KeyID could  
result in peers that cannot communicate. It is a plausible situation  
when the values are manually configured. I'm personally willing to  
make that tradeoff for a simpler TCP stack. This error should rarely  
occur in the presence of a future automated key management method.

One more thought ... it seems to me that with probe-based approaches  
a man-in-the-middle can prevent the session ever moving to the new  
key. This would be done by dropping frames containing a new KeyID,  
forcing the TCP session continue with an old key. Continued use of  
the old key indefinitely may not be detected by operations staff. On  
the other hand, the presences of a "new KeyID bit" would requires a  
man-in-the-middle to disrupt the TCP session entirely, which is not a  
new attack on TCP, and also immediately visible to operations staff.

Brian

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Jan 2009 16:24:21 -0800

Brian Weis wrote:
...
> Joe mentioned a third approach. Summarizing the discussion, rather than
> "probe" with segments that the TCP stack would already send, his
> approach would add a signal to TCP segments noting that a new master key
> was available. This helps a peer implementation make the decision to
> move to a new key (i.e., the problem we're trying to solve) without
> actually using the new key. This can break the deadlock without the
> actual use of the new key.
> 
> extra KeyID value for each real KeyID. The example given was to allocate
> both KeyID 5 and KeyID 6 when using KeyID 5. Signaling the presence of a
> new key comes by moving to KeyID 6. But overloading KeyIDs is not ideal
> -- in particular, recall that KeyID values are chosen by some external
> entity (e.g., a human or some automated key management system). I'm
> really not confident that a human will always appreciate that they can
> only configure "odd" KeyID values, for example. Furthermore, in order to
> guarantee interoperability I believe that this would have to be
> described in TCP-AO. We would want to avoid different implementations
> have different conventions, and not be able to set the same KeyIDs! This
> could be a fair amount of addition to TCP-AO.
> 
> the meaning "I have a new KeyID". 

The problem with this sort of bit is that we would need to know when it
is set and when it is clearable; this requires coordinating state
between the endpoints.

The flag has meaning only in the context of a particular keyID, which is
why it is equivalent to using a new keyID value. Further, using keyIDs
allows the user/KMS/etc to have a variety of ways to pick new keys.
E.g., if there are one of two possible future keys:

	key A = keyID 9
	key A = keyID 10
	key A = keyID 11

	keyB = keyID 12
	keyB = keyID 13

Use keyID=9 for the 'old key' with no new changes pending. Use keyID=11
to signal use of key B, and use keyID=12 to signal use of keyID=13.
There are other things that keyIDs can be used to coordinate - and this
is exactly why it's not useful to carve bits out for specific meaning.
The meaning should be determined by the user/KMS.

Joe

---

From: Brian Weis <[email-masked]>
Date: Thu, 29 Jan 2009 17:35:31 -0800

Hi Joe,

On Jan 29, 2009, at 4:24 PM, Joe Touch wrote:

>> than
>> allocate

Each TCP peer sets the bit independently, at such time as a new KeyID  
is provided to the local system that matches policy for an existing  
TCP session. I.e., the manual key management logic or automated key  
management system.

The station clears the bit when it begins transmitting with a new  
KeyID. It begins transmitting with the new KeyID because it observes  
the peer using the new KeyID (as described earlier in this thread).

> The meaning should be determined by the user/KMS.

Recall that TCP-AO is meant for BGP and LDP. Neither one needs much  
more than an "old key" and "new key" per peer. Going to the extent  
you describe here is way overkill. I know you don't like defining  
bits in a header, but sometimes they solve a simple problem in a  
straightforward way.

If there's really an application that needs what you describe above,  
it will be complicated enough that it will need automated KMS, and  
that KMS can instruct TCP-AO exactly which key it wants to be used  
using a local mechanism.

Brian

> Joe
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmCSLUACgkQE5f5cImnZrs4QwCfdOq2iH4mXHVxlTmQETSBdLQD
> leEAn0GNipkeF66Et5lmaswnZ3+fQPTs
> =yjNn
> -----END PGP SIGNATURE-----

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Jan 2009 18:44:17 -0800

At Thu, 29 Jan 2009 09:16:36 -0800,
> the ADs saying - they can certainly remind us of what they're thinking

Well, as I said earlier, there are ways to do this that don't
couple to TCP. I.e., TCP-AO just chooses the occasional existing
packet to probe with. 

> switchover when its ready.

Yes, but you rely on correct receipt to confirm the switch.

> congestion control. 

Yeah, I'm having a really hard time getting worked up about the
impact of losing one packet every hour or so.

> implementation to decide that.

I don't consider that a benefit in terms of either interop or user confusion.

-Ekr

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Thu, 29 Jan 2009 21:28:47 -0600

I mostly agree with Joe, and have some brief comments below:

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Joe Touch
>Sent: Thursday, January 29, 2009 12:17 PM
>

The direction that we were always heading in was that TCPM will make
sure the spec for AO permits automated changes of keys and won't be
breaking other parts of TCP in the meantime.  We understood that
"permiting" or "supporting" the changeover in AO didn't mean actually
being responsible for doing it all inside the TCP connection, and that
the SECDIR would define a separate mechanism (not inside TCP) for this.
To be done timely and without bugs, AO has to stay as simple as the
needed security properties permit, so I have to agree with Joe.

>API, with zero impact to the TCP implementation.

This is a very important property given the level of complexity that
we already have in TCP implementations to be robust under all sorts
of circumstances and with various combinations of options in play.

>expecting we were trying to avoid).

I agree, this should definitely be avoided.  It's easy to specify wrong,
and even easier to implement wrong.