Some RDDP attacks

In looking over email to the list, I noticed some comments from
Jim Pinkerton about attacks on RDDP.  I've pulled selected excerpts
from a couple of Jim's messages to deal with these specific issues -
the more general issue of where we are on security and what needs to
be done will be covered in a separate message.  So, quoting from
Jim's messages:

> The RDMAP/DDP protocol allows a multi-gigabyte data transfer to occur
> as one RDMAP/DDP Message. If we're going over a dial-up line at roughly
> 8 KB/sec, this means that the "one-shot" approach allows an attack on
> the STag to occur for roughly 69 hours (2 gig transfer). Thus I don't
> see how one-shot significantly decreases the threat profile.

Even though that's an unrealistic scenario, it still misses the point.
After that 69 hour transfer, if some form of "one-shot" causes the STag
to be invalidated by RDMAP/DDP, then the receiving protocol logic cannot
be attacked by overwriting placing data while the protocol is processing
the placed data (because the STag will necessarily have been invalidated).
In the absence of "one-shot" a "forgot to invalidate" bug/oversight in
the receiver opens the receiver to this attack.

> 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 think that's actually indicative of a DDP problem, in that the current
DDP draft is too quick to close a connection when receiving anything it
doesn't expect.  Mandating "silent drop" rather than "tear down the
connection" would make this attack significantly harder to pull off.

> 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.

This was about whether unpredictable STag values add any security
above the TCP ISN or SCTP Verification Tag.  I suspect they do, as
STag values are likely to have significantly shorter lifetimes than
transport (TCP or SCTP) connections/associations, and hence making
them unpredictable increases the difficulty of an active insertion
attack.  It doesn't make such attacks impossible, just more difficult.

FWIW, the architecture draft is hung up on this issue at the moment,
in essence the concern is that for predictable STag values, learning
one allows an attacker to figure out others.  This could make a
difference in a situation where STag values are hard for an attacker
to learn (e.g., attacker can't see sink to source communication of
STag values and each STag is used once only - I suspect it can be
argued that this situation is unlikely because at a common MTU like
~1500 bytes, using an STag for one packet will not be efficient/
effective).  I have not pursued this issue with the ADs/IESG yet,
as I need to know where the WG is going to settle on level of
requirement (MUST/SHOULD/MAY) for IPsec before doing so.

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
----------------------------------------------------