Re: [tcpm] tcpsecure recommendations

> 
> The key issues are:
> 
> - - lack of protection against injected data itself (I'm not 
> sure if the doc actually calls this out specifically; it 
> probably should in the security considerations section - even 
> an off-path attacker can do this,
> e.g.)

There are references to IPsec and MD5 etc., in the security section. I
think all the above is implied and understood. Like it has been
emphasised before many times, the purpose of TCP secure is to add
robustness to some cases and not to replace IPsec/MD5.

> 
> - - the word "eventually" above
> 
> IMO, if you are running a TCP connection that is susceptible 
> to attacks only by a *stream* of forged segments, you 
> probably ought to use something besides TCP-secure as protection.

Actaully it is not a "stream" of forged segments. A malicious segment
(which utilizes the liberal range of ACK value) can come and occupy any
place within the receive window, it could be in the re-assembly queue/or
somewhere inline, but this just like a "time-bomb' waiting to explode.
[The document mentions these possibilities under the data injection
section] Also as mentioned in the document FIN attacks are also possible
which is a control plane thingy ( using your terminology)

> 
> As a result, I think that you SHOULD protect the control 
> plane (if you employ this technique), but that protection of 
> attacks via data plane volume are not as critical, and thus a MAY.

Data injection is about strict ACK checking and applies to FIN segments.
To re-iterate: preventing anything which causes the connection tear down
maliciously is critical. So it could be a RST/SYN or Data or FIN.

But if your point is the mitigation should not be called as "data
injection" and something else, I agree. OTOH, the assumption is that any
implementer (true for any RFC) is going to read and understand that
tcp-secure provides adds robustness in some cases and for a
comprehensive data/control protection one is going to use MD5/Ipsec.
Like I pointed out earlier many times tcp-secure is not an
authentication mechanism and lot of folks agree to that, but you seem to
thinking this as an authentication mechanism and with that line of
thinking, your reasoning is fine, but the basic point is tcp-secure is
NOT a authentication mechanism, it is about protocol robustness :-) 

-Anantha
_______________________________________________
tcpm mailing list
tcpm@ietf.org
http://www.ietf.org/mailman/listinfo/tcpm