headers
Black_David | 5 Jul 2004 20:50

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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Black_David | 5 Jul 2004 20:55

MPA as MUST over TCP

This one I can do something about now ...

The WG chair believes that the rough consensus of the RDDP
WG is that MPA MUST be used to employ RDDP over TCP.

Please post any objections to the list.  This could
create a need for some interesting (but not impossible)
wordsmithery if MPA does not get upgraded to standards
track from its current direction of becoming an
informational RFC (e.g., won't be able to state that
requirement in the DDP or RDMAP documents).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: rddp-bounces <at> ietf.org [mailto:rddp-bounces <at> ietf.org] On 
> Behalf Of Michael Krause
> Sent: Wednesday, June 23, 2004 1:35 PM
> To: rddp <at> ietf.org
> Subject: [rddp] MPA 
> 
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Black_David | 5 Jul 2004 21:29

RE: Why IPsec is needed for iSCSI but might not beneededfo r RDDP/iWARP

Aside from cautioning about the use of the word "consensus"
("rough consensus" should only be called by the WG Chair
for legal and procedural reasons), this was a very helpful
email message in summarizing the current state of things
and proposing what to do next

Specifically, I would strongly encourage work on:

	I believe the open issue is whether we can specify a
	set of local interface requirements which:

	a) will satisfy the IESG that they are sufficiently
		complete and there natural usage simple enough
		that use of RDMA over unsecured transports will
		create no new security vulnerabilities.

	b) are simple enough that they do not require a redesign
		of in-progress hardware.

The result would need to be phrased in terms of requirements/
restrictions on the functional interface and behavior presented
to ULPs.  This has been done before, as the IPsec security
"databases" (SPD and SAD in RFC 2401) are examples.  I would
hope the result can be posted to the list, as the deadline for
new drafts is coming up quickly.  While the verbs draft could
be useful as an example to work on, the eventual requirements
will need to go into the DDP, RDMAP, and/or security drafts.

I think this work is a good idea *even if* we ultimately decide
that IPsec is mandatory-to-implement.  This is because (IIRC,
(Continue reading)

Permalink | Reply | 11 comments |
headers
Minti Patel | 7 Jul 2004 21:45

iSER Specification login/text operational keys


Hello all,

Sections 8.1 and 8.6 of the iSER specification state that if 
RDMAExtensions is negotiated to Yes on the leading connection of a 
session, then HeaderDigest,DataDigests, OFMarker and IFMarker, if they are 
negotiated, must be negotiated to None/No.

In Section 5.3, points 2 and 8 say that the keys HeaderDigest,DataDigests, 
OFMarker and IFMarker MUST be negotiated to None/No.

Does this mean that these keys must be offered for negotiation when 
RDMAExtensions=Yes, even if they simply select the value None? (Since 
these keys are off by default, negotiation is not required to arrive at 
the result None/No. )

Does similar reasoning apply to InitiatorRecvDataSegmentLength and 
TargetRecvDataSegmentLength?

Any help is appreciated.
Thanks,

Minti Patel
InterOperability Lab
University of New Hampshire
Permalink | Reply | 1 comment |
headers
Mike Ko | 8 Jul 2004 00:01
Picon
Favicon

Re: iSER Specification login/text operational keys

The intent is to not use HeaderDigest, DataDigest, OFMarker, and IFMarker 
when RDMAExtensions is negotiated to yes.  Should the iSCSI spec be 
changed for any reason such that the defaults for these 4 keys are not off 
by default, then these 4 keys must be negotiated to None/No for an iSER 
connection.  Otherwise no explicit negotiation for these 4 keys are 
intended if the default is None/No.

For InitiatorRecvDataSegmentLength and TargetRecvDataSegmentLength, if 
both the initiator and the target are willing to accept the default value, 
then no explicit negotiation is required for an iSER connection.

Hope this helps.

Mike
Sent by:        rddp-bounces <at> ietf.org
To:     rddp <at> ietf.org
cc:      
Subject:        [rddp] iSER Specification login/text operational keys

Hello all,

Sections 8.1 and 8.6 of the iSER specification state that if
RDMAExtensions is negotiated to Yes on the leading connection of a
session, then HeaderDigest,DataDigests, OFMarker and IFMarker, if they are
negotiated, must be negotiated to None/No.

In Section 5.3, points 2 and 8 say that the keys HeaderDigest,DataDigests,
OFMarker and IFMarker MUST be negotiated to None/No.

Does this mean that these keys must be offered for negotiation when
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Pinkerton | 8 Jul 2004 02:45
Picon
Favicon

Reminder - RAIT Workshop - September 20, 2004

A gentle reminder to those that may be considering submitting a paper to the IEEE Cluster 2004 RAIT Workshop (RDMA Applications, Implementations, and Technologies) – the current date for submitting papers will be extended from July 9th to a new date of July 16th, due to vacations, etc.

 

For those that were not aware, there is a one day RDMA Workshop at this Fall’s IEEE Cluster 2004 Conference, on September 20th, 2004. The workshop day will focus on reviewing the various juried papers submitted and discussions on advanced RDMA topics. All are welcome to attend. The official Workshop web page is http://grail.sdsc.edu/cluster2004/RDMA2004Workshop.htm.

 

The umbrella conference is the IEEE Cluster 2004, and its web site is http://grail.sdsc.edu/cluster2004/.

 

Here’s an excerpt from the web page:

 

Call for papers

 

Remote Direct Memory Access (RDMA) enables transfer of data across a network directly to and from application buffers without requiring any intermediate copies or buffers. RDMA, along with direct access to the networking hardware, also provides a low overhead mechanism for achieving low latency, high-bandwidth communication. RDMA has become a desirable feature in high-speed clusters and data-center networks.

 

Scope

The RAIT 2004 workshop is the first event dedicated to RDMA. RAIT 2004 will serve as a forum to present the latest research work by the researchers and developers from both the academia and industry. The focus of this workshop will be on the applications of RDMA, the implementation aspects of RDMA, and the RDMA technologies based on the standards (RDMA over TCP/IP, InfiniBand, Virtual Interface Architecture, etc.). Topics of interest include, but are not limited to:

·        RDMA hardware (RDMA-enabled NICs, InfiniBand adapters, or VI NICs)

·        RDMA-aware networks and interfaces

·        Middleware and network services for RDMA-based networking

·        Applications of RDMA (iSCSI/iSER, NFS, DAFS, SDP, databases, clustering, etc.)

·        RDMA Protocols

·        Operating system infrastructure for RDMA

·        RDMA performance evaluation (application performance, performance metrics, network performance, etc.)

·        RDMA and security

·        Future directions for RDMA     

 

 

 

Co-Chairs:

Jim Pinkerton                                        Hemal Shah

Microsoft                                               Intel

 

 

 

_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
Permalink | Reply | 0 comments |
headers
Talpey, Thomas | 8 Jul 2004 13:17
Picon

Re: Some RDDP attacks

At 02:50 PM 7/5/2004, Black_David <at> emc.com wrote:
>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.

Silent drop would be a disastrous choice for DDP errors, especially
bad MSN or invalid STag! This would be like TCP ack'ing a hole in
sequence space or bad checksum. It would give the upper layers
on both sides of the connection an indication that messages had
been received when they had not.

Consider an RDMA Write with bad STag that was dropped at the
receiver. The subsequent Send, signalling the receipt, would then
pass upwards. Oops. Or consider a sender exceeding its credits
and losing a string messages in the middle, but not the end, of a
sequence.

Because it's an ack-less protocol, the only valid response DDP can
make is to send a Terminate and close the connection. Which it must.

Tom. 

_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
Permalink | Reply | 0 comments |
headers
Caitlin Bestler | 8 Jul 2004 15:20

Re: Some RDDP attacks


On Jul 5, 2004, at 1:50 PM, Black_David <at> emc.com wrote:

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

If you can forge a TCP packet within the TCP window you can force the
connection to close. No RDDP Layer capabilities are required. This is
also true for SCTP, although forging a valid packet is slightly harder.
Permalink | Reply | 0 comments |
headers
Jim Pinkerton | 8 Jul 2004 15:34
Picon
Favicon

RE: Some RDDP attacks

 
Abstracting it up a level, the current DDP/RDMAP IDs require a reliable transport protocol underneath them. For example, the DDP ID is titled "DDP over Reliable Transports". Silent drop is effectively corrupting the reliable transport.
 
Back when we were originally creating the DDP/RDMAP drafts, we spent a lot of time trying to decide on whether the protocol was generic enough to run over reliable and unreliable transports. When we dove in to it, there were significant issues that were unique to the approach of running over an unreliable transport (what is the programming model, how are completions handled when things are lost, resolving holes in sequence space, etc). The group was primarily interested in nailing reliable transports, since that has been the traditional RDMA programming model. Thus the draft title got "... over Reliable Transports" added to it to explicitly state the original author's focus.
 
I believe since the IDs were adopted by RDDP, that there has been wide support for a focus on reliable transports as the first protocol suite to come out of RDDP. Unreliable can come later.
 
 
 
jim
 
 

From: rddp-bounces <at> ietf.org on behalf of Talpey, Thomas
Sent: Thu 7/8/2004 4:17 AM
To: rddp <at> ietf.org
Subject: Re: [rddp] Some RDDP attacks

At 02:50 PM 7/5/2004, Black_David <at> emc.com wrote:
>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.

Silent drop would be a disastrous choice for DDP errors, especially
bad MSN or invalid STag! This would be like TCP ack'ing a hole in
sequence space or bad checksum. It would give the upper layers
on both sides of the connection an indication that messages had
been received when they had not.

Consider an RDMA Write with bad STag that was dropped at the
receiver. The subsequent Send, signalling the receipt, would then
pass upwards. Oops. Or consider a sender exceeding its credits
and losing a string messages in the middle, but not the end, of a
sequence.

Because it's an ack-less protocol, the only valid response DDP can
make is to send a Terminate and close the connection. Which it must.

Tom. 

_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
Permalink | Reply | 0 comments |
headers
Jim Pinkerton | 8 Jul 2004 15:47
Picon
Favicon

RE: Some RDDP attacks

 
I agree with Caitlin - once you've figured out the right values in TCP (i.e. "forge a packet"), TCP allows you to reset the connection without ever dealing with DDP/RDMAP - just send a RST segment. Thus I don't see how solving this in DDP/RDMAP changes the exposure.
 
As is noted in the following ID, this is viewed as non-trivial, but possible.
 
http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpattack-00.txt, section 2.1.6 "Reset a single BGP Session".
 
 
 
jim
 
 

From: Caitlin Bestler [mailto:cait <at> asomi.com]
Sent: Thu 7/8/2004 6:20 AM
To: RDDP
Cc: David Black; Jim Pinkerton
Subject: Re: [rddp] Some RDDP attacks


On Jul 5, 2004, at 1:50 PM, Black_David <at> emc.com wrote:

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

If you can forge a TCP packet within the TCP window you can force the
connection to close. No RDDP Layer capabilities are required. This is
also true for SCTP, although forging a valid packet is slightly harder.


_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
Permalink | Reply | 0 comments |

Gmane