Re: [tcpm] tcpsecure: how strong to recommend?

[Joe Touch <[e-mail]>]

Ted Faber wrote:
> On Fri, Oct 05, 2007 at 10:21:38AM -0700, [e-mail] wrote:
>>> IMHO, we're already addressing unlikely events - MSL violation or
>>> off-path spoofed RST with known addresses and ports.  I think that the
>>> cost of one packet exchange to validate that the connection is not about
>>> to be terminated by an unlikely event is a reasonable engineering
>>> choice. 
>> TCP was designed to be able to unilaterally terminate a connection with a RST.
>> If you wanted a handshake, why did you not use FIN?
> 
> That's an instructive example.
> 
> If your RST is lost - they're not sent reliably as a FIN is - the packet
> exchange is exactly the one TCPsecure proposes: ACK the last packet.
> (Strictly speaking the lost RST doesn't do it of course - that would be
> a nice trick.  Either new data goes out (ACKing the last packet as
> well), or a retransmission occurs, or a window probe goes off.)
>
> Receiving the ACK triggers a retransmission of the RST and state
> synchronizes.  If all the RSTs are lost, the state still synchronizes
> with a timeout.  I wouldn't call that an authentication (and I know you
> didn't), but the process is very similar to how TCPsecure plays out.

It's not the same, as you point out. If there's no further data to be
sent, then it doesn't necessarily behave like a FIN exchange.

If you want a coordinated endpoint exchange, I suggest using a FIN.

> If we were in a drinking establishment or academic symposium where the
> navel gazing were appropriate, we could discuss whether that RST packet
> "unilaterally terminates the connection" or is a hint that the
> connection has been unilaterally terminated by the destruction of the
> connection state at one endpoint. 

I doubt we would debate that long; I agree with you, I suspect, that the
latter is more precise. It's a hint.

Again, a reason why you either take the hint or not. You don't respond
to it, and you don't gain anything - except over-optimization - by
telling the other end anything to confirm that hint.

> I'm sure you can tell what I
> believe, and I'm suggesting that thinking of both these processes as
> confirming a hint might be less objectionable to you than thinking of
> them as authenticating a message. 

Confirming that it's a hint? Confirming what? That the hint came from
who you thought. Again we're back to authentication.

> But here on the list, I'm hoping that talking about what a "slightly
> unusual" packet is might steer us back toward the
> MAY/SHOULD/MUST/applicability statement discussion.

It walks, looks, and quacks like a duck. Whether you will agree to call
it a duck or not, I won't worry. But I've treated it like a duck in
deciding MUST/MAY/SHOULD.

If we truly want to get back to that discussion, I haven't heard others
address the proposed way forward I offered...

Joe

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