Subject: [rddp] Some RDDP attacks
From: [email-masked]
To: [email-masked], [email-masked]
Date: Mon, 5 Jul 2004 14:50:15 -0400
List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>

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
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked], [email-masked]
Subject: [rddp] MPA as MUST over TCP
From: [email-masked]
Date: Mon, 5 Jul 2004 14:55:49 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

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 
> 
> 
> 
> I've been looking through the various e-mail strings to understand if 
> consensus on MPA negotiation has been reached or not.  There was some 
> discussion on at least one proposal but I don't see a 
> resolution.  I would 
> hope that MPA was viewed as a MUST requirement for RDMA over 
> TCP so that an 
> equivalent level of CRC protection and framing as provided by SCTP is 
> available for ULP to count on when they are designed.
> 
> Thanks,
> 
> Mike
> 
> 
> _______________________________________________
> rddp mailing list
> rddp at ietf.org
> https://www1.ietf.org/mailman/listinfo/rddp
> 

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked], [email-masked]
Subject: RE: [rddp] Why IPsec is needed for iSCSI but might not beneededfo r RDDP/iWARP
From: [email-masked]
Date: Mon, 5 Jul 2004 15:29:06 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

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,
as Dwight pointed out) IPsec can't stop a malicious client
who is able authenticate, and RDDP is potentially applicable to
protocols that need to allow sufficiently large populations
of clients to authenticate (e.g., NFSv4, HTTP) that authentication
material can be expected to be obtainable by a motivated attacker.

To see a worked example of this in a different context, Google
for "exploder control" and notice that this control was
cryptographically signed ...

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: Caitlin Bestler [mailto:cait at asomi.com] 
> Sent: Monday, June 28, 2004 11:49 AM
> To: RDDP
> Cc: David Black; Jim Pinkerton
> Subject: Re: [rddp] Why IPsec is needed for iSCSI but might 
> not beneededfo r RDDP/iWARP
> 
> 
> 
> On Jun 28, 2004, at 10:14 AM, Black_David at emc.com wrote:
> 
> > Jim (and Mike),
> >
> > My current belief is that this will need discussion in San
> > Diego - I'm uncomfortable trying to call rough consensus on
> > IPsec requirements on the mailing list based on the traffic
> > I've seen, BUT ...
> >
> > ... the security draft needs to be updated because it's current
> > approach to IPsec is not good.  Let's put the IPsec text into
> > the next version of that draft and then discuss what we want
> > to do and why in San Diego.
> >
> > The problem with the current security draft text is that it
> > (re)profiles IPsec - that should not be necessary at this point,
> > instead the draft should do one of the following two things:
> > 	- Reference appropriate sections of RFC 3723 (IP Storage
> > 		security) to reuse that IPsec profile.
> > 	- Reference IKEv2 and associated drafts to use the new
> > 		work done there.
> > The former approach exactly matches the existing text and
> > doesn't pull in an IKEv2 requirement, so that's probably
> > preferable.
> >
> > Thanks,
> > --David
> >
> 
> I think that it is clear that there are at least some
> RDMA applications that would benefit from having transport
> layer anti-spoofing as an alternative to having to authenticate
> the payload themselves after invalidating the STag.
> 
> So clearly defining how IPsec would work with RDMA is clearly
> beneficial, whether IPsec ends up being a MUST implement or not.
> 
> I also believe that there is consensus on the following points:
> 
> 1) Mandating IPsec implementation is preferable to making any
>     changes to RDDP or RDMAP headers.
> 
> 2) Mandating IPsec implementation is preferable to restricting
>     the application model, for example by standardizing the
>     usage of tagged buffers in relation to untagged buffers.
> 
> 3) The nature of the RDDP specific vulnerability is in the
>     local interface. Specifically, the common practice for
>     RDMA ULPs is to "deliver" a tagged buffer implicitly
>     by completing an untagged message. That is the receiver
>     of the untagged message understands that a set of previously
>     advertised tagged buffers has been delivered, but just as
>     the method of advertising is not known to RDDP, neither is
>     the method of delivering content through tagged buffers.
> 
>     Local interfaces can actually encourage the application
>     designer to use one of these "delivered" tagged buffers
>     *before* ending the exposure of the buffer to tagged writes.
>     In the absence of transport layer authentication, the ULP
>     can only authenticate received tagged buffers *after*
>     the exposure has been eliminated.
> 
> 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. There are simple methods to add IPsec
>     functionality *below* the existing iWarp layers, although
>     they add variable cost in doing so. But something that can
>     be added on may be preferable to a theoretically simpler
>     solution that requires rework, especially this far into
>     the development process.
> 
> I would be interested in hearing if everyone agrees with the
> above, and further if they believe the solutions already
> described for the local interface are sufficiently simple
> in at least the case of a simple receive queue.
> 
> If there is consensus that the proposed local interface enhancements
> are adequate at least for simple receive queues, we would then have
> to proceed with a discussion on how to apply these techniques to
> shared receive queues, and exactly what standards apply to shared
> receive queues.  I believe the same approach will work for SRQs,
> but it is definitely more challenging than for simple endpoints.
> But there is no point in doing that work if the WG does not believe
> in either assumption A or B above.
> 
> 
> 

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: RDDP <[email-masked]>
Subject: Re: [rddp] Some RDDP attacks
From: Caitlin Bestler <[email-masked]>
Date: Thu, 8 Jul 2004 08:20:57 -0500
Cc: David Black <Black_David at emc.com>, Jim Pinkerton <jpink at windows.microsoft.com>
In-reply-to: <[email-masked]>
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
References: <[email-masked]>
Sender: [email-masked]

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

To: "Talpey, Thomas" <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] Some RDDP attacks
From: "Jim Pinkerton" <[email-masked]>
Date: Thu, 8 Jul 2004 06:34:32 -0700
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcRk3URw1CFLUetKRhuMyLOKKSbYxAAET7GM
Thread-topic: [rddp] Some RDDP attacks

Title: Re: [rddp] 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: [email-masked] on behalf of Talpey, Thomas
Sent: Thu 7/8/2004 4:17 AM
To: [email-masked]
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

To: "Caitlin Bestler" <[email-masked]>, "RDDP" <[email-masked]>
Subject: RE: [rddp] Some RDDP attacks
From: "Jim Pinkerton" <[email-masked]>
Date: Thu, 8 Jul 2004 06:47:21 -0700
Cc: David Black <Black_David at emc.com>
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcRk7mbNizKfomR4R5qS9RAQcY1uBQAAfNP/
Thread-topic: [rddp] Some RDDP attacks

Title: Re: [rddp] 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:[email-masked]]
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

To: "Jim Pinkerton" <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] Some RDDP attacks
From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 8 Jul 2004 06:56:34 -0700
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcRk83JAw9dHwaudSwGfs/QreyO8OA==
Thread-topic: [rddp] Some RDDP attacks

Title: RE: [rddp] Some RDDP attacks

DDP depends on ordering as well as reliability. So UDP (the
ultimate silent drop :) would be a double challenge.

Not that I want to go there. The "traditional" model is the
only one we need, IMO. What data-intensive protocols run
by default over unreliable, unordered transport?

Tom.

At 09:34 AM 7/8/2004, Jim Pinkerton wrote:
>
>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

To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] Some RDDP attacks
From: [email-masked]
Date: Fri, 9 Jul 2004 17:27:36 -0600
Cc: Black_David at emc.com
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcRk7mbNizKfomR4R5qS9RAQcY1uBQAAfNP/AEbXd3A=
Thread-topic: [rddp] Some RDDP attacks

Title: Re: [rddp] Some RDDP attacks
I agree with this and also about the dangers of silent drop. Silent drop would allow silent data corroruption. The RDMAP protocol relies on stream completeness and its ordering rules to ensure behavior to the upper layers.
 
Pat

    -----Original Message-----
    From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org]On Behalf Of Jim Pinkerton
    Sent: Thursday, July 08, 2004 6:47 AM
    To: Caitlin Bestler; RDDP
    Cc: David Black
    Subject: RE: [rddp] 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

To: [email-masked]
Subject: [rddp] I-D ACTION:draft-ietf-rddp-problem-statement-04.txt
From: [email-masked]
Date: Tue, 13 Jul 2004 16:05:59 -0400
Cc: rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote Direct Data Placement Working Group of the IETF.

	Title		: Remote Direct Memory Access (RDMA) over IP Problem Statement
	Author(s)	: A. Romanow, et al.
	Filename	: draft-ietf-rddp-problem-statement-04.txt
	Pages		: 21
	Date		: 2004-7-13
	
This draft addresses an IP-based solution to the problem of high
     system overhead due to the movement of user data in the network I/O
     path.  The overhead has limited the use of TCP/IP in
     interconnection networks, especially where high bandwidth, low
     latency and/or low overhead of end-system data movement are
     required by the hosted application.  An architectural solution
     enabling "copy avoidance" is proposed to eliminate it.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-problem-statement-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rddp-problem-statement-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rddp-problem-statement-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-rddp-problem-statement-04.txt>

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: [rddp] I-D ACTION:draft-ietf-rddp-arch-05.txt
From: [email-masked]
Date: Tue, 13 Jul 2004 16:06:34 -0400
Cc: rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote Direct Data Placement Working Group of the IETF.

	Title		: The Architecture of Direct Data Placement (DDP)And Remote 
			  Direct Memory Access (RDMA)On Internet Protocols
	Author(s)	: S. Bailey, T. Talpey
	Filename	: draft-ietf-rddp-arch-05.txt
	Pages		: 20
	Date		: 2004-7-13
	
This document defines an abstract architecture for Direct Data
Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to
run on Internet Protocol-suite transports.  This architecture does
not necessarily reflect the proper way to implement such protocols,
but is, rather, a descriptive tool for defining and understanding
the protocols.  DDP allows the efficient placement of data into
buffers designated by Upper Layer Protocols (e.g. RDMA).  RDMA
provides the semantics to enable Remote Direct Memory Access
between peers in a way consistent with application requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-arch-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rddp-arch-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rddp-arch-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-rddp-arch-05.txt>

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: [rddp] Authors: SUBMIT DRAFTS!!
From: [email-masked]
Date: Wed, 14 Jul 2004 18:30:13 -0400
Importance: high
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

A glance at the WG's IETF web page shows no trace of
the following drafts:

RDMAP (draft-ietf-rddp-rdmap-*)
Applicability Statement (draft-ietf-rddp-applicability-*)
SCTP Mapping (draft-ietf-rddp-sctp-*)
MPA (draft-ietf-rddp-mpa-*)

I realize that these drafts are relatively stable and
have expired courtesy of the delays in thrashing out
security, but ...

	DRAFT AUTHORS NEED TO SUBMIT NEW VERSIONS ASAP!!

This is because:

- Many of these drafts should go to WG Last Call not too
	long after San Diego on the assumption that we can
	get the security issues closed.  I'm going to have a
	very hard time explaining to the ADs that I'm starting
	WG Last Call on an expired draft or one for which no
	version was available during the San Diego meetings.

- Any draft going to WG Last Call needs to have up-to-date
	RFC 3667/3668 boilerplate.  See the current version of:

	http://www.ietf.org/ietf/1id-guidelines.txt

	for boilerplate than can be cut and pasted.  Pay
	attention to the 3668 IPR (e.g., patent) disclosure
	obligations.

- The iSER drafts will be on the IPS WG agenda, and will
	reference some of these missing drafts.  Not having
	these drafts available will be held against us.

The submission deadline for San Diego is 9am **EASTERN**
Time on Monday, July 19th (that's 6am for those of you
in California ...).

Sorry to do this in public, but "copious spare time" to
individually nag authors in private is in short supply ...

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

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-02.txt
From: [email-masked]
Date: Mon, 19 Jul 2004 15:59:44 -0400
Cc: rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote Direct Data Placement Working Group of the IETF.

	Title		: DDP/RDMAP Security
	Author(s)	: J. Pinkerton, et al.
	Filename	: draft-ietf-rddp-security-02.txt
	Pages		: 57
	Date		: 2004-7-19
	
This document analyzes security issues around implementation and 
   use of the Direct Data Placement Protocol(DDP) and Remote Direct 
   Memory Access Protocol (RDMAP). It first defines an architectural 
   model for an RDMA Network Interface Card (RNIC), which can 
   implement DDP or RDMAP and DDP. The document reviews various 
   attacks against the resources defined in the architectural model 
   and the countermeasures that can be used to protect the system. 
   Attacks are grouped into spoofing, tampering, information 
   disclosure, denial of service, and elevation of privilege. 
   Finally, the document concludes with a summary of security 
   services for RDDP, such as IPSec.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rddp-security-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rddp-security-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-rddp-security-02.txt>

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: [rddp] I-D ACTION:draft-ietf-rddp-mpa-01.txt
From: [email-masked]
Date: Tue, 20 Jul 2004 16:22:11 -0400
Cc: rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote Direct Data Placement Working Group of the IETF.

	Title		: Marker PDU Aligned Framing for TCP Specification
	Author(s)	: P. Culley, et al.
	Filename	: draft-ietf-rddp-mpa-01.txt,.pdf
	Pages		: 59
	Date		: 2004-7-20
	
A framing protocol is defined for TCP that is fully compliant with
applicable TCP RFCs and fully interoperable with existing TCP
implementations. The framing mechanism is designed to work as an
'adaptation layer' between TCP and the Direct Data Placement [DDP]
protocol, preserving the reliable, in-order delivery of TCP, while
adding the preservation of higher-level protocol record boundaries
that DDP requires.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-mpa-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rddp-mpa-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rddp-mpa-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-rddp-mpa-01.txt>

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: [rddp] Broadcom IPR in MPA
From: [email-masked]
Date: Fri, 23 Jul 2004 23:06:58 -0400
Cc: styson at broadcom.com
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

FYI:

http://www.ietf.org/ietf/IPR/3rd-party-broadcom-ipr-draft-ietf-rddp-mpa.txt

That notice does not meet the requirements of RFC 3668, specifically:

6.4.1.  The disclosure must list the numbers of any issued patents or
   published patent applications or indicate that the claim is based on
   unpublished patent applications.

Also, anyone who knows of any other IPR in any RDDP WG
draft should disclose it ASAP - see RFC 3668 Section 6
and http://www.ietf.org/ipr.html .

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

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: [rddp] Draft San Diego Agenda
From: [email-masked]
Date: Sun, 25 Jul 2004 18:43:45 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

San Diego IETF Meeting
August 1-6, 2004
---------------------------

Remote Direct Data Placement WG (rddp)

CHAIR:	David L. Black <Black_David at emc.com>

The RDDP WG works on Remote Direct Data Placement and Remote
Direct Memory Access functionality.  For more information,
please refer to the rddp charter at:

http://www.ietf.org/html.charters/rddp-charter.html

AGENDA: Subject to change

WEDNESDAY, August 4, 2004, 0900-1130
-------------------------------------
- Agenda Bashing and Administrivia (5 min)
	- Blue Sheets
	- NOTE WELL

- Status of drafts (5 min)

- Security
	(draft-ietf-rddp-security-02.txt)

Mandatory to implement security requirements 

- Any other issues/topics

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp