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

[[e-mail]]

Quoting Ted Faber <[e-mail]>:

> > Asking to 'synchronize with the other end' is authentication, especially
> > when the only purpose behind it is to determine whether a spoofed packet
> > is generated.
> 
> "Did you say that?" is a fundamentally different question that "Who said
> that" in my mind.  Asking the first in this context is both more useful
> and more practical to determine.
> 
> If you want to think of them both as authentication, I'm not going to
> try any more to convince you not to.

The only difference between "did you say that" and "who said that" is who is
providing the authentication. The latter can be authenticated by a third party,
where the first is done exclusively by the other end of the connection. I hope
that at least helps explain why I see these as equivalent, even if not everyone
agrees with it.

> > It's insincere to rationalize events like erroneously generated or
> > delayed RSTs into this discussion. Both kinds of RSTs are just as valid
> > as correctly generated, timely ones, as far as the TCP spec is
> > concerned, unless you're concerned they're beings spoofed.
> 
> I'm perfectly sincere about it.  I think pointing out that the technique
> mitigates several possibilities emphasizes its value from an engineering
> perspective.
> 
> I can't argue with your perfectly correct statement that a compliant TCP
> will treat the spoofed, out of date, erroneously generated, or damaged
> packets as correct and reset the connection.  The argument is whether
> that behavior is useful or not.  
> 
> I think it's not, but YMMV.

I think I've shown above that the utility of the behavior is exclusively
motivated by authentication, and that other justifications don't have valid
support.

You can still think it's useful. I don't think it's not useful, so much as not
necessary if you're really concerned about security, and potentially dangerous
(unncesssarily complicated and IPR-burdened) if you aren't.

> > >> What does that tell you about the other end that you didn't know? What
> > >> purpose relevant to resetting a connection does synchronizing state
> > >> serve if not to authenticate the other end?
> > > 
> > > If the RST that triggered the ACK was from another connection, the
> > > TCPsecure exchange tells you that the other end of this connection has
> > > not reset.  
> > 
> > That presumes that either the RST is floating in the network more than 2
> > MSLs or that your end decided to accept a connection it shouldn't have
> > since it didn't correctly wait 2 MSLs from a previous connection.
> 
> Again, technically correct.  I think that addressing the eventuality that
> (among other things) MSL is incorrectly estimated or configured with an
> extra packet exchange is good engineering.
> 
> Yes, I know that an "engineering decision" is often difficult to tell
> from an "egregious hack."  I think that this design is the former.

Good engineering to update TCP to handle incorrect MSL estimation would be a
substantial piece of work. It would require reevaluating everything from SYN
exchanges to window offset validation. At the end of the day, if you don't
trust the MSL estimation, you need anti-replay. Yet another good reason to use
something like IPsec if this is what you're true concerns are, rather than a
patchwork of solutions that approximate anti-replay in specific cases.

> > If we're going to patch TCP to fix >2MSL errors, there's a lot more work
> > than this to be done. If your end is broken, then expecting this patch
> > to correct the situation is not productive.
> 
> Again, engineering vs. protocol design.
> 
> 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?

..
> > > No new information about the identity of that endpoint has
> > > been asserted, simply that the end that got your ACK has state closely
> > > enough synchronized with yours to make a sensical reply.  The identity
> > > of the sender of the RST remains unknown (though if the other end *has*
> > > reset, the sender is likely the other end).
> > 
> > The identity of the other end is defined by the synchronization process
> > - it's a TCP endpoint with which your ACKs synchronize state.
> > 
> > > I don't know anything new about the identity of anyone in the
> > > communication; I just don't see authentication there.
> > 
> > You know it's the other end with which you can synchronize state. That's
> > identity.
> 
> I think we're arguing over what to name the process.  This would be fun
> to do in person, but I don't think it's advancing the discussion of the
> system, or in particular of the discussion about the guidance to
> implementers we're trying to decide on.

I agree with that, but we've tripped over some other name issues that are
fundamental here:


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