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

[Alfred Hönes <[e-mail]>]

Gregory, Joe, all,

I didn't see the original message regarding the New_Key process
for TCP-AO.  Hasn't it been copied to the tcpm list?

The text proposal at a high level seems to reflect the current
wisdom and state of the art of how 'rekeying' (sorry for the
simplifying term commonly used) should be performed in a reasonable
"make-before-break" manner.

Further, I appreciate your intent to get a new version out *before*
the 'rush weeks' before IETF draft cutoff, where drafts always are
in danger of not getting the attention and time they might deserve.
(Unfortunately, this happened with the previous versions of TCP-AO.)

I do not pretend to either be a "TCP guru" nor having "much experience"
with RFC 2385, but my working knowledge with TCP makes me raising my
voice regarding the DISCUSS items w.r.t. TCP use in your proposal.


(A)  Section X.2.3, {New_Key state} TSAD-OVERLAP

Firstly, the proposed timer value of 512 sec amounts to ~8.5 minutes,
"~9 minutes" is a bit too coarse.    :-)

However, from my point of view, two considerations apply:

a)  After an active close of a TCP connection, if the ACK
    for the FIN arrives, the TCP peer transitions its TCP
    to the TIME-WAIT state which regularly persists for 2*MSL
    (twice the maximum segment lifetime in the Internet)
    which the IETF has defined as  4 minutes.

    Since this scenario resembles the above -- it also aims
    at draining all TCP segments still 'on the road' at the
    activation of the new TSAD, it would IMHO make sense to
    adopt the same timeout value, 4 minutes.

b)  Since the TCP-AO processing rules take care of silently
    dropping packets not matching an active TSAD entry (for
    connections that have at least one TSAD entry, of course),
    it would be easy to expedite the aging of the old TSAD-X:
    The TCP peer entering TSAD-OVERLAP is aware of the current
    sequence and acknowledgment numbers at this instant.

    The remote peer is obliged to send all subsequent segments
    under the protection of TSAD-Y as well.  Therefore, as soon
    as the connection makes progress, i.e.:
    -  all outbound segments with sequence numbers
       less than the local 'switchover point' to TSAD-X have been
       transmitted (drained from the local retransmission queue)
       and acknowledged by the remote peer  AND
    -  all inbound segments with sequence numbers less than the
       peer's switchover point have been received and cumulatively
       acknowledged,
    it is save to cancel the TSAD-OVERLAP timer, deactivate TSAD-X,
    and transition to SINGLE-TSAD state.
    Unnecessary retransmissions and packets duplicated in the
    network that are protected by TSAD-X aandstill around at this
    moment will simply be silently discarded at arrival.

    This way, resources (including stale keying material) could be
    cleaned up more quickly.  This might be of particular importance
    if crypto accelerating hardware with restricted resources is used.


(B)  Section X.3, Probe Mechanism

It seems dangerous to introduce new, 'unusual' packets for this
signaling mechanism; intermediate systems and firewalls might
not let them through, and the proposal seems to need a detailed
security analysis.  At first glance, it also seems to violate
rules being recommended for more closer packet inspection in
order to counter various kinds of attack vectors against TCP.

TCP has a 'keep alive' mechanism based on ACK exchanges, and
virtually all TCP implementations support this mechanism.

It would therefore make very much sense to re-use that mechanism
for the Probes: no 'strange looking' segments, known security
considerations for the segments, better re-use of existing code!

Therefore, regarding Question 1, I essentially suggest:  1024 --> 0  !

Regarding Question 2:  I assume the Probe TCP segments will come
with a TCP header and an IP header as well.  :-)
Therefore, the question is moot!
(Every TCP regularly sends myriads of data-less ACKs w/o padding,
and (data) padding never happens at the TCP layer.)


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+

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