RE: IPsec and RDDP as a transport

I'd be cautious about using the SCTP Verification Tag issue as an
example for RDDP STag selection. From RFC 2960:

   "Packets
   received without the expected Verification Tag value are discarded,
   as a protection against blind masquerade attacks and against stale
   SCTP packets from a previous association." 

Thus the initial Verification Tag value must be randomly selected to
prevent a blind attacker from guessing the right value (and also for
enabling rejection of delayed duplicates). As I'm sure you know, this is
similar to TCP, but a better design because TCP combines the the
verification tag concept with the sequence number (ISN). For RDDP, the
blind attacker must first guess the TCP ISN or SCTP Verification Tag
selection criteria (and several other fields in those headers). Then it
can attack the STag. 

So I view the validity of STag value selection as *not* being equivalent
to the criteria used for SCTP Verification Tag. If we wanted to
officially say that SCTP Verification Tag is insufficient for RDDP (I
don't!), then we would presumably be obligated to do an analysis of how
to make it even more difficult to get a packet to be accepted by a blind
masquerader.  

If we took a moment to look at the packet header for DDP for how a
malicious user that has successfully guessed the SCTP/TCP transport
parameters can effect the connection, there is actually a far simpler
attack than guessing the 32 bit STag value - and the attack abortively
terminates the connection and thus truncates the data stream. Use
untagged messages with just about any MSN, and the receiver will get a
"no buffers available" error and tear down the connection. Thus claiming
the STag is a risk actually ignores a much easier attack.

I'm a strong proponent of layering, and this specific issue is supposed
to be sufficiently dealt with by SCTP (a brand new protocol that has
specifically designed in mitigations for this attack). And I believe it
does sufficiently solve the issue. 

Note that a completely separate (and unrelated) issue is non-blind
masquerade attacks (the attacker can see the packets) where really the
only defense is IPSec or equivalent.


Jim

 

 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
Of
> [email protected]
> Sent: Wednesday, May 26, 2004 8:52 PM
> To: [email protected]
> Subject: [rddp] IPsec and RDDP as a transport
> 
> I think the discussion with Caitlin has reached the point
> where a summary and opening up the discussion to others is
> in order.
> 
> In essence, Caitlin strongly suggests that RDDP's security
> requirements should be derived by considering it as a transport
> protocol optimization and looking to what is required of other
> transport protocols.  SCTP (RFC 2960) is an obvious place to
> look.
> 
> I think that this is viable (although I'm probably in for a
> lengthy discussion with the security ADs - part of my job
> as a WG chair), but there are three important consequences
> that I'd like to see comments on:
> 
> (1) The "no IPsec" (or equivalent mechanism) level of requirement
> 	would apply only to implementations that restrict all STags
> 	to be one-shot (single use in some sense).
> 
> (2) Implementations that allow longer-lived STags would in all
> 	likelihood be subject to a stronger security requirement
> 	due to the increased application exposure created by
> 	long-lived STags.
> 
> (3) STag values will probably have a randomness requirement to
> 	make them hard to guess.  See the discussion of the SCTP
> 	Initiate Tag and its randomness requirements in RFC 2960
> 	(e.g., Section 5.3.1).
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email protected]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp