Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt

> This first sequence number information can be used to form part of the
> challenge-response; if the sender has sent an RST packet whose
> sequence number lies in the window, but it is not the next expected
> packet, the ack sent back by the receiver can be an indicator for the
> RST sender to pass the first sequence number in a subsequent packet
> (also containing a confirming RST flag. 'I told you to close. I'm
> telling you to close again. And here's a reminder of when we first
> spoke and agreed to open. It's a random number we both know.'.)

If I'm sending you a RST because I rebooted and lost all state and
don't have any state for the TCP connection that you apparently have
becasue you are sending me packets, how am I supposed to remember what
the initial sequence number was?

Here's an idea (just thinkint out loud here) for solving the BGP problem:

Ignore RSTs and just let keep alive failures and timers take care of
tearing down old connections.

(and continuing to think out loud here....)

Joe Touch recently suggested that IPsec/ESP with Null encryption and
authentication would effectively put in place a cookie mechanism (the
SPI being the cookie) which would be sufficient to solve these
probelms.  But that just pushes the problem of handling a TCP RST to
figuring out how to "RST" a IPsec SA.  And my understanding of that
problem (which is based on recent discussion in HIP WG) is that when a
packet shows up with an unknown SPI, that you might have a mechanism
that sends back an advisory "unknown SPI" notification, but that when
you receive an "unknown SPI" notification, there's not much you can do
with it because it could be someone spoofing you.

So it seems just hacking your TCP implementation to ignore RSTs
might give you the same robustness that you'd get from
null-encryption, null-authentication IPsec ESP.

			-Tim Shepard
			 shep@alum.mit.edu

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm