Subject: RE: [rddp] IPsec and RDDP as a transport
From: [email-masked]
To: [email-masked]
Date: Mon, 31 May 2004 21:38:58 -0400
List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>

> If one shot STags would have been an acceptable solution,
> why wouldn't making one shot STags a "MUST implement"
> be adequate?

Because that would allow long-lived STags without requiring
the countermeasures for the security exposures they create.
 
[... snip ...]

> I also repeat my objection to requiring that a cleanly layered
> RDDP implementation solve problems on a lower layer.
> This is *extremely* bad policy. The SCTP mapping in particular
> is quite suitable for implementation *over* SCTP.

That's fine - see below for an approach that solves RDDP's problems
within the RDDP layer ...
 
> The probable effect of forcing inclusion of IPsec in an RNIC

[... snip ...]

This is going off on an unproductive tangent.  Please reread
the following from my earlier post:

  Given the resistance to a "MUST implement IPsec" requirement,
  the only obvious remaining path forward is to design security
  mechanisms into the RDDP protocols (i.e., solve the security
  exposures created by RDDP headers with long-lived STags without
  resorting to IPsec). To a first approximation, the security
  mechanisms will have to be able to address the following:

	If an attacker hijacks a transport connection and
	attempts to make use of an existing STag, the attempt
	will fail because <put details of security mechanism
	here>.

I believe this is an alternative to "MUST implement IPsec", but
it will take some significant work to design the new security
mechanisms for the RDDP headers.  While I can't speak for the
security ADs, my working assumption (and intent in writing the
above text) is that these security mechanisms can be confined to
the RDDP headers (i.e., it will not be necessary to MAC or encrypt
the payloads to be placed).

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: RE: [rddp] IPsec and RDDP as a transport
From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 1 Jun 2004 01:00:23 -0500 (CDT)
Cc: [email-masked]
Importance: Normal
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]
User-agent: SquirrelMail/1.4.2

Black_David at emc.com said:
>> If one shot STags would have been an acceptable solution,
>> why wouldn't making one shot STags a "MUST implement"
>> be adequate?
>
> Because that would allow long-lived STags without requiring
> the countermeasures for the security exposures they create.
>

An existing TCP or SCTP application is not required to
use IPsec, even if it is present.

If a "MUST Implement IPsec" requirement is added to RDDP,
the application would still be free not to use it.

Applications that choose not to use security counter-measures
will be free to do so independently of whether you force
IPsec circuitry onto RNICs. Therefore it cannot see how
it can be cited as a justification for such a mandate.

This sounds like very much like "IPsec should be a requirement,
but we don't have an excuse to force that, so we'll just
require it on every new protocol wihthout exception."

If one-shot STags are availabe as a "MUST Implement"
feature then there is *no* additional vulnerability
created by use of RDDP. All exposed buffers are exposed
by action of the ULP itself. If one-shot STags are always
available, and perhaps even made the default, then there
is no inadvertant exposure of ULP memory. That leaves
only the same application layer security issues that
any TCP or SCTP application running over plain IP
would face.

Whether or not you believe such applications should
run over plain IP is irrelevant, the simple fact is
that this is a legitimate deployment decision.

Unlike the storage specialized protocols, RDDP as a
solution will be in direct competition with non-RDDP
applications using TCP and SCTP. Placing a requirement
on RDDP deployments that is *not* placed on non-RDDP
deployments can *only* be justified to the extent
that RDDP has created a security vulnerability that
would not be faced by the equivalent TCP/SCTP application.

Even without enhancing the local interface requirements
that is essentially already true. The local ULP has full
control over the exposure of its local buffers. If it
only examines those buffers *after* the permission has
expired, or when it has other reasons to believe that
the connection has not been compromised, then there is
*no* additional security vulnerability.

I do not believe you have disputed the above assertion,
only that with the existing requirements for the local
interface (and existing local interfaces) it is easy for
an application designer to lose track of what buffers they
have left exposed.

That limited  concern can be addressed by a handful of
requirements on the local interface. In what way has any
more radical solution been justified?

--
Caitlin Bestler
http://asomi.com/

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

To: [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport
From: [email-masked]
Date: Tue, 1 Jun 2004 09:05:52 -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]

> Black_David at emc.com said:
> >> If one shot STags would have been an acceptable solution,
> >> why wouldn't making one shot STags a "MUST implement"
> >> be adequate?
> >
> > Because that would allow long-lived STags without requiring
> > the countermeasures for the security exposures they create.
> >
> 
> An existing TCP or SCTP application is not required to
> use IPsec, even if it is present.

This continues to confuse "MUST implement" with "MUST use".
The usual IETF requirement is "MUST implement" so that an
administrator can decide whether the network environment
contains security threats that justify use of security
measures such as IPsec.  The administrator is free not to
use IPsec, but it is better to "have and not need" than to
"need and not have" - the requirement that there be
mandatory-to-implement security avoids the latter.

[... snip ...]

> If one-shot STags are available as a "MUST Implement"
> feature then there is *no* additional vulnerability
> created by use of RDDP. All exposed buffers are exposed
> by action of the ULP itself.

In which case there's no downside to making all STags one-shot,
because everything still works, right?  In practice, the answer
is "no" because the use of long-lived STags gets locked
into ULP applications at implementation time, so when a user
discovers that long-lived STags cause security issues in
her network, she has no way to deal with them, short of
ceasing to use the application.  Avoiding this is the
rationale behind mandatory-to-implement security requirements.

If there are sufficient advantages to using long-lived STags
to justify their inclusion in the specification, then RDDP
is obligated to provide the security countermeasures to the
risks caused by long-lived STags.  An implementation that
omits long-lived STags is free to omit the security measures
needed to deal with them.

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: RE: [rddp] IPsec and RDDP as a transport
From: Michael Krause <[email-masked]>
Date: Tue, 01 Jun 2004 06:14:03 -0700
In-reply-to: <[email-masked] o.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>
References: <[email-masked]> <[email-masked]>
Sender: [email-masked]

- I agree that "MUST implement IPSec" is a cost-adder with little motivation within the industry to execute. Putting this in is likely to see the same response by the hardware developers as seen in other ULP which is to simply ignore the requirement.

- I agree that "MUST implement one-shot STag" if it does not preclude long-lived STag is tenable since this becomes a ULP / OS design usage issue.

- I am concerned about trying to change the RDDP / DDP headers at this stage of the development for security purposes. I think the security draft and much of the debate to date has illustrated that documenting what the attacks are and allowing ULP / OS / etc. developers to determine which ones they will solve and which they will not at their appropriate interfaces is the preferred approach as it applies KISS to RDDP / DDP. Use of KISS tends to avoid subsequent unanticipated vulnerabilities by constraining the permutations of events / conditions that lead to new attacks.

Mike

At 11:00 PM 5/31/2004, Caitlin Bestler wrote:

Black_David at emc.com said:
>> If one shot STags would have been an acceptable solution,
>> why wouldn't making one shot STags a "MUST implement"
>> be adequate?
>
> Because that would allow long-lived STags without requiring
> the countermeasures for the security exposures they create.
>

An existing TCP or SCTP application is not required to
use IPsec, even if it is present.

If a "MUST Implement IPsec" requirement is added to RDDP,
the application would still be free not to use it.

Applications that choose not to use security counter-measures
will be free to do so independently of whether you force
IPsec circuitry onto RNICs. Therefore it cannot see how
it can be cited as a justification for such a mandate.

This sounds like very much like "IPsec should be a requirement,
but we don't have an excuse to force that, so we'll just
require it on every new protocol wihthout exception."

If one-shot STags are availabe as a "MUST Implement"
feature then there is *no* additional vulnerability
created by use of RDDP. All exposed buffers are exposed
by action of the ULP itself. If one-shot STags are always
available, and perhaps even made the default, then there
is no inadvertant exposure of ULP memory. That leaves
only the same application layer security issues that
any TCP or SCTP application running over plain IP
would face.

Whether or not you believe such applications should
run over plain IP is irrelevant, the simple fact is
that this is a legitimate deployment decision.

Unlike the storage specialized protocols, RDDP as a
solution will be in direct competition with non-RDDP
applications using TCP and SCTP. Placing a requirement
on RDDP deployments that is *not* placed on non-RDDP
deployments can *only* be justified to the extent
that RDDP has created a security vulnerability that
would not be faced by the equivalent TCP/SCTP application.

Even without enhancing the local interface requirements
that is essentially already true. The local ULP has full
control over the exposure of its local buffers. If it
only examines those buffers *after* the permission has
expired, or when it has other reasons to believe that
the connection has not been compromised, then there is
*no* additional security vulnerability.

I do not believe you have disputed the above assertion,
only that with the existing requirements for the local
interface (and existing local interfaces) it is easy for
an application designer to lose track of what buffers they
have left exposed.

That limited  concern can be addressed by a handful of
requirements on the local interface. In what way has any
more radical solution been justified?

--
Caitlin Bestler
http://asomi.com/

 _______________________________________________
 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: "'Michael Krause'" <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Leonid Grossman" <[email-masked]>
Date: Tue, 1 Jun 2004 10:30:16 -0700
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>
Sender: [email-masked]
Thread-index: AcRH+8khQY+nM3w9TT6top5BFFsmbgAAJ8VA

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of Michael Krause
> Sent: Tuesday, June 01, 2004 6:14 AM
> To: rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> - I agree that "MUST implement IPSec" is a cost-adder with 
> little motivation within the industry to execute.  Putting 
> this in is likely to see the same response by the hardware 
> developers as seen in other ULP which is to simply ignore the 
> requirement.

I agree; at least for 10GbE the "MUST implement IPSec" requirement would be
not just a cost-adder - it will be simply impossible to productize an RNIC
with IPSec for the next 3-4 years, so the requirement is going to be
ignored.

Leonid

> 
> - I agree that "MUST implement one-shot STag" if it does not 
> preclude long-lived STag is tenable since this becomes a ULP 
> / OS design usage issue.
> 
> - I am concerned about trying to change the RDDP / DDP 
> headers at this stage of the development for security 
> purposes.  I think the security draft and much of the debate 
> to date has illustrated that documenting what the attacks are 
> and allowing ULP / OS / etc. developers to determine which 
> ones they will solve and which they will not at their 
> appropriate interfaces is the preferred approach as it 
> applies KISS to RDDP / DDP.  Use of KISS tends to avoid 
> subsequent unanticipated vulnerabilities by constraining the 
> permutations of events / conditions that lead to new attacks.
> 
> Mike
> 
> 
> 
> At 11:00 PM 5/31/2004, Caitlin Bestler wrote:
> 
> >Black_David at emc.com said:
> > >> If one shot STags would have been an acceptable solution, why 
> > >> wouldn't making one shot STags a "MUST implement"
> > >> be adequate?
> > >
> > > Because that would allow long-lived STags without requiring the 
> > > countermeasures for the security exposures they create.
> > >
> >
> >An existing TCP or SCTP application is not required to use 
> IPsec, even 
> >if it is present.
> >
> >If a "MUST Implement IPsec" requirement is added to RDDP, the 
> >application would still be free not to use it.
> >
> >Applications that choose not to use security 
> counter-measures will be 
> >free to do so independently of whether you force IPsec 
> circuitry onto 
> >RNICs. Therefore it cannot see how it can be cited as a 
> justification 
> >for such a mandate.
> >
> >This sounds like very much like "IPsec should be a 
> requirement, but we 
> >don't have an excuse to force that, so we'll just require it 
> on every 
> >new protocol wihthout exception."
> >
> >If one-shot STags are availabe as a "MUST Implement"
> >feature then there is *no* additional vulnerability created 
> by use of 
> >RDDP. All exposed buffers are exposed by action of the ULP 
> itself. If 
> >one-shot STags are always available, and perhaps even made 
> the default, 
> >then there is no inadvertant exposure of ULP memory. That 
> leaves only 
> >the same application layer security issues that any TCP or SCTP 
> >application running over plain IP would face.
> >
> >Whether or not you believe such applications should run over 
> plain IP 
> >is irrelevant, the simple fact is that this is a legitimate 
> deployment 
> >decision.
> >
> >Unlike the storage specialized protocols, RDDP as a solution 
> will be in 
> >direct competition with non-RDDP applications using TCP and SCTP. 
> >Placing a requirement on RDDP deployments that is *not* placed on 
> >non-RDDP deployments can *only* be justified to the extent that RDDP 
> >has created a security vulnerability that would not be faced by the 
> >equivalent TCP/SCTP application.
> >
> >Even without enhancing the local interface requirements that is 
> >essentially already true. The local ULP has full control over the 
> >exposure of its local buffers. If it only examines those buffers 
> >*after* the permission has expired, or when it has other reasons to 
> >believe that the connection has not been compromised, then there is
> >*no* additional security vulnerability.
> >
> >I do not believe you have disputed the above assertion, only 
> that with 
> >the existing requirements for the local interface (and 
> existing local 
> >interfaces) it is easy for an application designer to lose track of 
> >what buffers they have left exposed.
> >
> >That limited  concern can be addressed by a handful of 
> requirements on 
> >the local interface. In what way has any more radical solution been 
> >justified?
> >
> >--
> >Caitlin Bestler
> >http://asomi.com/
> >
> >_______________________________________________
> >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
> 

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

To: [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport
From: [email-masked]
Date: Tue, 1 Jun 2004 19:11:56 -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]

Mike,

I'm not sure I see a solution in what you're suggesting.

The situation is that if RDDP specifies long-lived
STags, then any implementation that supports them
MUST implement security to protect them.  This is an
IESG requirement - fighting this results in no RFCs.

Between not wanting IPsec to be "MUST implement" and
not wanting to change the RDDP/DDP headers, how do
you propose to address this situation?  Is an additional
(OPTIONAL to use) security header acceptable?

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: Tuesday, June 01, 2004 9:14 AM
> To: rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> 
> - I agree that "MUST implement IPSec" is a cost-adder with little 
> motivation within the industry to execute.  Putting this in is likely to 
> see the same response by the hardware developers as seen in other ULP
which 
> is to simply ignore the requirement.
> 
> - I agree that "MUST implement one-shot STag" if it does not preclude 
> long-lived STag is tenable since this becomes a ULP / OS design usage
issue.
> 
> - I am concerned about trying to change the RDDP / DDP headers at this 
> stage of the development for security purposes.  I think the security
draft 
> and much of the debate to date has illustrated that documenting what the 
> attacks are and allowing ULP / OS / etc. developers to determine which
ones 
> they will solve and which they will not at their appropriate interfaces is

> the preferred approach as it applies KISS to RDDP / DDP.  Use of KISS
tends 
> to avoid subsequent unanticipated vulnerabilities by constraining the 
> permutations of events / conditions that lead to new attacks.
> 
> Mike

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

To: [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 2 Jun 2004 03:48:10 -0500 (CDT)
Cc: rddp at ietf.org
Importance: Normal
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]
User-agent: SquirrelMail/1.4.2

Black_David at emc.com said:
>> Black_David at emc.com said:
>> >> If one shot STags would have been an acceptable solution,
>> >> why wouldn't making one shot STags a "MUST implement"
>> >> be adequate?
>> >
>> > Because that would allow long-lived STags without requiring
>> > the countermeasures for the security exposures they create.
>> >
>> An existing TCP or SCTP application is not required to
>> use IPsec, even if it is present.
>
> This continues to confuse "MUST implement" with "MUST use".
> The usual IETF requirement is "MUST implement" so that an
> administrator can decide whether the network environment
> contains security threats that justify use of security
> measures such as IPsec.  The administrator is free not to
> use IPsec, but it is better to "have and not need" than to
> "need and not have" - the requirement that there be
> mandatory-to-implement security avoids the latter.
>

With all due respect, the confusion is over what is required
and why.

You seem to be working under the assumption that the IESG
had mandated that DDP headers be protected from spoofing,
either by IPsec or by RDDP itself.

That would only be true if the DDP header posed a new
security risk, one not faced by an equivalent LLP-only
application.

I do not believe that this analysis is shared by the WG.
I certainly do not accept it.

A DDP Header has no magic access to user memory. Just as
any above-transport-header, it only has access to user
memory to the extent authorized by the ULP.

I do not believe that you, or anyone else, has disputed
that assertion.

Any application that accepts delivered payload without
*some* form of authentication (whether transport or
application layer) is at risk from any attacker that
can spoof IP packets.

And therefore a wise application designer places their
own authentication in when forged packets may pose a
security vulnerability (which is not always the case)
and there is no transport level authentication service
in use (or available).

But whether or not something is wise for an application
developer is not the issue. The question is whether RDDP
creates a *new* security vulnerability that would not have
existed for a non-RDDP version of the same application.

Basically, if a TCP or SCTP application has the option
of being reckless with its own security, an RDDP application
must have the same right. An RDDP-specific security requirement
can only be justified by an RDDP-specific security vulnerability.

The only identified RDDP-specific security vulnerability is
minor -- namely that the local interface *might* not make
it totally clear to the ULP what exposure it has created.
Default use of persistent STags could indeed lead to such
confusion by a developer new to RDMA.

But I do not accept that a ULP designer that is *deliberately*
using persistent STags has no concept of what they have
exposed. If an application developer has *deliberately*
used a persistent STag, then they are aware of the
persistence and therefore is no new security vulnerability.

The vulnerability is *not* in the RDDP headers, but in the
potential *misunderstanding* of the duration of STag exposure
by developers new to RDMA.

Therefore the solution proposed is *not* to secure the RDDP
headers, but to correct the potential misunderstanding on
the duration of STag exposure.

I believe that requiring a one-shot STag capability is
sufficient, and perhaps that use of persistent STags
MUST NOT be enabled as a default.

The security problem here is strictly within the local
interface. The solution can also be found there, without
driving up the cost of RNICs or disrupting current
development efforts.

Is there anyone in the WG who would argue that the
protocol itself creates a security vulnerability?

--
Caitlin Bestler
http://asomi.com/

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

To: [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport
From: [email-masked]
Date: Wed, 2 Jun 2004 10:31:41 -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]

Caitlin Bestler writes:
 
> That would only be true if the DDP header posed a new
> security risk, one not faced by an equivalent LLP-only
> application.
> 
> I do not believe that this analysis is shared by the WG.
> I certainly do not accept it.
> 
> A DDP Header has no magic access to user memory. Just as
> any above-transport-header, it only has access to user
> memory to the extent authorized by the ULP.
> 
> I do not believe that you, or anyone else, has disputed
> that assertion.

The latter assertion is correct, but it does not imply that
a DDP header creates no risks beyond an equivalent LLP-only
application.  For an LLP-only application transport buffers
are always one-shot and receive addresses in memory are
determined by the receiver, not the sender.  If the WG
were prepared to limit itself to this behavior by requiring
that all STags be one-shot, then the position that there
are no new security risks should be defensible.  The WG
does not appear to be prepared to make this restriction.

More importantly, relying on the "authorized by the ULP"
assertion is not acceptable to the IESG.  That approach
amounts to an instruction to ULP developers not to use
long-lived STags if they are a potential cause of security
problems and also an instruction to users not to use ULPs
that employ long-lived STags if long-lived STags will cause
security problems on their network(s).  I've recently had
to deal with another draft that tried this sort of "don't
use feature <X> if it will cause security problems"
approach; the IESG rejected that approach, and the security
considerations section of the draft had to be revised.

The bottom line is that long-lived STags create additional
memory exposure that is not present in an equivalent LLP-only
application.  The fact that the ULP chose to create the
exposure does not absolve RDDP of providing security measures
to deal with it.  IETF requires that protocols which create
security issues deal with those security issues and not palm
them off on other protocols (e.g., by asserting that all
security issues created by long-lived RDDP STags are ULP
problems because the ULP chose to use them).

I've just updated and resubmitted draft-ietf-rddp-rdma-concerns
(will appear shortly as a -01 version) - it contains nearly
2-year-old text in its security considerations section
pointing out this memory exposure issue.

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] Administrative Items
From: [email-masked]
Date: Wed, 2 Jun 2004 16:49:15 -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]

Everyone,

I've just sent in the request for a 2-2.5 hour RDDP WG
meeting slot in San Diego.  Based on current list
discussion, I would expect that much of this is going
to be spent on setting direction for security (however,
exceeding expectations and settling this sooner would
be a pleasant and welcome surprise).

Some IETF procedures and rules have been updated - the IETF
is now operating under the following two RFCs:
	- RFC 3667 IETF Rights in Contributions
	- RFC 3668 Intellectual Property Rights in IETF Technology
Copyrights on Internet-Drafts are among the topics covered
in RFC 3667 and patents are among the topics covered in
RFC 3668.  See the RFCs for details.

One of the consequences is that the required
Internet-Draft "boilerplate" has changed.  In accordance
with Section 5.1 of RFC 3667, all Internet-Drafts must
now carry the following statement:

   By submitting this Internet-Draft, I certify that any
   applicable patent or other IPR claims of which I am aware
   have been disclosed, and any of which I become aware
   will be disclosed, in accordance with RFC 3668.

All drafts for consideration in the San Diego meeting need
to carry this, and any relevant IPR notices have to go in
at the same time as the draft or beforehand.  RFC 3668 has
some changes to disclosure from RFC 2026 - see the RFC for
details.  See Section 5 of RFC 3667 for other changes to
"boilerplate" text in Internet-Drafts.

Anyone who knows of "applicable patent or other IPR claims"
in any RDDP WG draft should probably start working on the
disclosure(s) sooner rather than later.  I believe that there
is an IPR disclosure on the MPA draft coming from Broadcom.

Some of the RDDP WG drafts have disappeared from the IETF
web site - if you're the author of one of these drafts,
please bump the version number, update the boilerplate,
and submit the result.

FYI and Thanks,
--David (RDDP WG Chair)
----------------------------------------------------
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-rdma-concerns-01.txt
From: [email-masked]
Date: Thu, 03 Jun 2004 15:58:21 -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 and RDMA Concerns
	Author(s)	: D. Black, et al.
	Filename	: draft-ietf-rddp-rdma-concerns-01.txt
	Pages		: 7
	Date		: 2004-6-3
	
This draft describes technical concerns that should be considered
    in the design of standardized RDMA and DDP protocols/mechanisms for 

    use with Internet transport protocols.  This draft was written to
    provide input to the proposed new Remote Direct Data Placement
    (rddp) WG, and is not intended for publication as an RFC.
    
    This is an updated and resubmitted version of draft-ietf-rddp-rdma-
    concerns-00.txt to make it available for current discussions of
    mandatory-to-implement security in the RDDP WG.  Sections 4.1, 4.2, 

    and 5 are of particular relevance to that discussion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-rdma-concerns-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-rdma-concerns-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-rdma-concerns-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-rdma-concerns-01.txt>

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

To: <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Barron, Dwight" <[email-masked]>
Date: Fri, 4 Jun 2004 18:51:00 -0500
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: AcRI6zWNA965H0pNRuK9MywJYWZVTgA12ugw
Thread-topic: [rddp] IPsec and RDDP as a transport

Sorry to be dense, but I'm still having trouble visualizing the attack
that makes DDP more vulnerable. I think it has been relegated to a man
in the middle attack scenario, as bogus data from the real peer always
gets through, even with IPSEC enabled. The transport layer behavior is
the same with/without DDP headers; a packet with an appropriate
transport sequence number gets ACKed and passed upstream to be placed in
a buffer. The buffer eventually gets passed to the application. The only
difference I see is in the buffer model, random access within the scope
of an Stag vs. being put in a pre-posted buffer. Either way, the wrong
data gets passed to the upper layer because of spoofing that got past
the transport layer. Why is DDP being asked to implement a mandatory
solution that protects the transport from MITM attacks? I acknowledge
that DDP is in a gray area between transport and ULP, but either way,
there should be consistency for all new ULPs and/or transports. Where is
the cry for mandatory IPSEC on SCTP?

BTW - my recollection of the year old Stag security issue was related to
the necessary isolations/associations of an Stag with each transport
stream, a local peer security issue.

Regards,
Dwight

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> Behalf Of Black_David at emc.com
> Sent: Wednesday, June 02, 2004 9:32 AM
> To: rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> Caitlin Bestler writes:
>  
> > That would only be true if the DDP header posed a new
> security risk,
> > one not faced by an equivalent LLP-only application.
> > 
> > I do not believe that this analysis is shared by the WG.
> > I certainly do not accept it.
> > 
> > A DDP Header has no magic access to user memory. Just as any 
> > above-transport-header, it only has access to user memory to the 
> > extent authorized by the ULP.
> > 
> > I do not believe that you, or anyone else, has disputed that 
> > assertion.
> 
> The latter assertion is correct, but it does not imply that
> a DDP header creates no risks beyond an equivalent LLP-only
> application.  For an LLP-only application transport buffers 
> are always one-shot and receive addresses in memory are 
> determined by the receiver, not the sender.  If the WG were 
> prepared to limit itself to this behavior by requiring that 
> all STags be one-shot, then the position that there are no 
> new security risks should be defensible.  The WG does not 
> appear to be prepared to make this restriction.
> 
> More importantly, relying on the "authorized by the ULP"
> assertion is not acceptable to the IESG.  That approach 
> amounts to an instruction to ULP developers not to use 
> long-lived STags if they are a potential cause of security 
> problems and also an instruction to users not to use ULPs 
> that employ long-lived STags if long-lived STags will cause 
> security problems on their network(s).  I've recently had to 
> deal with another draft that tried this sort of "don't use 
> feature <X> if it will cause security problems" approach; the 
> IESG rejected that approach, and the security considerations 
> section of the draft had to be revised.
> 
> The bottom line is that long-lived STags create additional
> memory exposure that is not present in an equivalent LLP-only 
> application.  The fact that the ULP chose to create the 
> exposure does not absolve RDDP of providing security measures 
> to deal with it.  IETF requires that protocols which create 
> security issues deal with those security issues and not palm 
> them off on other protocols (e.g., by asserting that all 
> security issues created by long-lived RDDP STags are ULP 
> problems because the ULP chose to use them).
> 
> I've just updated and resubmitted
> draft-ietf-rddp-rdma-concerns (will appear shortly as a -01 
> version) - it contains nearly 2-year-old text in its security 
> considerations section pointing out this memory exposure issue.
> 
> 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
> 

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

To: [email-masked], [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport
From: [email-masked]
Date: Fri, 4 Jun 2004 20:56:09 -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]

Dwight,

> Sorry to be dense, but I'm still having trouble visualizing the attack
> that makes DDP more vulnerable. I think it has been relegated to a man
> in the middle attack scenario, as bogus data from the real peer always
> gets through, even with IPSEC enabled. The transport layer behavior is
> the same with/without DDP headers; a packet with an appropriate
> transport sequence number gets ACKed and passed upstream to be placed
> in a buffer. The buffer eventually gets passed to the application.

The difference happens here.  If the STag is 'long-lived' or 'persistent'
and has not been invalidated, the buffer can still be modified remotely
*after* being passed to the application.  Such modification is not
possible in the absence of DDP.  If the STag is 'one-shot' (in whatever
sense that restriction is defined), the important property is that the
application can rely on the data not being changed by remote access
after the buffer has been passed to the application.  If the WG
is prepared to restrict all STags to be 'one-shot' so that at the point
where the buffer is passed to the application, the STag used to deliver
the data MUST be invalid (and the RDDP implementation is responsible
for ensuring this), then it should be possible to avoid additional
security requirements in this area.

[... snip ...]

> Why is DDP being asked to implement a mandatory
> solution that protects the transport from MITM attacks?

Protection of the transport is not being required.  What is being
required is to be able to protect the application from exploitation of
memory exposure enabled by RDDP functionality that is beyond that of
the underlying transport.  If RDDP is willing to forego that additional
functionality, there should no longer be a problem that needs a
mandatory solution.

> I acknowledge
> that DDP is in a gray area between transport and ULP, but either way,
> there should be consistency for all new ULPs and/or transports. Where is
> the cry for mandatory IPSEC on SCTP?

The ULP can choose how it wants to secure its data.  TLS is among the
possibilities and can be used over SCTP.  Beyond this, if SCTP runs over
IPv6, IPsec is mandatory, and I would expect that if any of the IP
Storage protocols (iSCSI, FCIP, iFCP) are defined over SCTP, IPsec
will remain mandatory for them.  In any case, IPsec is sufficient,
but not necessary for RDDP.  A mechanism that prevents MITM misuse
of RDDP headers is a possible alternative.

> BTW - my recollection of the year old Stag security issue was related to
> the necessary isolations/associations of an Stag with each transport
> stream, a local peer security issue.

That was a related, but different issue.  The ability to control
STag association with transport streams is still necessary.

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: Barron, Dwight [mailto:dwight.barron at hp.com] 
> Sent: Friday, June 04, 2004 7:51 PM
> To: Black_David at emc.com; rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> Sorry to be dense, but I'm still having trouble visualizing the attack
> that makes DDP more vulnerable. I think it has been relegated to a man
> in the middle attack scenario, as bogus data from the real peer always
> gets through, even with IPSEC enabled. The transport layer behavior is
> the same with/without DDP headers; a packet with an appropriate
> transport sequence number gets ACKed and passed upstream to be placed in
> a buffer. The buffer eventually gets passed to the application. The only
> difference I see is in the buffer model, random access within the scope
> of an Stag vs. being put in a pre-posted buffer. Either way, the wrong
> data gets passed to the upper layer because of spoofing that got past
> the transport layer. Why is DDP being asked to implement a mandatory
> solution that protects the transport from MITM attacks? I acknowledge
> that DDP is in a gray area between transport and ULP, but either way,
> there should be consistency for all new ULPs and/or transports. Where is
> the cry for mandatory IPSEC on SCTP?
> 
> BTW - my recollection of the year old Stag security issue was related to
> the necessary isolations/associations of an Stag with each transport
> stream, a local peer security issue.
> 
> Regards,
> Dwight
> 
> > -----Original Message-----
> > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> > Behalf Of Black_David at emc.com
> > Sent: Wednesday, June 02, 2004 9:32 AM
> > To: rddp at ietf.org
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> > 
> > 
> > Caitlin Bestler writes:
> >  
> > > That would only be true if the DDP header posed a new
> > security risk,
> > > one not faced by an equivalent LLP-only application.
> > > 
> > > I do not believe that this analysis is shared by the WG.
> > > I certainly do not accept it.
> > > 
> > > A DDP Header has no magic access to user memory. Just as any 
> > > above-transport-header, it only has access to user memory to the 
> > > extent authorized by the ULP.
> > > 
> > > I do not believe that you, or anyone else, has disputed that 
> > > assertion.
> > 
> > The latter assertion is correct, but it does not imply that
> > a DDP header creates no risks beyond an equivalent LLP-only
> > application.  For an LLP-only application transport buffers 
> > are always one-shot and receive addresses in memory are 
> > determined by the receiver, not the sender.  If the WG were 
> > prepared to limit itself to this behavior by requiring that 
> > all STags be one-shot, then the position that there are no 
> > new security risks should be defensible.  The WG does not 
> > appear to be prepared to make this restriction.
> > 
> > More importantly, relying on the "authorized by the ULP"
> > assertion is not acceptable to the IESG.  That approach 
> > amounts to an instruction to ULP developers not to use 
> > long-lived STags if they are a potential cause of security 
> > problems and also an instruction to users not to use ULPs 
> > that employ long-lived STags if long-lived STags will cause 
> > security problems on their network(s).  I've recently had to 
> > deal with another draft that tried this sort of "don't use 
> > feature <X> if it will cause security problems" approach; the 
> > IESG rejected that approach, and the security considerations 
> > section of the draft had to be revised.
> > 
> > The bottom line is that long-lived STags create additional
> > memory exposure that is not present in an equivalent LLP-only 
> > application.  The fact that the ULP chose to create the 
> > exposure does not absolve RDDP of providing security measures 
> > to deal with it.  IETF requires that protocols which create 
> > security issues deal with those security issues and not palm 
> > them off on other protocols (e.g., by asserting that all 
> > security issues created by long-lived RDDP STags are ULP 
> > problems because the ULP chose to use them).
> > 
> > I've just updated and resubmitted
> > draft-ietf-rddp-rdma-concerns (will appear shortly as a -01 
> > version) - it contains nearly 2-year-old text in its security 
> > considerations section pointing out this memory exposure issue.
> > 
> > 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
> > 
> 

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

To: [email-masked], [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Uri Elzur" <[email-masked]>
Date: Fri, 4 Jun 2004 18:20:17 -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: AcRI60WUILrnjiCXR5WHhisZBEB5cQBpq54Q
Thread-topic: [rddp] IPsec and RDDP as a transport

David, All

I'd like to chime in on this important discussion. I'm sorry, but I do
fail to see the "new" security hole. The response I've seen on 5/9 to
Caitilin's real good discussion, was that a "buffer overflow" is the
risk. I believe this is wrong. The RDMA layer will guarantee with its
checks and bounds this cannot happen (if other layer is used on top of
DDP, it needs to provide similar mechanisms). To take a step back, there
are potentially two types security threats: on the wire and on end
station. 
 
1) Network: A connection + resources are allocated only after the remote
is proven to be trustworthy with mechanisms outside the scope of DDP. So
what if some man-in-the-middle spoofs the STags (no need to deal with
spoofing IP or Transport as this is NOT a DDP issue). The probability is
higher the longer the STag is exposed, hence the discussion about
shingle shot (but note that even single shot doesn't limit the time the
exposure is there...). The key in my mind is that in order to spoof the
STag, you have to hijack the connection, as it is only the combination
of TCP/IP + STag that opens the buffer. Therefore, it seems like this is
no different than TCP/IP hijack and is not a new risk model

2) End station: we probably need a statement about demarcation of
responsibilities between the application and the wire protocol. I
believe, it's the responsibility of the wire protocol not to expose the
end station and any of its other resources  (including other processes
or threads, other devices etc.) except for the resources allocated by
the application or the comm stack. Actually TCP as one example, has the
flexibility to allocate resources to a connection even when no resources
has been allocated by the application. However, TCP guarantees the
application will not be given more data than resources it hands to TCP
stack. DDP is layered on top of a reliable transport (TCP, SCTP etc.)
and is not allocating any resources on its own. So does the DDP wire
protocol bear any additional responsibilities that other transports
never had? In other words, who owns the application resources: the
application or a performance enhancement protocol like RDDP? To me the
answer is clear and the application should have a free hand to expose
its buffers, AS LONG as actions of a single application do not expose
other (which is an OS issue not a wire protocol issue). IPSec will not
solve this problem...

SO what do I miss? Before this WG subscribes a bitter pill, it better
clarify what illness it is trying to cure.  
 
Uri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Black_David at emc.com
Sent: Wednesday, June 02, 2004 7:32 AM
To: [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport

Caitlin Bestler writes:
 
> That would only be true if the DDP header posed a new security risk, 
> one not faced by an equivalent LLP-only application.
> 
> I do not believe that this analysis is shared by the WG.
> I certainly do not accept it.
> 
> A DDP Header has no magic access to user memory. Just as
> any above-transport-header, it only has access to user
> memory to the extent authorized by the ULP.
> 
> I do not believe that you, or anyone else, has disputed
> that assertion.

The latter assertion is correct, but it does not imply that
a DDP header creates no risks beyond an equivalent LLP-only application.
For an LLP-only application transport buffers are always one-shot and
receive addresses in memory are determined by the receiver, not the
sender.  If the WG were prepared to limit itself to this behavior by
requiring that all STags be one-shot, then the position that there are
no new security risks should be defensible.  The WG does not appear to
be prepared to make this restriction.

More importantly, relying on the "authorized by the ULP" assertion is
not acceptable to the IESG.  That approach amounts to an instruction to
ULP developers not to use long-lived STags if they are a potential cause
of security problems and also an instruction to users not to use ULPs
that employ long-lived STags if long-lived STags will cause security
problems on their network(s).  I've recently had to deal with another
draft that tried this sort of "don't use feature <X> if it will cause
security problems" approach; the IESG rejected that approach, and the
security considerations section of the draft had to be revised.

The bottom line is that long-lived STags create additional memory
exposure that is not present in an equivalent LLP-only application.  The
fact that the ULP chose to create the exposure does not absolve RDDP of
providing security measures to deal with it.  IETF requires that
protocols which create security issues deal with those security issues
and not palm them off on other protocols (e.g., by asserting that all
security issues created by long-lived RDDP STags are ULP problems
because the ULP chose to use them).

I've just updated and resubmitted draft-ietf-rddp-rdma-concerns (will
appear shortly as a -01 version) - it contains nearly 2-year-old text in
its security considerations section pointing out this memory exposure
issue.

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

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

To: <[email-masked]>
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Somesh Gupta" <[email-masked]>
Date: Fri, 4 Jun 2004 18:28:04 -0700
Importance: Normal
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>
Sender: [email-masked]

It seems that for iSCSI specifically, RDMA writes icrease the possibility
of data corruption, even with 'one-shot' STags. Consider iSCSI over TCP,
with header and data CRC. If a random TCP packet is used to attack the
connection, and the packet is accepted (large windows etc), the CRC
checks will fail and the problem detected before a corruption occurs.

Now consider iSCSI using iSER over RDDP. iSCSI depends on RDDP for
CRC checks. An attack on the connection (out of order RDMA writes)
could place data in the write buffers and if this happens, the attack
will never be detected.

Maybe this problem is iSCSI specific only.

Somesh
> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org]On Behalf Of
> Black_David at emc.com
> Sent: Friday, June 04, 2004 5:56 PM
> To: dwight.barron at hp.com; rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
>
>
> Dwight,
>
> > Sorry to be dense, but I'm still having trouble visualizing the attack
> > that makes DDP more vulnerable. I think it has been relegated to a man
> > in the middle attack scenario, as bogus data from the real peer always
> > gets through, even with IPSEC enabled. The transport layer behavior is
> > the same with/without DDP headers; a packet with an appropriate
> > transport sequence number gets ACKed and passed upstream to be placed
> > in a buffer. The buffer eventually gets passed to the application.
>
> The difference happens here.  If the STag is 'long-lived' or 'persistent'
> and has not been invalidated, the buffer can still be modified remotely
> *after* being passed to the application.  Such modification is not
> possible in the absence of DDP.  If the STag is 'one-shot' (in whatever
> sense that restriction is defined), the important property is that the
> application can rely on the data not being changed by remote access
> after the buffer has been passed to the application.  If the WG
> is prepared to restrict all STags to be 'one-shot' so that at the point
> where the buffer is passed to the application, the STag used to deliver
> the data MUST be invalid (and the RDDP implementation is responsible
> for ensuring this), then it should be possible to avoid additional
> security requirements in this area.
>
> [... snip ...]
>
> > Why is DDP being asked to implement a mandatory
> > solution that protects the transport from MITM attacks?
>
> Protection of the transport is not being required.  What is being
> required is to be able to protect the application from exploitation of
> memory exposure enabled by RDDP functionality that is beyond that of
> the underlying transport.  If RDDP is willing to forego that additional
> functionality, there should no longer be a problem that needs a
> mandatory solution.
>
> > I acknowledge
> > that DDP is in a gray area between transport and ULP, but either way,
> > there should be consistency for all new ULPs and/or transports. Where is
> > the cry for mandatory IPSEC on SCTP?
>
> The ULP can choose how it wants to secure its data.  TLS is among the
> possibilities and can be used over SCTP.  Beyond this, if SCTP runs over
> IPv6, IPsec is mandatory, and I would expect that if any of the IP
> Storage protocols (iSCSI, FCIP, iFCP) are defined over SCTP, IPsec
> will remain mandatory for them.  In any case, IPsec is sufficient,
> but not necessary for RDDP.  A mechanism that prevents MITM misuse
> of RDDP headers is a possible alternative.
>
> > BTW - my recollection of the year old Stag security issue was related to
> > the necessary isolations/associations of an Stag with each transport
> > stream, a local peer security issue.
>
> That was a related, but different issue.  The ability to control
> STag association with transport streams is still necessary.
>
> 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: Barron, Dwight [mailto:dwight.barron at hp.com]
> > Sent: Friday, June 04, 2004 7:51 PM
> > To: Black_David at emc.com; rddp at ietf.org
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> >
> >
> > Sorry to be dense, but I'm still having trouble visualizing the attack
> > that makes DDP more vulnerable. I think it has been relegated to a man
> > in the middle attack scenario, as bogus data from the real peer always
> > gets through, even with IPSEC enabled. The transport layer behavior is
> > the same with/without DDP headers; a packet with an appropriate
> > transport sequence number gets ACKed and passed upstream to be placed in
> > a buffer. The buffer eventually gets passed to the application. The only
> > difference I see is in the buffer model, random access within the scope
> > of an Stag vs. being put in a pre-posted buffer. Either way, the wrong
> > data gets passed to the upper layer because of spoofing that got past
> > the transport layer. Why is DDP being asked to implement a mandatory
> > solution that protects the transport from MITM attacks? I acknowledge
> > that DDP is in a gray area between transport and ULP, but either way,
> > there should be consistency for all new ULPs and/or transports. Where is
> > the cry for mandatory IPSEC on SCTP?
> >
> > BTW - my recollection of the year old Stag security issue was related to
> > the necessary isolations/associations of an Stag with each transport
> > stream, a local peer security issue.
> >
> > Regards,
> > Dwight
> >
> > > -----Original Message-----
> > > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> > > Behalf Of Black_David at emc.com
> > > Sent: Wednesday, June 02, 2004 9:32 AM
> > > To: rddp at ietf.org
> > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > >
> > >
> > > Caitlin Bestler writes:
> > >
> > > > That would only be true if the DDP header posed a new
> > > security risk,
> > > > one not faced by an equivalent LLP-only application.
> > > >
> > > > I do not believe that this analysis is shared by the WG.
> > > > I certainly do not accept it.
> > > >
> > > > A DDP Header has no magic access to user memory. Just as any
> > > > above-transport-header, it only has access to user memory to the
> > > > extent authorized by the ULP.
> > > >
> > > > I do not believe that you, or anyone else, has disputed that
> > > > assertion.
> > >
> > > The latter assertion is correct, but it does not imply that
> > > a DDP header creates no risks beyond an equivalent LLP-only
> > > application.  For an LLP-only application transport buffers
> > > are always one-shot and receive addresses in memory are
> > > determined by the receiver, not the sender.  If the WG were
> > > prepared to limit itself to this behavior by requiring that
> > > all STags be one-shot, then the position that there are no
> > > new security risks should be defensible.  The WG does not
> > > appear to be prepared to make this restriction.
> > >
> > > More importantly, relying on the "authorized by the ULP"
> > > assertion is not acceptable to the IESG.  That approach
> > > amounts to an instruction to ULP developers not to use
> > > long-lived STags if they are a potential cause of security
> > > problems and also an instruction to users not to use ULPs
> > > that employ long-lived STags if long-lived STags will cause
> > > security problems on their network(s).  I've recently had to
> > > deal with another draft that tried this sort of "don't use
> > > feature <X> if it will cause security problems" approach; the
> > > IESG rejected that approach, and the security considerations
> > > section of the draft had to be revised.
> > >
> > > The bottom line is that long-lived STags create additional
> > > memory exposure that is not present in an equivalent LLP-only
> > > application.  The fact that the ULP chose to create the
> > > exposure does not absolve RDDP of providing security measures
> > > to deal with it.  IETF requires that protocols which create
> > > security issues deal with those security issues and not palm
> > > them off on other protocols (e.g., by asserting that all
> > > security issues created by long-lived RDDP STags are ULP
> > > problems because the ULP chose to use them).
> > >
> > > I've just updated and resubmitted
> > > draft-ietf-rddp-rdma-concerns (will appear shortly as a -01
> > > version) - it contains nearly 2-year-old text in its security
> > > considerations section pointing out this memory exposure issue.
> > >
> > > 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
> > >
> >
>
> _______________________________________________
> 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: "Somesh Gupta" <[email-masked]>, [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Uri Elzur" <[email-masked]>
Date: Fri, 4 Jun 2004 18:56:23 -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: AcRKnwGRYWK9amaxRRiB555k0hCYRQAAJqow
Thread-topic: [rddp] IPsec and RDDP as a transport

Somesh

If a packet is hijacked, what will prevent the CRC match??!! So why will
the iSCSI over TCP data not be accepted? CRC has no cryptographic
value...

Uri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Somesh Gupta
Sent: Friday, June 04, 2004 6:28 PM
To: [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport

It seems that for iSCSI specifically, RDMA writes icrease the
possibility of data corruption, even with 'one-shot' STags. Consider
iSCSI over TCP, with header and data CRC. If a random TCP packet is used
to attack the connection, and the packet is accepted (large windows
etc), the CRC checks will fail and the problem detected before a
corruption occurs.

Now consider iSCSI using iSER over RDDP. iSCSI depends on RDDP for CRC
checks. An attack on the connection (out of order RDMA writes) could
place data in the write buffers and if this happens, the attack will
never be detected.

Maybe this problem is iSCSI specific only.

Somesh
> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org]On Behalf Of

> Black_David at emc.com
> Sent: Friday, June 04, 2004 5:56 PM
> To: dwight.barron at hp.com; rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
>
>
> Dwight,
>
> > Sorry to be dense, but I'm still having trouble visualizing the 
> > attack that makes DDP more vulnerable. I think it has been relegated

> > to a man in the middle attack scenario, as bogus data from the real 
> > peer always gets through, even with IPSEC enabled. The transport 
> > layer behavior is the same with/without DDP headers; a packet with 
> > an appropriate transport sequence number gets ACKed and passed 
> > upstream to be placed in a buffer. The buffer eventually gets passed

> > to the application.
>
> The difference happens here.  If the STag is 'long-lived' or 
> 'persistent' and has not been invalidated, the buffer can still be 
> modified remotely
> *after* being passed to the application.  Such modification is not
> possible in the absence of DDP.  If the STag is 'one-shot' (in
whatever
> sense that restriction is defined), the important property is that the
> application can rely on the data not being changed by remote access
> after the buffer has been passed to the application.  If the WG
> is prepared to restrict all STags to be 'one-shot' so that at the
point
> where the buffer is passed to the application, the STag used to
deliver
> the data MUST be invalid (and the RDDP implementation is responsible
> for ensuring this), then it should be possible to avoid additional
> security requirements in this area.
>
> [... snip ...]
>
> > Why is DDP being asked to implement a mandatory
> > solution that protects the transport from MITM attacks?
>
> Protection of the transport is not being required.  What is being 
> required is to be able to protect the application from exploitation of

> memory exposure enabled by RDDP functionality that is beyond that of 
> the underlying transport.  If RDDP is willing to forego that 
> additional functionality, there should no longer be a problem that 
> needs a mandatory solution.
>
> > I acknowledge
> > that DDP is in a gray area between transport and ULP, but either 
> > way, there should be consistency for all new ULPs and/or transports.

> > Where is the cry for mandatory IPSEC on SCTP?
>
> The ULP can choose how it wants to secure its data.  TLS is among the 
> possibilities and can be used over SCTP.  Beyond this, if SCTP runs 
> over IPv6, IPsec is mandatory, and I would expect that if any of the 
> IP Storage protocols (iSCSI, FCIP, iFCP) are defined over SCTP, IPsec 
> will remain mandatory for them.  In any case, IPsec is sufficient, but

> not necessary for RDDP.  A mechanism that prevents MITM misuse of RDDP

> headers is a possible alternative.
>
> > BTW - my recollection of the year old Stag security issue was 
> > related to the necessary isolations/associations of an Stag with 
> > each transport stream, a local peer security issue.
>
> That was a related, but different issue.  The ability to control STag 
> association with transport streams is still necessary.
>
> 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: Barron, Dwight [mailto:dwight.barron at hp.com]
> > Sent: Friday, June 04, 2004 7:51 PM
> > To: Black_David at emc.com; rddp at ietf.org
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> >
> >
> > Sorry to be dense, but I'm still having trouble visualizing the 
> > attack that makes DDP more vulnerable. I think it has been relegated

> > to a man in the middle attack scenario, as bogus data from the real 
> > peer always gets through, even with IPSEC enabled. The transport 
> > layer behavior is the same with/without DDP headers; a packet with 
> > an appropriate transport sequence number gets ACKed and passed 
> > upstream to be placed in a buffer. The buffer eventually gets passed

> > to the application. The only difference I see is in the buffer 
> > model, random access within the scope of an Stag vs. being put in a 
> > pre-posted buffer. Either way, the wrong data gets passed to the 
> > upper layer because of spoofing that got past the transport layer. 
> > Why is DDP being asked to implement a mandatory solution that 
> > protects the transport from MITM attacks? I acknowledge that DDP is 
> > in a gray area between transport and ULP, but either way, there 
> > should be consistency for all new ULPs and/or transports. Where is 
> > the cry for mandatory IPSEC on SCTP?
> >
> > BTW - my recollection of the year old Stag security issue was 
> > related to the necessary isolations/associations of an Stag with 
> > each transport stream, a local peer security issue.
> >
> > Regards,
> > Dwight
> >
> > > -----Original Message-----
> > > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> > > Behalf Of Black_David at emc.com
> > > Sent: Wednesday, June 02, 2004 9:32 AM
> > > To: rddp at ietf.org
> > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > >
> > >
> > > Caitlin Bestler writes:
> > >
> > > > That would only be true if the DDP header posed a new
> > > security risk,
> > > > one not faced by an equivalent LLP-only application.
> > > >
> > > > I do not believe that this analysis is shared by the WG. I 
> > > > certainly do not accept it.
> > > >
> > > > A DDP Header has no magic access to user memory. Just as any 
> > > > above-transport-header, it only has access to user memory to the

> > > > extent authorized by the ULP.
> > > >
> > > > I do not believe that you, or anyone else, has disputed that 
> > > > assertion.
> > >
> > > The latter assertion is correct, but it does not imply that a DDP 
> > > header creates no risks beyond an equivalent LLP-only application.

> > > For an LLP-only application transport buffers are always one-shot 
> > > and receive addresses in memory are determined by the receiver, 
> > > not the sender.  If the WG were prepared to limit itself to this 
> > > behavior by requiring that all STags be one-shot, then the 
> > > position that there are no new security risks should be 
> > > defensible.  The WG does not appear to be prepared to make this 
> > > restriction.
> > >
> > > More importantly, relying on the "authorized by the ULP" assertion

> > > is not acceptable to the IESG.  That approach amounts to an 
> > > instruction to ULP developers not to use long-lived STags if they 
> > > are a potential cause of security problems and also an instruction

> > > to users not to use ULPs that employ long-lived STags if 
> > > long-lived STags will cause security problems on their network(s).

> > > I've recently had to deal with another draft that tried this sort 
> > > of "don't use feature <X> if it will cause security problems" 
> > > approach; the IESG rejected that approach, and the security 
> > > considerations section of the draft had to be revised.
> > >
> > > The bottom line is that long-lived STags create additional memory 
> > > exposure that is not present in an equivalent LLP-only 
> > > application.  The fact that the ULP chose to create the exposure 
> > > does not absolve RDDP of providing security measures to deal with 
> > > it.  IETF requires that protocols which create security issues 
> > > deal with those security issues and not palm them off on other 
> > > protocols (e.g., by asserting that all security issues created by 
> > > long-lived RDDP STags are ULP problems because the ULP chose to 
> > > use them).
> > >
> > > I've just updated and resubmitted draft-ietf-rddp-rdma-concerns 
> > > (will appear shortly as a -01
> > > version) - it contains nearly 2-year-old text in its security 
> > > considerations section pointing out this memory exposure issue.
> > >
> > > 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
> > >
> >
>
> _______________________________________________
> 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

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

To: [email-masked]
Subject: [rddp] TCP offload
From: "john thodiyil" <[email-masked]>
Date: Fri, 04 Jun 2004 19:07:36 -0700 (PDT)
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]

Has anyone got any experience with TCP offload using
IXP28xxx, and also how tejas can help wrt the code required
for this purpose.

Tejas sales is claiming that they can go upto 4Gbps TOE using
50% utilization of the NPU leaving computing power for iscsi or
other Applications.

I would like to get a feel of some real numbers from experience.

Cheers
John

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

To: [email-masked], RDDP <[email-masked]>
Subject: Re: [rddp] IPsec and RDDP as a transport
From: Caitlin Bestler <[email-masked]>
Date: Sat, 5 Jun 2004 13:58:52 +0300
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 Jun 5, 2004, at 3:56 AM, Black_David at emc.com wrote:

Dwight,

Sorry to be dense, but I'm still having trouble visualizing the attack
that makes DDP more vulnerable. I think it has been relegated to a man
in the middle attack scenario, as bogus data from the real peer always
gets through, even with IPSEC enabled. The transport layer behavior is
the same with/without DDP headers; a packet with an appropriate
transport sequence number gets ACKed and passed upstream to be placed
in a buffer. The buffer eventually gets passed to the application.

    The difference happens here. If the STag is 'long-lived' or 'persistent'
    and has not been invalidated, the buffer can still be modified remotely
    *after* being passed to the application. Such modification is not
    possible in the absence of DDP. If the STag is 'one-shot' (in whatever
    sense that restriction is defined), the important property is that the
    application can rely on the data not being changed by remote access
    after the buffer has been passed to the application. If the WG
    is prepared to restrict all STags to be 'one-shot' so that at the point
    where the buffer is passed to the application, the STag used to deliver
    the data MUST be invalid (and the RDDP implementation is responsible
    for ensuring this), then it should be possible to avoid additional
    security requirements in this area. 

To summarize, the vulnerability occurs when an application trusts its
remote peer to follow the upper layer protocol regarding STag access
rather than using the local interface to enforce compliance.

Or more generally, a buffer that the application intends to use is still
exposed to update from non-authenticated DDP packets.

This is indeed a new security vulnerability, the question is how to
deal with it.

The current drafts take a "well we told you not to do that" approach.
Personally, I still find this valid. But I will concede that others might
consider this to be inadequate. But for the record I will point out that
the RDDP layer simply cannot prevent the ULP from doing stupid
things. Consider the fundamental rule that an exposed buffer is
undefined *until* the ULP infers delivery from a untagged message
or RDMA Read completion. An application that attempts to read
smoke signals in partially update RDMA accessible buffers based
only on tagged writes is very vulnerable not only to attack but to
to unstable behavior. I doubt that anyone would propose requiring
the RDDP layer to remove read access for the ULP on undelivered
buffers that it has update access to. And the vulnerability to unstable
behavior would be there even over IPsec.

David has proposed the ULP be able to rely on the availability
of IPsec authentication of DDP packets.

I believe it would be more appropriate to require the local
interface to provide adequate tools so that applications would
neither be forced to overexpose buffers, or even be prone to
do so by the defaults of the local interface. "Defaults" here
would include omission of extra steps that an application
*should* be taking, but the local interface requires additional
steps to invoke.

The proposed restriction to "one shot" STags would be one
such local interface change, but I believe it is also to extreme.

I believe we can determine what local interface requirements
would be appropriate if we examine the current gaps:

- The application can be encouraged to rely upon the remote
   peer to invalidate an STag when the transaction is done.
   If an expected remote invalidation is not performed, the
   application is typically required to invalidate the STag
   ifself. This is typically an asynchronous operation which
   would require the application to add an extra state before
   properly utilizing the buffer only after it had been secured.

-  Some applications advertise an aggregate buffer to be
   used over the span of several untagged messages. Each
   untagged message would indicate what portion of the
   advertised buffer had been used, and at the ULP layer
   pledge not to make further writes to that portion.

   Current local interfaces lack any support for enforcement
   of this model. When the portion used by the remote peer
   on each response is variably sized, there is no way for
   the Data Sink to remove one portion of a window without
   at least momentarily making the entire STag invalid.

To address these problems I would propose the following
local interface enhancements, which could be implemented
as an alternative to authenticating DDP packets with IPsec
or other equivalent transport-layer solutions:

-- The local interface MUST provide an option where a posted
    receive operation will complete in error unless the Send
    successfully invalidated an STag.

-- The local interface MUST provide an option where a posted
    receive operation will not complete until after a specified
    STag has been invalidated.

-- The local interface MUST provide an option to rebind an
    STag to a contiguous subset of its current range without
    taking it through an intermediate invalid state.

With these tools an application can easily ensure that the
DDP exposure of an STag matches the ULP required exposure.
Given the ability to easily remove a buffer's exposure *before*
using it the application will face *no* additional security vulnerability
and therefore would *not* require IPsec.

That may also be true with a subset of the above. The last one
is the only requirement that cannot be implemented by a shim
layer over current verbs, and it is admittedly of the least generality.

--
Caitlin Bestler
http://asomi.com/

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

To: "RDDP" <[email-masked]>
Subject: [rddp] RDMAP specification - no interaction with ULP specified in clause 5.2 with reception of terminate
From: "Barry Reinhold" <[email-masked]>
Date: Sat, 5 Jun 2004 09:08:48 -0400
Cc: Renato Recio <recio at us.ibm.com>
Importance: Normal
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]

I believe this is just an editorial issue:

When a terminate message is received at a remote peer, the terminate
message must be delivered to the RDMAP layer which must deliver it to
the ULP (clause 7.4). However in clause 5.2 (RDMPA Interactions with the
ULP) there is no mention of any exchange between the RDMAP layer and the
ULP upon reception of a terminate message.

Suggest adding a paragraph in clause 5.2 covering ULP interaction on
reception of terminate.

Barry Reinhold
Lamprey Networks
bbr at lampreynetworks.com
(603) 868-8411

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

To: [email-masked], [email-masked]
Subject: [rddp] RDDP-enabled iSCSI "hole"
From: [email-masked]
Date: Sun, 6 Jun 2004 16:40:58 -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]

Uri,

> I'd like to chime in on this important discussion. I'm sorry,
> but I do fail to see the "new" security hole. 

Here's a scenario where long-lived RDDP STags cause a potential
iSCSI security "hole" that can't occur with single-shot STags or
in the absence of RDDP.  I'm going one step beyond Somesh and
assuming that the iSCSI data CRC is still being used with RDDP
(in contrast to Somesh's assumption that the RDDP CRC(s)
replace(s) the iSCSI data CRC - that assumption opens the "hole"
wider because the RDDP CRC is checked earlier):

(1) An STag is used to transfer data for an iSCSI write.
	The STag is left valid after the data is transfer so
	that the initiator and target can reuse this buffer
	and its STag for the next write (a fairly obvious and
	desirable optimization).
(2) The iSCSI target checks the received data against the
	iSCSI CRC.  The check succeeds, so the target code
	requests a local disk write operation from the buffer
	that is still exposed via the STag
(3) Before the write operation takes place, a TCP packet from
	the MITM attacker (e.g., connection hijacker) shows up
	and uses the STag to overwrite part of the write buffer.

At this point, there is corrupt data headed for the disk.  In
the absence of long-lived STags, the TCP packet at step (3)
gets rejected by RDDP.  In the absence of RDDP, that TCP packet
gets through, but won't corrupt the iSCSI write data.  Hence
RDDP's long-lived STags have opened up a new security problem.

This problem appears to be generic to any reuse of a write
buffer and its associated STag.  If an application protocol
uses RDDP to transfer data that is actually interpreted by 
the application protocol, there are versions of this attack
that target protocol functionality if the implementation
contains code that assumes the contents of the receive
buffer don't change.

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 Uri Elzur
> Sent: Friday, June 04, 2004 9:56 PM
> To: Somesh Gupta; rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> Somesh
> 
> If a packet is hijacked, what will prevent the CRC match??!! 
> So why will
> the iSCSI over TCP data not be accepted? CRC has no cryptographic
> value...
> 
> Uri
> 
> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of
> Somesh Gupta
> Sent: Friday, June 04, 2004 6:28 PM
> To: rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> It seems that for iSCSI specifically, RDMA writes icrease the
> possibility of data corruption, even with 'one-shot' STags. Consider
> iSCSI over TCP, with header and data CRC. If a random TCP 
> packet is used
> to attack the connection, and the packet is accepted (large windows
> etc), the CRC checks will fail and the problem detected before a
> corruption occurs.
> 
> Now consider iSCSI using iSER over RDDP. iSCSI depends on RDDP for CRC
> checks. An attack on the connection (out of order RDMA writes) could
> place data in the write buffers and if this happens, the attack will
> never be detected.
> 
> Maybe this problem is iSCSI specific only.
> 
> Somesh

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

To: [email-masked], [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport
From: [email-masked]
Date: Sun, 6 Jun 2004 17:36:20 -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]

Several clarifying comments:

> To summarize, the vulnerability occurs when an application trusts its
> remote peer to follow the upper layer protocol regarding STag access
> rather than using the local interface to enforce compliance.
> 
> Or more generally, a buffer that the application intends to use is
> still exposed to update from non-authenticated DDP packets.

The latter is the better statement of the vulnerability, as it includes
man-in-the-middle traffic injection, e.g., via a connection hijack.

> David has proposed the ULP be able to rely on the availability
> of IPsec authentication of DDP packets.

Not exactly ... this was originally proposed in the RDDP security
draft, although with a "SHOULD implement" requirement that would have
to be changed to "MUST implement" in order to obtain IESG approval.
This was discussed in Seoul, which is why the original thread on
this topic carries the issue (4) tag from Seoul.

To the extent that I've pointed out that the IESG is very serious
about mandatory-to-implement security, I guess it's fair to tag me
with some responsibility for this proposal, BUT ...

... I have also posted that while IPsec is sufficient to deal with
this problem, it's more than is necessary.  It should be possible
to design a mechanism that only authenticates the RDDP headers via
some sort of keyed cryptographic integrity check.  I would ask
everyone to please stop looking for conspiracy theories about
how this is somehow part of a grand plot to require IPsec everywhere.

Despite this, I do think local functionality/interface modifications
(e.g., restrict all STags to be 'one-shot' and require implementations
to enforce this) are the preferred approach because they block not only
the man-in-the-middle but also the misbehaved or malicious client;
this is quite useful for protocols like NFS that generally cannot
place complete trust in clients.  I probably should have said this
more strenuously about a dozen posts ago.

Caitlin's proposal below appears to be headed in a productive direction,
but at the end of the day, we have to abide by the IESG's "if you broke
it, provide tools to fix it" approach to mandatory-to-implement security
- if the WG wants its specifications to provide long-lived STag
functionality for use by protocols that are prepared to assume the
requisite high degree of trust among the communicating peers, the WG
is obligated to also provide the mandatory-to-implement security that
such protocols can use to prevent man-in-the-middle attacks on/via that
long-lived STag functionality.  At the moment, I'm not certain whether
Caitlin's proposal is sufficient in this regard.

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: Saturday, June 05, 2004 6:59 AM
> To: Black_David at emc.com; RDDP
> Subject: Re: [rddp] IPsec and RDDP as a transport
> 
> 
> 
> On Jun 5, 2004, at 3:56 AM, Black_David at emc.com wrote:
> 
> > Dwight,
> >
> >> Sorry to be dense, but I'm still having trouble visualizing the attack
> >> that makes DDP more vulnerable. I think it has been relegated to a man
> >> in the middle attack scenario, as bogus data from the real peer always
> >> gets through, even with IPSEC enabled. The transport layer behavior is
> >> the same with/without DDP headers; a packet with an appropriate
> >> transport sequence number gets ACKed and passed upstream to be placed
> >> in a buffer. The buffer eventually gets passed to the application.
> >
> > The difference happens here.  If the STag is 'long-lived' or
'persistent'
> > and has not been invalidated, the buffer can still be modified remotely
> > *after* being passed to the application.  Such modification is not
> > possible in the absence of DDP.  If the STag is 'one-shot' (in whatever
> > sense that restriction is defined), the important property is that the
> > application can rely on the data not being changed by remote access
> > after the buffer has been passed to the application.  If the WG
> > is prepared to restrict all STags to be 'one-shot' so that at the point
> > where the buffer is passed to the application, the STag used to deliver
> > the data MUST be invalid (and the RDDP implementation is responsible
> > for ensuring this), then it should be possible to avoid additional
> > security requirements in this area.
> 
> To summarize, the vulnerability occurs when an application trusts its
> remote peer to follow the upper layer protocol regarding STag access
> rather than using the local interface to enforce compliance.
> 
> Or more generally, a buffer that the application intends to use is still
> exposed to update from non-authenticated DDP packets.
> 
> This is indeed a new security vulnerability, the question is how to
> deal with it.
> 
> The current drafts take a "well we told you not to do that" approach.
> Personally, I still find this valid. But I will concede that others 
> might consider this to be inadequate. But for the record I will 
> point out that the RDDP layer simply cannot prevent the ULP from
> doing stupid things. Consider the fundamental rule that an exposed
> buffer is undefined *until* the ULP infers delivery from a untagged
> message or RDMA Read completion. An application that attempts to read
> smoke signals in partially update RDMA accessible buffers based
> only on tagged writes is very vulnerable not only to attack but to
> to unstable behavior. I doubt that anyone would propose requiring
> the RDDP layer to remove read access for the ULP on undelivered
> buffers that it has update access to. And the vulnerability 
> to unstable behavior would be there even over IPsec.
> 
> David has proposed the ULP be able to rely on the availability
> of IPsec authentication of DDP packets.
> 
> I believe it would be more appropriate to require the local
> interface to provide adequate tools so that applications would
> neither be forced to overexpose buffers, or even be prone to
> do so by the defaults of the local interface. "Defaults" here
> would include omission of extra steps that an application
> *should* be taking, but the local interface requires additional
> steps to invoke.
> 
> The proposed restriction to "one shot" STags would be one
> such local interface change, but I believe it is also to extreme.
> 
> I believe we can determine what local interface requirements
> would be appropriate if we examine the current gaps:
> 
> - The application can be encouraged to rely upon the remote
>     peer to invalidate an STag when the transaction is done.
>     If an expected remote invalidation is not performed, the
>     application is typically required to invalidate the STag
>     ifself. This is typically an asynchronous operation which
>     would require the application to add an extra state before
>     properly utilizing the buffer only after it had been secured.
> 
> -  Some applications advertise an aggregate buffer to be
>     used over the span of several untagged messages. Each
>     untagged message would indicate what portion of the
>     advertised buffer had been used, and at the ULP layer
>     pledge not to make further writes to that portion.
> 
>     Current local interfaces lack any support for enforcement
>     of this model. When the portion used by the remote peer
>     on each response is variably sized, there is no way for
>     the Data Sink to remove one portion of a window without
>     at least momentarily making the entire STag invalid.
> 
> To address these problems I would propose the following
> local interface enhancements, which could be implemented
> as an alternative to authenticating DDP packets with IPsec
> or other equivalent transport-layer solutions:
> 
> -- The local interface MUST provide an option where a posted
>      receive operation will complete in error unless the Send
>      successfully invalidated an STag.
> 
> -- The local interface MUST provide an option where a posted
>      receive operation will not complete until after a specified
>      STag has been invalidated.
> 
> -- The local interface MUST provide an option to rebind an
>      STag to a contiguous subset of its current range without
>      taking it through an intermediate invalid state.
> 
> With these tools an application can easily ensure that the
> DDP exposure of an STag matches the ULP required exposure.
> Given the ability to easily remove a buffer's exposure *before*
> using it the application will face *no* additional security
> vulnerability and therefore would *not* require IPsec.
> 
> That may also be true with a subset of the above. The last one
> is the only requirement that cannot be implemented by a shim
> layer over current verbs, and it is admittedly of the least 
> generality.
> 
> 
> 
> 
> --
> Caitlin Bestler
> http://asomi.com/
> 

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

To: [email-masked], [email-masked]
Subject: RE: [rddp] TCP offload - DO NOT RESPOND
From: [email-masked]
Date: Sun, 6 Jun 2004 17:52:55 -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]

John,

Your message solicits information on a specific vendor's
product; this is not appropriate for the IETF RDDP Working
Group mailing list.  This is a protocol design list - please
take this sort of inquiry elsewhere.

Thanks,
--David (IETF RDDP WG chair)
----------------------------------------------------
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 john thodiyil
> Sent: Friday, June 04, 2004 10:08 PM
> To: rddp at ietf.org
> Subject: [rddp] TCP offload
> 
> 
> 
> Has anyone got any experience with TCP offload using
> IXP28xxx, and also how tejas can help wrt the code required
> for this purpose.
> 
> Tejas sales is claiming that they can go upto 4Gbps TOE using
> 50% utilization of the NPU leaving computing power for iscsi or
> other Applications.
> 
> I would like to get a feel of some real numbers from experience.
> 
> Cheers
> John
> 
> _______________________________________________
> 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]
Subject: Re: [rddp] IPsec and RDDP as a transport
From: "Mallikarjun C." <[email-masked]>
Date: Sun, 06 Jun 2004 18:35:10 -0700
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]
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

I view the iSCSI/iSER/iWARP vulnerability qualitatively no different from that of iSCSI+sync-and-steering/TCP, under a given set of operating assumptions (IPSec, threat assumptions, attacker smarts, "tag" recycling frequency etc.). In the former, the placement is done based on STags and in the latter, the placement is done based on ITTs. In the former, the "tag" is the STag and in the latter, it's the ITT. Neither can provide absolute guarantees.

More description of the exact scenario of concern/vulnerability will help me see the problem. Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

Somesh Gupta wrote:

It seems that for iSCSI specifically, RDMA writes icrease the possibility
of data corruption, even with 'one-shot' STags. Consider iSCSI over TCP,
with header and data CRC. If a random TCP packet is used to attack the
connection, and the packet is accepted (large windows etc), the CRC
checks will fail and the problem detected before a corruption occurs.

Now consider iSCSI using iSER over RDDP. iSCSI depends on RDDP for
CRC checks. An attack on the connection (out of order RDMA writes)
could place data in the write buffers and if this happens, the attack
will never be detected.

Maybe this problem is iSCSI specific only.

Somesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Black_David at emc.com
Sent: Friday, June 04, 2004 5:56 PM
To: [email-masked]; [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport

Dwight,

Sorry to be dense, but I'm still having trouble visualizing the attack
that makes DDP more vulnerable. I think it has been relegated to a man
in the middle attack scenario, as bogus data from the real peer always
gets through, even with IPSEC enabled. The transport layer behavior is
the same with/without DDP headers; a packet with an appropriate
transport sequence number gets ACKed and passed upstream to be placed
in a buffer. The buffer eventually gets passed to the application.

The difference happens here.  If the STag is 'long-lived' or 'persistent'
and has not been invalidated, the buffer can still be modified remotely
*after* being passed to the application.  Such modification is not
possible in the absence of DDP.  If the STag is 'one-shot' (in whatever
sense that restriction is defined), the important property is that the
application can rely on the data not being changed by remote access
after the buffer has been passed to the application.  If the WG
is prepared to restrict all STags to be 'one-shot' so that at the point
where the buffer is passed to the application, the STag used to deliver
the data MUST be invalid (and the RDDP implementation is responsible
for ensuring this), then it should be possible to avoid additional
security requirements in this area.

[... snip ...]

Why is DDP being asked to implement a mandatory
solution that protects the transport from MITM attacks?

Protection of the transport is not being required.  What is being
required is to be able to protect the application from exploitation of
memory exposure enabled by RDDP functionality that is beyond that of
the underlying transport.  If RDDP is willing to forego that additional
functionality, there should no longer be a problem that needs a
mandatory solution.

I acknowledge
that DDP is in a gray area between transport and ULP, but either way,
there should be consistency for all new ULPs and/or transports. Where is
the cry for mandatory IPSEC on SCTP?

The ULP can choose how it wants to secure its data.  TLS is among the
possibilities and can be used over SCTP.  Beyond this, if SCTP runs over
IPv6, IPsec is mandatory, and I would expect that if any of the IP
Storage protocols (iSCSI, FCIP, iFCP) are defined over SCTP, IPsec
will remain mandatory for them.  In any case, IPsec is sufficient,
but not necessary for RDDP.  A mechanism that prevents MITM misuse
of RDDP headers is a possible alternative.

BTW - my recollection of the year old Stag security issue was related to
the necessary isolations/associations of an Stag with each transport
stream, a local peer security issue.

That was a related, but different issue.  The ability to control
STag association with transport streams is still necessary.

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: Barron, Dwight [mailto:[email-masked]]
Sent: Friday, June 04, 2004 7:51 PM
To: [email-masked]; [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport

Sorry to be dense, but I'm still having trouble visualizing the attack
that makes DDP more vulnerable. I think it has been relegated to a man
in the middle attack scenario, as bogus data from the real peer always
gets through, even with IPSEC enabled. The transport layer behavior is
the same with/without DDP headers; a packet with an appropriate
transport sequence number gets ACKed and passed upstream to be placed in
a buffer. The buffer eventually gets passed to the application. The only
difference I see is in the buffer model, random access within the scope
of an Stag vs. being put in a pre-posted buffer. Either way, the wrong
data gets passed to the upper layer because of spoofing that got past
the transport layer. Why is DDP being asked to implement a mandatory
solution that protects the transport from MITM attacks? I acknowledge
that DDP is in a gray area between transport and ULP, but either way,
there should be consistency for all new ULPs and/or transports. Where is
the cry for mandatory IPSEC on SCTP?

BTW - my recollection of the year old Stag security issue was related to
the necessary isolations/associations of an Stag with each transport
stream, a local peer security issue.

Regards,
Dwight

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Black_David at emc.com
Sent: Wednesday, June 02, 2004 9:32 AM
To: [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport

Caitlin Bestler writes:

                    That would only be true if the DDP header posed a new 

security risk,

one not faced by an equivalent LLP-only application.

I do not believe that this analysis is shared by the WG.
I certainly do not accept it.

A DDP Header has no magic access to user memory. Just as any
above-transport-header, it only has access to user memory to the
extent authorized by the ULP.

I do not believe that you, or anyone else, has disputed that
assertion.

The latter assertion is correct, but it does not imply that
a DDP header creates no risks beyond an equivalent LLP-only
application.  For an LLP-only application transport buffers
are always one-shot and receive addresses in memory are
determined by the receiver, not the sender.  If the WG were
prepared to limit itself to this behavior by requiring that
all STags be one-shot, then the position that there are no
new security risks should be defensible.  The WG does not
appear to be prepared to make this restriction.

More importantly, relying on the "authorized by the ULP"
assertion is not acceptable to the IESG.  That approach
amounts to an instruction to ULP developers not to use
long-lived STags if they are a potential cause of security
problems and also an instruction to users not to use ULPs
that employ long-lived STags if long-lived STags will cause
security problems on their network(s).  I've recently had to
deal with another draft that tried this sort of "don't use
feature <X> if it will cause security problems" approach; the
IESG rejected that approach, and the security considerations
section of the draft had to be revised.

The bottom line is that long-lived STags create additional
memory exposure that is not present in an equivalent LLP-only
application.  The fact that the ULP chose to create the
exposure does not absolve RDDP of providing security measures
to deal with it.  IETF requires that protocols which create
security issues deal with those security issues and not palm
them off on other protocols (e.g., by asserting that all
security issues created by long-lived RDDP STags are ULP
problems because the ULP chose to use them).

I've just updated and resubmitted
draft-ietf-rddp-rdma-concerns (will appear shortly as a -01
version) - it contains nearly 2-year-old text in its security
considerations section pointing out this memory exposure issue.

Thanks,
--David

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

To: <[email-masked]>
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Barry Reinhold" <[email-masked]>
Date: Mon, 7 Jun 2004 09:58:06 -0400
Importance: Normal
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>
Sender: [email-masked]

I don't think I fully understand the problem yet - 
So for a short summary we are addressing vulnerability when:

1. IPsec is not in use
2. There is a MITM attack (hijacked TCP connection)
3. A "long lived" STag (one that is not invalidated after first use) is
being used.

And this vulnerability is distinct from the case where:
1. IPsec is not in use
2. There is a MITM attack (hijacked TCP connection)
3. A "short lived" STag is being used.

Two questions:

1. What exactly is the MITM allowed to do? Obviously they can see the
traffic flow and they can spoof a packet in the context of a TCP
connection such that the receiver is happy with that. If they can do
those two things, I assume they can also drop and source, selectively,
packets being sent on the connection in either direction. Is this
correct?

2. The "badness" that we are looking at is undetected corrupt data on
disk. Is this correct? 

If this is the case, the points that I'm fuzzy on are:

1. Why does invalidating a STag after first use make a difference? It
would seem like the vulnerability is introduced when the ULP advertised
the STag.

2. I also don't understand why the STag, which is an identifier to a
buffer, is distinct from the ITT which also ends up being an identifier
to a buffer. One may be under the control of a protocol layer, but how
does this change the corruption problem?

3. The discussion seems to hinge on the idea of reusability of the
buffer. I can see this "opening the vulnerability" for a longer period
of time, but I don't see how it is a distinct new corruption problem.

If I have a smart MITM and track the state of both endpoints by
monitoring the TCP connection, when an interesting iSCSI read request
comes with a given ITT, it sure seems like I could screw this up by (1)
handling the complete IO myself, or (2) changing the data in the read
response PDU. (Lots of work to do in there to keep and present
consistent state to both endpoints -- but nothing that is "not doable"
from a cryptographic point of view.)

This would appear to cause undetected data corruption in an iSCSI
transfer. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Black_David at emc.com
Sent: Sunday, June 06, 2004 4:36 PM
To: [email-masked]; [email-masked]
Subject: RE: [rddp] IPsec and RDDP as a transport

Several clarifying comments:

> To summarize, the vulnerability occurs when an application trusts its
> remote peer to follow the upper layer protocol regarding STag access
> rather than using the local interface to enforce compliance.
> 
> Or more generally, a buffer that the application intends to use is
> still exposed to update from non-authenticated DDP packets.

The latter is the better statement of the vulnerability, as it includes
man-in-the-middle traffic injection, e.g., via a connection hijack.

> David has proposed the ULP be able to rely on the availability
> of IPsec authentication of DDP packets.

Not exactly ... this was originally proposed in the RDDP security
draft, although with a "SHOULD implement" requirement that would have
to be changed to "MUST implement" in order to obtain IESG approval.
This was discussed in Seoul, which is why the original thread on
this topic carries the issue (4) tag from Seoul.

To the extent that I've pointed out that the IESG is very serious
about mandatory-to-implement security, I guess it's fair to tag me
with some responsibility for this proposal, BUT ...

... I have also posted that while IPsec is sufficient to deal with
this problem, it's more than is necessary.  It should be possible
to design a mechanism that only authenticates the RDDP headers via
some sort of keyed cryptographic integrity check.  I would ask
everyone to please stop looking for conspiracy theories about
how this is somehow part of a grand plot to require IPsec everywhere.

Despite this, I do think local functionality/interface modifications
(e.g., restrict all STags to be 'one-shot' and require implementations
to enforce this) are the preferred approach because they block not only
the man-in-the-middle but also the misbehaved or malicious client;
this is quite useful for protocols like NFS that generally cannot
place complete trust in clients.  I probably should have said this
more strenuously about a dozen posts ago.

Caitlin's proposal below appears to be headed in a productive direction,
but at the end of the day, we have to abide by the IESG's "if you broke
it, provide tools to fix it" approach to mandatory-to-implement security
- if the WG wants its specifications to provide long-lived STag
functionality for use by protocols that are prepared to assume the
requisite high degree of trust among the communicating peers, the WG
is obligated to also provide the mandatory-to-implement security that
such protocols can use to prevent man-in-the-middle attacks on/via that
long-lived STag functionality.  At the moment, I'm not certain whether
Caitlin's proposal is sufficient in this regard.

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: Saturday, June 05, 2004 6:59 AM
> To: Black_David at emc.com; RDDP
> Subject: Re: [rddp] IPsec and RDDP as a transport
> 
> 
> 
> On Jun 5, 2004, at 3:56 AM, Black_David at emc.com wrote:
> 
> > Dwight,
> >
> >> Sorry to be dense, but I'm still having trouble visualizing the
attack
> >> that makes DDP more vulnerable. I think it has been relegated to a
man
> >> in the middle attack scenario, as bogus data from the real peer
always
> >> gets through, even with IPSEC enabled. The transport layer behavior
is
> >> the same with/without DDP headers; a packet with an appropriate
> >> transport sequence number gets ACKed and passed upstream to be
placed
> >> in a buffer. The buffer eventually gets passed to the application.
> >
> > The difference happens here.  If the STag is 'long-lived' or
'persistent'
> > and has not been invalidated, the buffer can still be modified
remotely
> > *after* being passed to the application.  Such modification is not
> > possible in the absence of DDP.  If the STag is 'one-shot' (in
whatever
> > sense that restriction is defined), the important property is that
the
> > application can rely on the data not being changed by remote access
> > after the buffer has been passed to the application.  If the WG
> > is prepared to restrict all STags to be 'one-shot' so that at the
point
> > where the buffer is passed to the application, the STag used to
deliver
> > the data MUST be invalid (and the RDDP implementation is responsible
> > for ensuring this), then it should be possible to avoid additional
> > security requirements in this area.
> 
> To summarize, the vulnerability occurs when an application trusts its
> remote peer to follow the upper layer protocol regarding STag access
> rather than using the local interface to enforce compliance.
> 
> Or more generally, a buffer that the application intends to use is
still
> exposed to update from non-authenticated DDP packets.
> 
> This is indeed a new security vulnerability, the question is how to
> deal with it.
> 
> The current drafts take a "well we told you not to do that" approach.
> Personally, I still find this valid. But I will concede that others 
> might consider this to be inadequate. But for the record I will 
> point out that the RDDP layer simply cannot prevent the ULP from
> doing stupid things. Consider the fundamental rule that an exposed
> buffer is undefined *until* the ULP infers delivery from a untagged
> message or RDMA Read completion. An application that attempts to read
> smoke signals in partially update RDMA accessible buffers based
> only on tagged writes is very vulnerable not only to attack but to
> to unstable behavior. I doubt that anyone would propose requiring
> the RDDP layer to remove read access for the ULP on undelivered
> buffers that it has update access to. And the vulnerability 
> to unstable behavior would be there even over IPsec.
> 
> David has proposed the ULP be able to rely on the availability
> of IPsec authentication of DDP packets.
> 
> I believe it would be more appropriate to require the local
> interface to provide adequate tools so that applications would
> neither be forced to overexpose buffers, or even be prone to
> do so by the defaults of the local interface. "Defaults" here
> would include omission of extra steps that an application
> *should* be taking, but the local interface requires additional
> steps to invoke.
> 
> The proposed restriction to "one shot" STags would be one
> such local interface change, but I believe it is also to extreme.
> 
> I believe we can determine what local interface requirements
> would be appropriate if we examine the current gaps:
> 
> - The application can be encouraged to rely upon the remote
>     peer to invalidate an STag when the transaction is done.
>     If an expected remote invalidation is not performed, the
>     application is typically required to invalidate the STag
>     ifself. This is typically an asynchronous operation which
>     would require the application to add an extra state before
>     properly utilizing the buffer only after it had been secured.
> 
> -  Some applications advertise an aggregate buffer to be
>     used over the span of several untagged messages. Each
>     untagged message would indicate what portion of the
>     advertised buffer had been used, and at the ULP layer
>     pledge not to make further writes to that portion.
> 
>     Current local interfaces lack any support for enforcement
>     of this model. When the portion used by the remote peer
>     on each response is variably sized, there is no way for
>     the Data Sink to remove one portion of a window without
>     at least momentarily making the entire STag invalid.
> 
> To address these problems I would propose the following
> local interface enhancements, which could be implemented
> as an alternative to authenticating DDP packets with IPsec
> or other equivalent transport-layer solutions:
> 
> -- The local interface MUST provide an option where a posted
>      receive operation will complete in error unless the Send
>      successfully invalidated an STag.
> 
> -- The local interface MUST provide an option where a posted
>      receive operation will not complete until after a specified
>      STag has been invalidated.
> 
> -- The local interface MUST provide an option to rebind an
>      STag to a contiguous subset of its current range without
>      taking it through an intermediate invalid state.
> 
> With these tools an application can easily ensure that the
> DDP exposure of an STag matches the ULP required exposure.
> Given the ability to easily remove a buffer's exposure *before*
> using it the application will face *no* additional security
> vulnerability and therefore would *not* require IPsec.
> 
> That may also be true with a subset of the above. The last one
> is the only requirement that cannot be implemented by a shim
> layer over current verbs, and it is admittedly of the least 
> generality.
> 
> 
> 
> 
> --
> Caitlin Bestler
> http://asomi.com/
> 

_______________________________________________
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]
Subject: RE: [rddp] TCP offload - DO NOT RESPOND
From: "john thodiyil" <[email-masked]>
Date: Mon, 07 Jun 2004 07:55:29 -0700 (PDT)
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]

My appologies!!

On Sun, 6 Jun 2004 17:52:55 -0400 , Black_David at emc.com wrote:

> 
> John,
> 
> Your message solicits information on a specific vendor's
> product; this is not appropriate for the IETF RDDP Working
> Group mailing list.  This is a protocol design list - please
> take this sort of inquiry elsewhere.
> 
> Thanks,
> --David (IETF RDDP WG chair)
> ----------------------------------------------------
> 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 john thodiyil
> > Sent: Friday, June 04, 2004 10:08 PM
> > To: rddp at ietf.org
> > Subject: [rddp] TCP offload
> > 
> > 
> > 
> > Has anyone got any experience with TCP offload using
> > IXP28xxx, and also how tejas can help wrt the code required
> > for this purpose.
> > 
> > Tejas sales is claiming that they can go upto 4Gbps TOE using
> > 50% utilization of the NPU leaving computing power for iscsi or
> > other Applications.
> > 
> > I would like to get a feel of some real numbers from experience.
> > 
> > Cheers
> > John
> > 
> > _______________________________________________
> > 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: "Barry Reinhold" <[email-masked]>
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 7 Jun 2004 10:31:57 -0500 (CDT)
Cc: rddp at ietf.org
Importance: Normal
In-reply-to: <000401c44c97$787913b0$467fa8c0@i8600>
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]> <000401c44c97$787913b0$467fa8c0@i8600>
Sender: [email-masked]
User-agent: SquirrelMail/1.4.2

Barry Reinhold said:
> I don't think I fully understand the problem yet -
> So for a short summary we are addressing vulnerability when:
>
> 1. IPsec is not in use
> 2. There is a MITM attack (hijacked TCP connection)
> 3. A "long lived" STag (one that is not invalidated after first use) is
> being used.
>

A vulnerability when:

1) There can be unauthenticated DDP Segments (i.e. whenever IPsec
     or an equivalent is not in use, except when the entire network
     is secured against spoofing by controlled switches/etc.)
2)  The Data Sink ULP has received an RDMA Written buffer (that is,
     per the Upper Layer Protocol it understood the completion of
     an untagged message to indicate that said buffer had been written)
     but the buffer is still exposed.

Why would an applicatioh leave a buffer that is "closed" under
the rules of the ULP "open" as far as RDDP is concerned?

a) It trusts its peer and has neglected to consider the possiblity
    of a MITM attack, or even that its peer could have bugs.
b) Properly closing the window may require extra steps with
    the local interface.

The security draft already details the required tools for an application
to protect itself. I do not believe that there is any dispute that these
tools are adequate, merely that they may encourage developers to
take insecure shortcuts.

A strong argument can be made that a local interface that leads
a novice user to the insecure option is a security vulnerability.
For example, most people would condemn an email server that
on installation was configured as an open relay. Merely telling
the user that they should configure their relay policy is not enough,
an open relay is a configuration that should only be enabled by
a sophisticated user who understands the implications of an
open relay.

Essentially, persistent STags are a very poor default, and are
quite likely to lead a novice user into inadvertently leaving
security vulnerabilities in their system.

> And this vulnerability is distinct from the case where:
> 1. IPsec is not in use
> 2. There is a MITM attack (hijacked TCP connection)
> 3. A "short lived" STag is being used.
>

The "short lived" STag is not more secure because it is
short lived, but rather because it is closed at the same
time that the ULP considers the buffer to be closed.

An application that examines an RDMA Writable buffer
while it is "open" according to the Upper Layer Protocol
is not only vulnerable to malicious attack, it is quite likely
unstable and vulnerable to vendor variations and numerous
timing glitches.

But if the application only examines the buffer *after*
both the ULP *and* STag window have been closed is
safe. To be precise: it is as safe as it would have been
running over the LLP directly.

RDDP is not responsible for making ULPs be secure,
but it is responsible for not introducing *new*
security vulnerabilities.

> Two questions:
>
> 1. What exactly is the MITM allowed to do? Obviously they can see the
> traffic flow and they can spoof a packet in the context of a TCP
> connection such that the receiver is happy with that. If they can do
> those two things, I assume they can also drop and source, selectively,
> packets being sent on the connection in either direction. Is this
> correct?
>

All existing LLP attacks (TCP or SCTP) still apply. The application
designer must evaluaate their vulnerability to such attacks, and
the consequences should they be compromised. Certain applications
will rightfully decide that they should only be run over secure connections,
independently of whether RDDP is in use or not.

> 2. The "badness" that we are looking at is undetected corrupt data on
> disk. Is this correct?
>

The "badness" is unauthorized data access that the application is
no longer in a position to detect because RDDP has relieved it of
handling data placement.

The solution is to ensure that applications have reasonalbe tools
to control access to their buffers so that they are never forced to,
or even encouraged to, examine a buffer that is still RDDP exposed
(in the absence of packet-authentication).

> If this is the case, the points that I'm fuzzy on are:
>
> 1. Why does invalidating a STag after first use make a difference? It
> would seem like the vulnerability is introduced when the ULP advertised
> the STag.
>

Ensuring that an STag's exposure matches the ULP defined exposure
is the goal. If the ULP considers a buffer to be "open" for 33 messages,
then there is nothing run with it being open at the RDDP level for 33
messages.

> 2. I also don't understand why the STag, which is an identifier to a
> buffer, is distinct from the ITT which also ends up being an identifier
> to a buffer. One may be under the control of a protocol layer, but how
> does this change the corruption problem?
>

The ITT is a ULP create, therefore I would assume its exposure is
properly controlled by the ULP. If that isn't the case, that should
be discussed in IPS, not here.

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

To: "Uri Elzur" <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Somesh Gupta" <[email-masked]>
Date: Mon, 7 Jun 2004 10:57:52 -0700
Importance: Normal
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>
Sender: [email-masked]

Uri,

With iSCSI, there is a delineation process on the byte
stream before processing the data. In other words,
if one packet or sequence of packets is injected by
the rogue, it will be detected because the delineation
process or CRC check or both will fail. There is one
exception to this which is if the attacker can also
predict the location of PDU header or data boundary in the byte
stream at the same time.

However RDMA writes offers no such protection. Out of
order RDMA writes can be completed, corrupting data.
Even when the holes are filled and if there are mechanisms
to detect that there was mis-alignment of data,
the user is still Out of luck because the data may already
have been consumed.

Somesh

> -----Original Message-----
> From: Uri Elzur [mailto:uri at broadcom.com]
> Sent: Friday, June 04, 2004 6:56 PM
> To: Somesh Gupta; rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> Somesh
> 
> If a packet is hijacked, what will prevent the CRC match??!! So why will
> the iSCSI over TCP data not be accepted? CRC has no cryptographic
> value...
> 
> Uri
> 
> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf Of
> Somesh Gupta
> Sent: Friday, June 04, 2004 6:28 PM
> To: rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> It seems that for iSCSI specifically, RDMA writes icrease the
> possibility of data corruption, even with 'one-shot' STags. Consider
> iSCSI over TCP, with header and data CRC. If a random TCP packet is used
> to attack the connection, and the packet is accepted (large windows
> etc), the CRC checks will fail and the problem detected before a
> corruption occurs.
> 
> Now consider iSCSI using iSER over RDDP. iSCSI depends on RDDP for CRC
> checks. An attack on the connection (out of order RDMA writes) could
> place data in the write buffers and if this happens, the attack will
> never be detected.
> 
> Maybe this problem is iSCSI specific only.
> 
> Somesh
> > -----Original Message-----
> > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org]On Behalf Of
> 
> > Black_David at emc.com
> > Sent: Friday, June 04, 2004 5:56 PM
> > To: dwight.barron at hp.com; rddp at ietf.org
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> >
> >
> > Dwight,
> >
> > > Sorry to be dense, but I'm still having trouble visualizing the 
> > > attack that makes DDP more vulnerable. I think it has been relegated
> 
> > > to a man in the middle attack scenario, as bogus data from the real 
> > > peer always gets through, even with IPSEC enabled. The transport 
> > > layer behavior is the same with/without DDP headers; a packet with 
> > > an appropriate transport sequence number gets ACKed and passed 
> > > upstream to be placed in a buffer. The buffer eventually gets passed
> 
> > > to the application.
> >
> > The difference happens here.  If the STag is 'long-lived' or 
> > 'persistent' and has not been invalidated, the buffer can still be 
> > modified remotely
> > *after* being passed to the application.  Such modification is not
> > possible in the absence of DDP.  If the STag is 'one-shot' (in
> whatever
> > sense that restriction is defined), the important property is that the
> > application can rely on the data not being changed by remote access
> > after the buffer has been passed to the application.  If the WG
> > is prepared to restrict all STags to be 'one-shot' so that at the
> point
> > where the buffer is passed to the application, the STag used to
> deliver
> > the data MUST be invalid (and the RDDP implementation is responsible
> > for ensuring this), then it should be possible to avoid additional
> > security requirements in this area.
> >
> > [... snip ...]
> >
> > > Why is DDP being asked to implement a mandatory
> > > solution that protects the transport from MITM attacks?
> >
> > Protection of the transport is not being required.  What is being 
> > required is to be able to protect the application from exploitation of
> 
> > memory exposure enabled by RDDP functionality that is beyond that of 
> > the underlying transport.  If RDDP is willing to forego that 
> > additional functionality, there should no longer be a problem that 
> > needs a mandatory solution.
> >
> > > I acknowledge
> > > that DDP is in a gray area between transport and ULP, but either 
> > > way, there should be consistency for all new ULPs and/or transports.
> 
> > > Where is the cry for mandatory IPSEC on SCTP?
> >
> > The ULP can choose how it wants to secure its data.  TLS is among the 
> > possibilities and can be used over SCTP.  Beyond this, if SCTP runs 
> > over IPv6, IPsec is mandatory, and I would expect that if any of the 
> > IP Storage protocols (iSCSI, FCIP, iFCP) are defined over SCTP, IPsec 
> > will remain mandatory for them.  In any case, IPsec is sufficient, but
> 
> > not necessary for RDDP.  A mechanism that prevents MITM misuse of RDDP
> 
> > headers is a possible alternative.
> >
> > > BTW - my recollection of the year old Stag security issue was 
> > > related to the necessary isolations/associations of an Stag with 
> > > each transport stream, a local peer security issue.
> >
> > That was a related, but different issue.  The ability to control STag 
> > association with transport streams is still necessary.
> >
> > 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: Barron, Dwight [mailto:dwight.barron at hp.com]
> > > Sent: Friday, June 04, 2004 7:51 PM
> > > To: Black_David at emc.com; rddp at ietf.org
> > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > >
> > >
> > > Sorry to be dense, but I'm still having trouble visualizing the 
> > > attack that makes DDP more vulnerable. I think it has been relegated
> 
> > > to a man in the middle attack scenario, as bogus data from the real 
> > > peer always gets through, even with IPSEC enabled. The transport 
> > > layer behavior is the same with/without DDP headers; a packet with 
> > > an appropriate transport sequence number gets ACKed and passed 
> > > upstream to be placed in a buffer. The buffer eventually gets passed
> 
> > > to the application. The only difference I see is in the buffer 
> > > model, random access within the scope of an Stag vs. being put in a 
> > > pre-posted buffer. Either way, the wrong data gets passed to the 
> > > upper layer because of spoofing that got past the transport layer. 
> > > Why is DDP being asked to implement a mandatory solution that 
> > > protects the transport from MITM attacks? I acknowledge that DDP is 
> > > in a gray area between transport and ULP, but either way, there 
> > > should be consistency for all new ULPs and/or transports. Where is 
> > > the cry for mandatory IPSEC on SCTP?
> > >
> > > BTW - my recollection of the year old Stag security issue was 
> > > related to the necessary isolations/associations of an Stag with 
> > > each transport stream, a local peer security issue.
> > >
> > > Regards,
> > > Dwight
> > >
> > > > -----Original Message-----
> > > > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> > > > Behalf Of Black_David at emc.com
> > > > Sent: Wednesday, June 02, 2004 9:32 AM
> > > > To: rddp at ietf.org
> > > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > > >
> > > >
> > > > Caitlin Bestler writes:
> > > >
> > > > > That would only be true if the DDP header posed a new
> > > > security risk,
> > > > > one not faced by an equivalent LLP-only application.
> > > > >
> > > > > I do not believe that this analysis is shared by the WG. I 
> > > > > certainly do not accept it.
> > > > >
> > > > > A DDP Header has no magic access to user memory. Just as any 
> > > > > above-transport-header, it only has access to user memory to the
> 
> > > > > extent authorized by the ULP.
> > > > >
> > > > > I do not believe that you, or anyone else, has disputed that 
> > > > > assertion.
> > > >
> > > > The latter assertion is correct, but it does not imply that a DDP 
> > > > header creates no risks beyond an equivalent LLP-only application.
> 
> > > > For an LLP-only application transport buffers are always one-shot 
> > > > and receive addresses in memory are determined by the receiver, 
> > > > not the sender.  If the WG were prepared to limit itself to this 
> > > > behavior by requiring that all STags be one-shot, then the 
> > > > position that there are no new security risks should be 
> > > > defensible.  The WG does not appear to be prepared to make this 
> > > > restriction.
> > > >
> > > > More importantly, relying on the "authorized by the ULP" assertion
> 
> > > > is not acceptable to the IESG.  That approach amounts to an 
> > > > instruction to ULP developers not to use long-lived STags if they 
> > > > are a potential cause of security problems and also an instruction
> 
> > > > to users not to use ULPs that employ long-lived STags if 
> > > > long-lived STags will cause security problems on their network(s).
> 
> > > > I've recently had to deal with another draft that tried this sort 
> > > > of "don't use feature <X> if it will cause security problems" 
> > > > approach; the IESG rejected that approach, and the security 
> > > > considerations section of the draft had to be revised.
> > > >
> > > > The bottom line is that long-lived STags create additional memory 
> > > > exposure that is not present in an equivalent LLP-only 
> > > > application.  The fact that the ULP chose to create the exposure 
> > > > does not absolve RDDP of providing security measures to deal with 
> > > > it.  IETF requires that protocols which create security issues 
> > > > deal with those security issues and not palm them off on other 
> > > > protocols (e.g., by asserting that all security issues created by 
> > > > long-lived RDDP STags are ULP problems because the ULP chose to 
> > > > use them).
> > > >
> > > > I've just updated and resubmitted draft-ietf-rddp-rdma-concerns 
> > > > (will appear shortly as a -01
> > > > version) - it contains nearly 2-year-old text in its security 
> > > > considerations section pointing out this memory exposure issue.
> > > >
> > > > 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
> > > >
> > >
> >
> > _______________________________________________
> > 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
> 
> 

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

To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Barron, Dwight" <[email-masked]>
Date: Mon, 7 Jun 2004 13:15:50 -0500
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: AcRMDxVnNsmtl9wDRbCaTDqcCKFGNQAmJd9g
Thread-topic: [rddp] IPsec and RDDP as a transport

Caitlin wrote:
> > Or more generally, a buffer that the application intends to use is 
> > still exposed to update from non-authenticated DDP packets.
> 
David Black responded:
> The latter is the better statement of the vulnerability, as 
> it includes man-in-the-middle traffic injection, e.g., via a 
> connection hijack.

Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP, MPI)
and ad-hoc applications in determining responsibility of implementing
protocol behaviors that do not leave themselves vulnerable? I believe it
is quite innoccuous and appropriate to require that IETF (or other)
ULPs be designed in a matter that does not notify ULP consumers of
available data while an Stag is 
still mapped to that data. Both remote and local Stag invalidations are
envisioned to be very 
lightweight operations. I also believe that the vast majority of data
movement and usage of 
DDP will occur through these and other defined ULPs. 

Regards,
Dwight

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of Black_David at emc.com
> Sent: Sunday, June 06, 2004 4:36 PM
> To: cait at asomi.com; rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> Several clarifying comments:
> 
> > To summarize, the vulnerability occurs when an application 
> trusts its 
> > remote peer to follow the upper layer protocol regarding 
> STag access 
> > rather than using the local interface to enforce compliance.
> > 
> > Or more generally, a buffer that the application intends to use is 
> > still exposed to update from non-authenticated DDP packets.
> 
> The latter is the better statement of the vulnerability, as 
> it includes man-in-the-middle traffic injection, e.g., via a 
> connection hijack.
> 
> > David has proposed the ULP be able to rely on the availability of 
> > IPsec authentication of DDP packets.
> 
> Not exactly ... this was originally proposed in the RDDP 
> security draft, although with a "SHOULD implement" 
> requirement that would have to be changed to "MUST implement" 
> in order to obtain IESG approval. This was discussed in 
> Seoul, which is why the original thread on this topic carries 
> the issue (4) tag from Seoul.
> 
> To the extent that I've pointed out that the IESG is very 
> serious about mandatory-to-implement security, I guess it's 
> fair to tag me with some responsibility for this proposal, BUT ...
> 
> ... I have also posted that while IPsec is sufficient to deal 
> with this problem, it's more than is necessary.  It should be 
> possible to design a mechanism that only authenticates the 
> RDDP headers via some sort of keyed cryptographic integrity 
> check.  I would ask everyone to please stop looking for 
> conspiracy theories about how this is somehow part of a grand 
> plot to require IPsec everywhere.
> 
> Despite this, I do think local functionality/interface 
> modifications (e.g., restrict all STags to be 'one-shot' and 
> require implementations to enforce this) are the preferred 
> approach because they block not only the man-in-the-middle 
> but also the misbehaved or malicious client; this is quite 
> useful for protocols like NFS that generally cannot place 
> complete trust in clients.  I probably should have said this 
> more strenuously about a dozen posts ago.
> 
> Caitlin's proposal below appears to be headed in a productive 
> direction, but at the end of the day, we have to abide by the 
> IESG's "if you broke it, provide tools to fix it" approach to 
> mandatory-to-implement security
> - if the WG wants its specifications to provide long-lived 
> STag functionality for use by protocols that are prepared to 
> assume the requisite high degree of trust among the 
> communicating peers, the WG is obligated to also provide the 
> mandatory-to-implement security that such protocols can use 
> to prevent man-in-the-middle attacks on/via that long-lived 
> STag functionality.  At the moment, I'm not certain whether 
> Caitlin's proposal is sufficient in this regard.
> 
> 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: Saturday, June 05, 2004 6:59 AM
> > To: Black_David at emc.com; RDDP
> > Subject: Re: [rddp] IPsec and RDDP as a transport
> > 
> > 
> > 
> > On Jun 5, 2004, at 3:56 AM, Black_David at emc.com wrote:
> > 
> > > Dwight,
> > >
> > >> Sorry to be dense, but I'm still having trouble visualizing the 
> > >> attack that makes DDP more vulnerable. I think it has been 
> > >> relegated to a man in the middle attack scenario, as bogus data 
> > >> from the real peer always gets through, even with IPSEC enabled. 
> > >> The transport layer behavior is the same with/without 
> DDP headers; 
> > >> a packet with an appropriate transport sequence number 
> gets ACKed 
> > >> and passed upstream to be placed in a buffer. The buffer 
> eventually 
> > >> gets passed to the application.
> > >
> > > The difference happens here.  If the STag is 'long-lived' or
> 'persistent'
> > > and has not been invalidated, the buffer can still be modified 
> > > remotely
> > > *after* being passed to the application.  Such modification is not
> > > possible in the absence of DDP.  If the STag is 
> 'one-shot' (in whatever
> > > sense that restriction is defined), the important 
> property is that the
> > > application can rely on the data not being changed by 
> remote access
> > > after the buffer has been passed to the application.  If the WG
> > > is prepared to restrict all STags to be 'one-shot' so 
> that at the point
> > > where the buffer is passed to the application, the STag 
> used to deliver
> > > the data MUST be invalid (and the RDDP implementation is 
> responsible
> > > for ensuring this), then it should be possible to avoid additional
> > > security requirements in this area.
> > 
> > To summarize, the vulnerability occurs when an application 
> trusts its 
> > remote peer to follow the upper layer protocol regarding 
> STag access 
> > rather than using the local interface to enforce compliance.
> > 
> > Or more generally, a buffer that the application intends to use is 
> > still exposed to update from non-authenticated DDP packets.
> > 
> > This is indeed a new security vulnerability, the question is how to 
> > deal with it.
> > 
> > The current drafts take a "well we told you not to do that" 
> approach. 
> > Personally, I still find this valid. But I will concede that others 
> > might consider this to be inadequate. But for the record I 
> will point 
> > out that the RDDP layer simply cannot prevent the ULP from doing 
> > stupid things. Consider the fundamental rule that an 
> exposed buffer is 
> > undefined *until* the ULP infers delivery from a untagged 
> message or 
> > RDMA Read completion. An application that attempts to read smoke 
> > signals in partially update RDMA accessible buffers based only on 
> > tagged writes is very vulnerable not only to attack but to 
> to unstable 
> > behavior. I doubt that anyone would propose requiring the 
> RDDP layer 
> > to remove read access for the ULP on undelivered buffers 
> that it has 
> > update access to. And the vulnerability to unstable 
> behavior would be 
> > there even over IPsec.
> > 
> > David has proposed the ULP be able to rely on the availability of 
> > IPsec authentication of DDP packets.
> > 
> > I believe it would be more appropriate to require the local 
> interface 
> > to provide adequate tools so that applications would 
> neither be forced 
> > to overexpose buffers, or even be prone to do so by the defaults of 
> > the local interface. "Defaults" here would include omission 
> of extra 
> > steps that an application
> > *should* be taking, but the local interface requires 
> additional steps 
> > to invoke.
> > 
> > The proposed restriction to "one shot" STags would be one 
> such local 
> > interface change, but I believe it is also to extreme.
> > 
> > I believe we can determine what local interface 
> requirements would be 
> > appropriate if we examine the current gaps:
> > 
> > - The application can be encouraged to rely upon the remote
> >     peer to invalidate an STag when the transaction is done.
> >     If an expected remote invalidation is not performed, the
> >     application is typically required to invalidate the STag
> >     ifself. This is typically an asynchronous operation which
> >     would require the application to add an extra state before
> >     properly utilizing the buffer only after it had been secured.
> > 
> > -  Some applications advertise an aggregate buffer to be
> >     used over the span of several untagged messages. Each
> >     untagged message would indicate what portion of the
> >     advertised buffer had been used, and at the ULP layer
> >     pledge not to make further writes to that portion.
> > 
> >     Current local interfaces lack any support for enforcement
> >     of this model. When the portion used by the remote peer
> >     on each response is variably sized, there is no way for
> >     the Data Sink to remove one portion of a window without
> >     at least momentarily making the entire STag invalid.
> > 
> > To address these problems I would propose the following
> > local interface enhancements, which could be implemented
> > as an alternative to authenticating DDP packets with IPsec
> > or other equivalent transport-layer solutions:
> > 
> > -- The local interface MUST provide an option where a posted
> >      receive operation will complete in error unless the Send
> >      successfully invalidated an STag.
> > 
> > -- The local interface MUST provide an option where a posted
> >      receive operation will not complete until after a specified
> >      STag has been invalidated.
> > 
> > -- The local interface MUST provide an option to rebind an
> >      STag to a contiguous subset of its current range without
> >      taking it through an intermediate invalid state.
> > 
> > With these tools an application can easily ensure that the DDP 
> > exposure of an STag matches the ULP required exposure. Given the 
> > ability to easily remove a buffer's exposure *before* using it the 
> > application will face *no* additional security vulnerability and 
> > therefore would *not* require IPsec.
> > 
> > That may also be true with a subset of the above. The last 
> one is the 
> > only requirement that cannot be implemented by a shim layer over 
> > current verbs, and it is admittedly of the least generality.
> > 
> > 
> > 
> > 
> > --
> > Caitlin Bestler
> > http://asomi.com/
> > 
> 
> _______________________________________________
> 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]
Subject: Re: [rddp] IPsec and RDDP as a transport
From: "Mallikarjun C." <[email-masked]>
Date: Mon, 07 Jun 2004 12:23:18 -0700
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]
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

To follow up on Dwight's point about well-designed ULPs with buffer use restrictions, here is a very short summary of how iSER deals with this today (and the IPS WG can choose to tighten these further once it hopefully takes up the RDMA work) since we seem to be on iSCSI/iSER anyway.

iSER target
- MUST cause invalidation of advertised peer STag via a
  SendInvSE message at the end of each I/O.
- MUST locally invalidate the Data Sink STags associated
  with the I/O whenever the I/O concludes abnormally
  (abort/reset etc.).
- SHOULD invalidate each Data Sink STag locally upon corresponding
  RDMA Read's conclusion.

iSER initiator
- MUST double check the auto-invalidation realized via
  SendInvSE upon each I/O conclusion.
- MUST invalidate the second STag locally upon bidirectional
  command completion.
- MUST locally invalidate the STags associated with the I/O
  whenever the I/O concludes abnormally (abort/reset etc.).
- All this MUST happen before the final I/O status is
  delivered to the iSCSI layer

BTW, I'd appreciate if someone can provide a precise description of
the scenario leading to the new "hole" with iSCSI/iSER and why the same cannot be encountered with iSCSI-3720 (RFC #).
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

Barron, Dwight wrote:

Caitlin wrote:

            Or more generally, a buffer that the application intends to use is still exposed to update from non-authenticated DDP packets. 

David Black responded:

        The latter is the better statement of the vulnerability, as it includes man-in-the-middle traffic injection, e.g., via a connection hijack. 

    Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP, MPI)
    and ad-hoc applications in determining responsibility of implementing
    protocol behaviors that do not leave themselves vulnerable? I believe it
    is quite innoccuous and appropriate to require that IETF (or other)
    ULPs be designed in a matter that does not notify ULP consumers of
    available data while an Stag is still mapped to that data. Both remote and local Stag invalidations are
    envisioned to be very lightweight operations. I also believe that the vast majority of data
    movement and usage of DDP will occur through these and other defined ULPs.

Regards,
Dwight

        -----Original Message-----
        From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf Of Black_David at emc.com
        Sent: Sunday, June 06, 2004 4:36 PM
        To: cait at asomi.com; rddp at ietf.org
        Subject: RE: [rddp] IPsec and RDDP as a transport

Several clarifying comments:

            To summarize, the vulnerability occurs when an application 

        trusts its

            remote peer to follow the upper layer protocol regarding 

        STag access

rather than using the local interface to enforce compliance.

            Or more generally, a buffer that the application intends to use is still exposed to update from non-authenticated DDP packets. 

        The latter is the better statement of the vulnerability, as it includes man-in-the-middle traffic injection, e.g., via a connection hijack.

            David has proposed the ULP be able to rely on the availability of IPsec authentication of DDP packets. 

        Not exactly ... this was originally proposed in the RDDP security draft, although with a "SHOULD implement" requirement that would have to be changed to "MUST implement" in order to obtain IESG approval. This was discussed in Seoul, which is why the original thread on this topic carries the issue (4) tag from Seoul.

        To the extent that I've pointed out that the IESG is very serious about mandatory-to-implement security, I guess it's fair to tag me with some responsibility for this proposal, BUT ...

        ... I have also posted that while IPsec is sufficient to deal with this problem, it's more than is necessary. It should be possible to design a mechanism that only authenticates the RDDP headers via some sort of keyed cryptographic integrity check. I would ask everyone to please stop looking for conspiracy theories about how this is somehow part of a grand plot to require IPsec everywhere.

        Despite this, I do think local functionality/interface modifications (e.g., restrict all STags to be 'one-shot' and require implementations to enforce this) are the preferred approach because they block not only the man-in-the-middle but also the misbehaved or malicious client; this is quite useful for protocols like NFS that generally cannot place complete trust in clients. I probably should have said this more strenuously about a dozen posts ago.

        Caitlin's proposal below appears to be headed in a productive direction, but at the end of the day, we have to abide by the IESG's "if you broke it, provide tools to fix it" approach to mandatory-to-implement security
        - if the WG wants its specifications to provide long-lived STag functionality for use by protocols that are prepared to assume the requisite high degree of trust among the communicating peers, the WG is obligated to also provide the mandatory-to-implement security that such protocols can use to prevent man-in-the-middle attacks on/via that long-lived STag functionality. At the moment, I'm not certain whether Caitlin's proposal is sufficient in this regard.

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:[email-masked]]
Sent: Saturday, June 05, 2004 6:59 AM
To: [email-masked]; RDDP
Subject: Re: [rddp] IPsec and RDDP as a transport

On Jun 5, 2004, at 3:56 AM, Black_David at emc.com wrote:

Dwight,

                    Sorry to be dense, but I'm still having trouble visualizing the attack that makes DDP more vulnerable. I think it has been relegated to a man in the middle attack scenario, as bogus data from the real peer always gets through, even with IPSEC enabled. The transport layer behavior is the same with/without 

        DDP headers;

                    a packet with an appropriate transport sequence number 

        gets ACKed

                    and passed upstream to be placed in a buffer. The buffer 

        eventually

                    gets passed to the application. 

                The difference happens here. If the STag is 'long-lived' or 

'persistent'

                and has not been invalidated, the buffer can still be modified remotely
                *after* being passed to the application. Such modification is not
                possible in the absence of DDP. If the STag is 

'one-shot' (in whatever

                sense that restriction is defined), the important 

property is that the

                application can rely on the data not being changed by 

remote access

                after the buffer has been passed to the application. If the WG
                is prepared to restrict all STags to be 'one-shot' so 

that at the point

                where the buffer is passed to the application, the STag 

used to deliver

                the data MUST be invalid (and the RDDP implementation is 

responsible

for ensuring this), then it should be possible to avoid additional
security requirements in this area.

            To summarize, the vulnerability occurs when an application 

        trusts its

            remote peer to follow the upper layer protocol regarding 

        STag access

rather than using the local interface to enforce compliance.

            Or more generally, a buffer that the application intends to use is still exposed to update from non-authenticated DDP packets.

            This is indeed a new security vulnerability, the question is how to deal with it.

            The current drafts take a "well we told you not to do that" 

        approach.

            Personally, I still find this valid. But I will concede that others might consider this to be inadequate. But for the record I 

        will point

            out that the RDDP layer simply cannot prevent the ULP from doing stupid things. Consider the fundamental rule that an 

        exposed buffer is

            undefined *until* the ULP infers delivery from a untagged 

        message or

            RDMA Read completion. An application that attempts to read smoke signals in partially update RDMA accessible buffers based only on tagged writes is very vulnerable not only to attack but to 

        to unstable

            behavior. I doubt that anyone would propose requiring the 

        RDDP layer

            to remove read access for the ULP on undelivered buffers 

        that it has

            update access to. And the vulnerability to unstable 

        behavior would be

there even over IPsec.

            David has proposed the ULP be able to rely on the availability of IPsec authentication of DDP packets.

            I believe it would be more appropriate to require the local 

        interface

            to provide adequate tools so that applications would 

        neither be forced

            to overexpose buffers, or even be prone to do so by the defaults of the local interface. "Defaults" here would include omission 

        of extra

            steps that an application
            *should* be taking, but the local interface requires 

        additional steps

to invoke.

            The proposed restriction to "one shot" STags would be one 

        such local

interface change, but I believe it is also to extreme.

            I believe we can determine what local interface 

        requirements would be

appropriate if we examine the current gaps:

- The application can be encouraged to rely upon the remote
   peer to invalidate an STag when the transaction is done.
   If an expected remote invalidation is not performed, the
   application is typically required to invalidate the STag
   ifself. This is typically an asynchronous operation which
   would require the application to add an extra state before
   properly utilizing the buffer only after it had been secured.

-  Some applications advertise an aggregate buffer to be
   used over the span of several untagged messages. Each
   untagged message would indicate what portion of the
   advertised buffer had been used, and at the ULP layer
   pledge not to make further writes to that portion.

   Current local interfaces lack any support for enforcement
   of this model. When the portion used by the remote peer
   on each response is variably sized, there is no way for
   the Data Sink to remove one portion of a window without
   at least momentarily making the entire STag invalid.

To address these problems I would propose the following
local interface enhancements, which could be implemented
as an alternative to authenticating DDP packets with IPsec
or other equivalent transport-layer solutions:

-- The local interface MUST provide an option where a posted
    receive operation will complete in error unless the Send
    successfully invalidated an STag.

-- The local interface MUST provide an option where a posted
    receive operation will not complete until after a specified
    STag has been invalidated.

-- The local interface MUST provide an option to rebind an
    STag to a contiguous subset of its current range without
    taking it through an intermediate invalid state.

            With these tools an application can easily ensure that the DDP exposure of an STag matches the ULP required exposure. Given the ability to easily remove a buffer's exposure *before* using it the application will face *no* additional security vulnerability and therefore would *not* require IPsec.

            That may also be true with a subset of the above. The last 

        one is the

            only requirement that cannot be implemented by a shim layer over current verbs, and it is admittedly of the least generality.

--
Caitlin Bestler
http://asomi.com/

_______________________________________________
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

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

To: [email-masked]
Subject: Re: [rddp] RDDP-enabled iSCSI "hole"
From: John Hufferd <[email-masked]>
Date: Mon, 7 Jun 2004 12:29:00 -0700
Cc: rddp-bounces at ietf.org, uri at broadcom.com, rddp at ietf.org
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>
Sender: [email-masked]

David,
I have tried to make some clarifications/extensions to your note below, with respect to iSCSI on RDMA - which is called iSCSI/iSER (iSCSI Extensions for RDMA).

First the Buffer is advertized to the Target (storage controller) as an STag (in an iSER header that is pre-pended onto the normal iSCSI PDU -- e.g. a Write PDU in the example case.  There may or my not be Immediate data within the same iSCSI PDU.  

On the target side the STag is used in possibly multiple RDMA Read operations, to extract the Write data from the Host buffers to the Target buffers.  The number and size of the RDMA reads is dependent on how much data is left to be extracted from the Host, and how much Cache Space is available at any one time at the target.  So it might take one RDMA Read or it might take 100+ RDMA reads.  All the RDMA reads use the same STag that was advertised with the iSCSI/iSER Write PDU (SCSI Write Command) but use different displacements.  

At the completion of the operation, the Target MUST return the status of the operation (in this case the status of the Write Command) in a "Send with Invalidate" type message that includes the STag to be invalidated.

The RNIC at the Host system is suppose to invalidate the subject STag, and when the status message is delivered to the iSCSI/iSER Host Initiator it is required to check the STag that was invalidated by the RNIC, and if for some reason it was not the STag associated with the I/O operation, iSCSI/iSER is supposed to overtly cause the STag that was advertised, to be invalidated.
So either the RNIC does the invalidate automatically, or the application performs the invalidate.  But NO STag is suppose to live beyond the Actual SCSI I/O operation.  

It was expected that subsequent SCSI I/O operations would use another STag.  

The important point, however, is that multiple RDMA Read operations can be done by the Target back to the Host initiator using the same STag.  But the STag is always invalidated after any specific transaction (SCSI I/O operation).

This then has perhaps lead to some confusion in our interchange here, where I an others wanted to be sure that the term "Single Shot STag" limitation was not used to prevent the multiple RDMA Read operations done to complete a SCSI Write.  Yet we are probably content to state that the invalidate is done after every transaction where a SCSI type transaction is completed by the returned Status in a Send (with invalidate) type message.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd at us.ibm.com

Black_David at emc.com
Sent by: rddp-bounces at ietf.org

06/06/2004 01:40 PM
To
uri at broadcom.com, rddp at ietf.org
cc
Subject
[rddp] RDDP-enabled iSCSI "hole"

Uri,

> I'd like to chime in on this important discussion. I'm sorry,
> but I do fail to see the "new" security hole.

Here's a scenario where long-lived RDDP STags cause a potential
iSCSI security "hole" that can't occur with single-shot STags or
in the absence of RDDP.  I'm going one step beyond Somesh and
assuming that the iSCSI data CRC is still being used with RDDP
(in contrast to Somesh's assumption that the RDDP CRC(s)
replace(s) the iSCSI data CRC - that assumption opens the "hole"
wider because the RDDP CRC is checked earlier):

(1) An STag is used to transfer data for an iSCSI write.
                The STag is left valid after the data is transfer so
                that the initiator and target can reuse this buffer
                and its STag for the next write (a fairly obvious and
                desirable optimization).
(2) The iSCSI target checks the received data against the
                iSCSI CRC.  The check succeeds, so the target code
                requests a local disk write operation from the buffer
                that is still exposed via the STag
(3) Before the write operation takes place, a TCP packet from
                the MITM attacker (e.g., connection hijacker) shows up
                and uses the STag to overwrite part of the write buffer.

At this point, there is corrupt data headed for the disk.  In
the absence of long-lived STags, the TCP packet at step (3)
gets rejected by RDDP.  In the absence of RDDP, that TCP packet
gets through, but won't corrupt the iSCSI write data.  Hence
RDDP's long-lived STags have opened up a new security problem.

This problem appears to be generic to any reuse of a write
buffer and its associated STag.  If an application protocol
uses RDDP to transfer data that is actually interpreted by
the application protocol, there are versions of this attack
that target protocol functionality if the implementation
contains code that assumes the contents of the receive
buffer don't change.

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 Uri Elzur
> Sent: Friday, June 04, 2004 9:56 PM
> To: Somesh Gupta; rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
>
>
> Somesh
>
> If a packet is hijacked, what will prevent the CRC match??!!
> So why will
> the iSCSI over TCP data not be accepted? CRC has no cryptographic
> value...
>
> Uri
>
> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> Behalf Of
> Somesh Gupta
> Sent: Friday, June 04, 2004 6:28 PM
> To: rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
>
>
> It seems that for iSCSI specifically, RDMA writes icrease the
> possibility of data corruption, even with 'one-shot' STags. Consider
> iSCSI over TCP, with header and data CRC. If a random TCP
> packet is used
> to attack the connection, and the packet is accepted (large windows
> etc), the CRC checks will fail and the problem detected before a
> corruption occurs.
>
> Now consider iSCSI using iSER over RDDP. iSCSI depends on RDDP for CRC
> checks. An attack on the connection (out of order RDMA writes) could
> place data in the write buffers and if this happens, the attack will
> never be detected.
>
> Maybe this problem is iSCSI specific only.
>
> Somesh

_______________________________________________
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: "Somesh Gupta" <[email-masked]>, "Uri Elzur" <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Barron, Dwight" <[email-masked]>
Date: Mon, 7 Jun 2004 15:26:56 -0500
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: AcRMu88DBi/pvXy+Sk6G+rXTJ/sj6AAEVwJQ
Thread-topic: [rddp] IPsec and RDDP as a transport

This compromize includes two components, one a successful spoofing of
the transport layer, in which RDDP is no more or less vulernable (same
transports) and a second component which is the demarcation point at
which the ULP can be assured that the buffer is no longer available for
modification by a remote peer. I believe that iSER has correctly
addressed this issue (see John Hufferd's clarification). The Stag will
be un-allocated before notification/completion of the SCSI command. 

Regards,
Dwight

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of Somesh Gupta
> Sent: Monday, June 07, 2004 12:58 PM
> To: Uri Elzur; rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> Uri,
> 
> With iSCSI, there is a delineation process on the byte
> stream before processing the data. In other words,
> if one packet or sequence of packets is injected by
> the rogue, it will be detected because the delineation
> process or CRC check or both will fail. There is one
> exception to this which is if the attacker can also
> predict the location of PDU header or data boundary in the 
> byte stream at the same time.
> 
> However RDMA writes offers no such protection. Out of
> order RDMA writes can be completed, corrupting data.
> Even when the holes are filled and if there are mechanisms
> to detect that there was mis-alignment of data,
> the user is still Out of luck because the data may already
> have been consumed.
> 
> Somesh
> 
> > -----Original Message-----
> > From: Uri Elzur [mailto:uri at broadcom.com]
> > Sent: Friday, June 04, 2004 6:56 PM
> > To: Somesh Gupta; rddp at ietf.org
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> > 
> > 
> > Somesh
> > 
> > If a packet is hijacked, what will prevent the CRC match??!! So why 
> > will the iSCSI over TCP data not be accepted? CRC has no 
> cryptographic 
> > value...
> > 
> > Uri
> > 
> > -----Original Message-----
> > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] 
> On Behalf 
> > Of Somesh Gupta
> > Sent: Friday, June 04, 2004 6:28 PM
> > To: rddp at ietf.org
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> > 
> > 
> > It seems that for iSCSI specifically, RDMA writes icrease the 
> > possibility of data corruption, even with 'one-shot' STags. 
> Consider 
> > iSCSI over TCP, with header and data CRC. If a random TCP packet is 
> > used to attack the connection, and the packet is accepted (large 
> > windows etc), the CRC checks will fail and the problem 
> detected before 
> > a corruption occurs.
> > 
> > Now consider iSCSI using iSER over RDDP. iSCSI depends on 
> RDDP for CRC 
> > checks. An attack on the connection (out of order RDMA 
> writes) could 
> > place data in the write buffers and if this happens, the 
> attack will 
> > never be detected.
> > 
> > Maybe this problem is iSCSI specific only.
> > 
> > Somesh
> > > -----Original Message-----
> > > From: rddp-bounces at ietf.org 
> [mailto:rddp-bounces at ietf.org]On Behalf 
> > > Of
> > 
> > > Black_David at emc.com
> > > Sent: Friday, June 04, 2004 5:56 PM
> > > To: dwight.barron at hp.com; rddp at ietf.org
> > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > >
> > >
> > > Dwight,
> > >
> > > > Sorry to be dense, but I'm still having trouble visualizing the
> > > > attack that makes DDP more vulnerable. I think it has 
> been relegated
> > 
> > > > to a man in the middle attack scenario, as bogus data from the 
> > > > real
> > > > peer always gets through, even with IPSEC enabled. The 
> transport 
> > > > layer behavior is the same with/without DDP headers; a 
> packet with 
> > > > an appropriate transport sequence number gets ACKed and passed 
> > > > upstream to be placed in a buffer. The buffer 
> eventually gets passed
> > 
> > > > to the application.
> > >
> > > The difference happens here.  If the STag is 'long-lived' or
> > > 'persistent' and has not been invalidated, the buffer can 
> still be 
> > > modified remotely
> > > *after* being passed to the application.  Such modification is not
> > > possible in the absence of DDP.  If the STag is 'one-shot' (in
> > whatever
> > > sense that restriction is defined), the important 
> property is that 
> > > the application can rely on the data not being changed by remote 
> > > access after the buffer has been passed to the 
> application.  If the 
> > > WG is prepared to restrict all STags to be 'one-shot' so 
> that at the
> > point
> > > where the buffer is passed to the application, the STag used to
> > deliver
> > > the data MUST be invalid (and the RDDP implementation is 
> responsible 
> > > for ensuring this), then it should be possible to avoid 
> additional 
> > > security requirements in this area.
> > >
> > > [... snip ...]
> > >
> > > > Why is DDP being asked to implement a mandatory
> > > > solution that protects the transport from MITM attacks?
> > >
> > > Protection of the transport is not being required.  What is being
> > > required is to be able to protect the application from 
> exploitation of
> > 
> > > memory exposure enabled by RDDP functionality that is 
> beyond that of
> > > the underlying transport.  If RDDP is willing to forego that 
> > > additional functionality, there should no longer be a 
> problem that 
> > > needs a mandatory solution.
> > >
> > > > I acknowledge
> > > > that DDP is in a gray area between transport and ULP, but either
> > > > way, there should be consistency for all new ULPs 
> and/or transports.
> > 
> > > > Where is the cry for mandatory IPSEC on SCTP?
> > >
> > > The ULP can choose how it wants to secure its data.  TLS is among 
> > > the
> > > possibilities and can be used over SCTP.  Beyond this, if 
> SCTP runs 
> > > over IPv6, IPsec is mandatory, and I would expect that if 
> any of the 
> > > IP Storage protocols (iSCSI, FCIP, iFCP) are defined over 
> SCTP, IPsec 
> > > will remain mandatory for them.  In any case, IPsec is 
> sufficient, but
> > 
> > > not necessary for RDDP.  A mechanism that prevents MITM misuse of 
> > > RDDP
> > 
> > > headers is a possible alternative.
> > >
> > > > BTW - my recollection of the year old Stag security issue was
> > > > related to the necessary isolations/associations of an 
> Stag with 
> > > > each transport stream, a local peer security issue.
> > >
> > > That was a related, but different issue.  The ability to control 
> > > STag
> > > association with transport streams is still necessary.
> > >
> > > 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: Barron, Dwight [mailto:dwight.barron at hp.com]
> > > > Sent: Friday, June 04, 2004 7:51 PM
> > > > To: Black_David at emc.com; rddp at ietf.org
> > > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > > >
> > > >
> > > > Sorry to be dense, but I'm still having trouble visualizing the
> > > > attack that makes DDP more vulnerable. I think it has 
> been relegated
> > 
> > > > to a man in the middle attack scenario, as bogus data from the 
> > > > real
> > > > peer always gets through, even with IPSEC enabled. The 
> transport 
> > > > layer behavior is the same with/without DDP headers; a 
> packet with 
> > > > an appropriate transport sequence number gets ACKed and passed 
> > > > upstream to be placed in a buffer. The buffer 
> eventually gets passed
> > 
> > > > to the application. The only difference I see is in the buffer
> > > > model, random access within the scope of an Stag vs. 
> being put in a 
> > > > pre-posted buffer. Either way, the wrong data gets 
> passed to the 
> > > > upper layer because of spoofing that got past the 
> transport layer. 
> > > > Why is DDP being asked to implement a mandatory solution that 
> > > > protects the transport from MITM attacks? I acknowledge 
> that DDP is 
> > > > in a gray area between transport and ULP, but either way, there 
> > > > should be consistency for all new ULPs and/or 
> transports. Where is 
> > > > the cry for mandatory IPSEC on SCTP?
> > > >
> > > > BTW - my recollection of the year old Stag security issue was
> > > > related to the necessary isolations/associations of an 
> Stag with 
> > > > each transport stream, a local peer security issue.
> > > >
> > > > Regards,
> > > > Dwight
> > > >
> > > > > -----Original Message-----
> > > > > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> > > > > Behalf Of Black_David at emc.com
> > > > > Sent: Wednesday, June 02, 2004 9:32 AM
> > > > > To: rddp at ietf.org
> > > > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > > > >
> > > > >
> > > > > Caitlin Bestler writes:
> > > > >
> > > > > > That would only be true if the DDP header posed a new
> > > > > security risk,
> > > > > > one not faced by an equivalent LLP-only application.
> > > > > >
> > > > > > I do not believe that this analysis is shared by the WG. I
> > > > > > certainly do not accept it.
> > > > > >
> > > > > > A DDP Header has no magic access to user memory. Just as any
> > > > > > above-transport-header, it only has access to user 
> memory to the
> > 
> > > > > > extent authorized by the ULP.
> > > > > >
> > > > > > I do not believe that you, or anyone else, has disputed that
> > > > > > assertion.
> > > > >
> > > > > The latter assertion is correct, but it does not imply that a 
> > > > > DDP
> > > > > header creates no risks beyond an equivalent LLP-only 
> application.
> > 
> > > > > For an LLP-only application transport buffers are always 
> > > > > one-shot
> > > > > and receive addresses in memory are determined by the 
> receiver, 
> > > > > not the sender.  If the WG were prepared to limit 
> itself to this 
> > > > > behavior by requiring that all STags be one-shot, then the 
> > > > > position that there are no new security risks should be 
> > > > > defensible.  The WG does not appear to be prepared to 
> make this 
> > > > > restriction.
> > > > >
> > > > > More importantly, relying on the "authorized by the ULP" 
> > > > > assertion
> > 
> > > > > is not acceptable to the IESG.  That approach amounts to an
> > > > > instruction to ULP developers not to use long-lived 
> STags if they 
> > > > > are a potential cause of security problems and also 
> an instruction
> > 
> > > > > to users not to use ULPs that employ long-lived STags if
> > > > > long-lived STags will cause security problems on 
> their network(s).
> > 
> > > > > I've recently had to deal with another draft that tried this 
> > > > > sort
> > > > > of "don't use feature <X> if it will cause security problems" 
> > > > > approach; the IESG rejected that approach, and the security 
> > > > > considerations section of the draft had to be revised.
> > > > >
> > > > > The bottom line is that long-lived STags create additional 
> > > > > memory
> > > > > exposure that is not present in an equivalent LLP-only 
> > > > > application.  The fact that the ULP chose to create 
> the exposure 
> > > > > does not absolve RDDP of providing security measures 
> to deal with 
> > > > > it.  IETF requires that protocols which create 
> security issues 
> > > > > deal with those security issues and not palm them off 
> on other 
> > > > > protocols (e.g., by asserting that all security 
> issues created by 
> > > > > long-lived RDDP STags are ULP problems because the 
> ULP chose to 
> > > > > use them).
> > > > >
> > > > > I've just updated and resubmitted 
> draft-ietf-rddp-rdma-concerns
> > > > > (will appear shortly as a -01
> > > > > version) - it contains nearly 2-year-old text in its security 
> > > > > considerations section pointing out this memory 
> exposure issue.
> > > > >
> > > > > 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
> > > > >
> > > >
> > >
> > > _______________________________________________
> > > 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
> > 
> > 
> 
> _______________________________________________
> 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]>, <[email-masked]>
Subject: RE: [rddp] RDDP-enabled iSCSI "hole"
From: "Somesh Gupta" <[email-masked]>
Date: Mon, 7 Jun 2004 13:16:42 -0700
Importance: Normal
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>
Sender: [email-masked]

David,

Why are you assuming that there is a separate iSCSI CRC above and
beyond the RDDP CRC? I assume that use of iSER implies use of
RDDP CRC. And in this case, the hole is pretty big, whether the
STags are single-shot or not.

Somesh

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org]On Behalf Of
> Black_David at emc.com
> Sent: Sunday, June 06, 2004 1:41 PM
> To: uri at broadcom.com; rddp at ietf.org
> Subject: [rddp] RDDP-enabled iSCSI "hole"
> 
> 
> Uri,
> 
> > I'd like to chime in on this important discussion. I'm sorry,
> > but I do fail to see the "new" security hole. 
> 
> Here's a scenario where long-lived RDDP STags cause a potential
> iSCSI security "hole" that can't occur with single-shot STags or
> in the absence of RDDP.  I'm going one step beyond Somesh and
> assuming that the iSCSI data CRC is still being used with RDDP
> (in contrast to Somesh's assumption that the RDDP CRC(s)
> replace(s) the iSCSI data CRC - that assumption opens the "hole"
> wider because the RDDP CRC is checked earlier):
> 
> (1) An STag is used to transfer data for an iSCSI write.
> 	The STag is left valid after the data is transfer so
> 	that the initiator and target can reuse this buffer
> 	and its STag for the next write (a fairly obvious and
> 	desirable optimization).
> (2) The iSCSI target checks the received data against the
> 	iSCSI CRC.  The check succeeds, so the target code
> 	requests a local disk write operation from the buffer
> 	that is still exposed via the STag
> (3) Before the write operation takes place, a TCP packet from
> 	the MITM attacker (e.g., connection hijacker) shows up
> 	and uses the STag to overwrite part of the write buffer.
> 
> At this point, there is corrupt data headed for the disk.  In
> the absence of long-lived STags, the TCP packet at step (3)
> gets rejected by RDDP.  In the absence of RDDP, that TCP packet
> gets through, but won't corrupt the iSCSI write data.  Hence
> RDDP's long-lived STags have opened up a new security problem.
> 
> This problem appears to be generic to any reuse of a write
> buffer and its associated STag.  If an application protocol
> uses RDDP to transfer data that is actually interpreted by 
> the application protocol, there are versions of this attack
> that target protocol functionality if the implementation
> contains code that assumes the contents of the receive
> buffer don't change.
> 
> 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 Uri Elzur
> > Sent: Friday, June 04, 2004 9:56 PM
> > To: Somesh Gupta; rddp at ietf.org
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> > 
> > 
> > Somesh
> > 
> > If a packet is hijacked, what will prevent the CRC match??!! 
> > So why will
> > the iSCSI over TCP data not be accepted? CRC has no cryptographic
> > value...
> > 
> > Uri
> > 
> > -----Original Message-----
> > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> > Behalf Of
> > Somesh Gupta
> > Sent: Friday, June 04, 2004 6:28 PM
> > To: rddp at ietf.org
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> > 
> > 
> > It seems that for iSCSI specifically, RDMA writes icrease the
> > possibility of data corruption, even with 'one-shot' STags. Consider
> > iSCSI over TCP, with header and data CRC. If a random TCP 
> > packet is used
> > to attack the connection, and the packet is accepted (large windows
> > etc), the CRC checks will fail and the problem detected before a
> > corruption occurs.
> > 
> > Now consider iSCSI using iSER over RDDP. iSCSI depends on RDDP for CRC
> > checks. An attack on the connection (out of order RDMA writes) could
> > place data in the write buffers and if this happens, the attack will
> > never be detected.
> > 
> > Maybe this problem is iSCSI specific only.
> > 
> > Somesh
> 
> _______________________________________________
> 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: "Barron, Dwight" <[email-masked]>, "Uri Elzur" <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Somesh Gupta" <[email-masked]>
Date: Mon, 7 Jun 2004 13:39:24 -0700
Importance: Normal
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>
Sender: [email-masked]

Dwight,

With regards to STags, the issue is of how Stags are generated
and whether there is significant level of predictability to
guessing an Stag correctly or not.

Somesh

> -----Original Message-----
> From: Barron, Dwight [mailto:dwight.barron at hp.com]
> Sent: Monday, June 07, 2004 1:27 PM
> To: Somesh Gupta; Uri Elzur; rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> This compromize includes two components, one a successful spoofing of
> the transport layer, in which RDDP is no more or less vulernable (same
> transports) and a second component which is the demarcation point at
> which the ULP can be assured that the buffer is no longer available for
> modification by a remote peer. I believe that iSER has correctly
> addressed this issue (see John Hufferd's clarification). The Stag will
> be un-allocated before notification/completion of the SCSI command. 
> 
> Regards,
> Dwight
> 
> > -----Original Message-----
> > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> > Behalf Of Somesh Gupta
> > Sent: Monday, June 07, 2004 12:58 PM
> > To: Uri Elzur; rddp at ietf.org
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> > 
> > 
> > Uri,
> > 
> > With iSCSI, there is a delineation process on the byte
> > stream before processing the data. In other words,
> > if one packet or sequence of packets is injected by
> > the rogue, it will be detected because the delineation
> > process or CRC check or both will fail. There is one
> > exception to this which is if the attacker can also
> > predict the location of PDU header or data boundary in the 
> > byte stream at the same time.
> > 
> > However RDMA writes offers no such protection. Out of
> > order RDMA writes can be completed, corrupting data.
> > Even when the holes are filled and if there are mechanisms
> > to detect that there was mis-alignment of data,
> > the user is still Out of luck because the data may already
> > have been consumed.
> > 
> > Somesh
> > 
> > > -----Original Message-----
> > > From: Uri Elzur [mailto:uri at broadcom.com]
> > > Sent: Friday, June 04, 2004 6:56 PM
> > > To: Somesh Gupta; rddp at ietf.org
> > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > > 
> > > 
> > > Somesh
> > > 
> > > If a packet is hijacked, what will prevent the CRC match??!! So why 
> > > will the iSCSI over TCP data not be accepted? CRC has no 
> > cryptographic 
> > > value...
> > > 
> > > Uri
> > > 
> > > -----Original Message-----
> > > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] 
> > On Behalf 
> > > Of Somesh Gupta
> > > Sent: Friday, June 04, 2004 6:28 PM
> > > To: rddp at ietf.org
> > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > > 
> > > 
> > > It seems that for iSCSI specifically, RDMA writes icrease the 
> > > possibility of data corruption, even with 'one-shot' STags. 
> > Consider 
> > > iSCSI over TCP, with header and data CRC. If a random TCP packet is 
> > > used to attack the connection, and the packet is accepted (large 
> > > windows etc), the CRC checks will fail and the problem 
> > detected before 
> > > a corruption occurs.
> > > 
> > > Now consider iSCSI using iSER over RDDP. iSCSI depends on 
> > RDDP for CRC 
> > > checks. An attack on the connection (out of order RDMA 
> > writes) could 
> > > place data in the write buffers and if this happens, the 
> > attack will 
> > > never be detected.
> > > 
> > > Maybe this problem is iSCSI specific only.
> > > 
> > > Somesh
> > > > -----Original Message-----
> > > > From: rddp-bounces at ietf.org 
> > [mailto:rddp-bounces at ietf.org]On Behalf 
> > > > Of
> > > 
> > > > Black_David at emc.com
> > > > Sent: Friday, June 04, 2004 5:56 PM
> > > > To: dwight.barron at hp.com; rddp at ietf.org
> > > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > > >
> > > >
> > > > Dwight,
> > > >
> > > > > Sorry to be dense, but I'm still having trouble visualizing the
> > > > > attack that makes DDP more vulnerable. I think it has 
> > been relegated
> > > 
> > > > > to a man in the middle attack scenario, as bogus data from the 
> > > > > real
> > > > > peer always gets through, even with IPSEC enabled. The 
> > transport 
> > > > > layer behavior is the same with/without DDP headers; a 
> > packet with 
> > > > > an appropriate transport sequence number gets ACKed and passed 
> > > > > upstream to be placed in a buffer. The buffer 
> > eventually gets passed
> > > 
> > > > > to the application.
> > > >
> > > > The difference happens here.  If the STag is 'long-lived' or
> > > > 'persistent' and has not been invalidated, the buffer can 
> > still be 
> > > > modified remotely
> > > > *after* being passed to the application.  Such modification is not
> > > > possible in the absence of DDP.  If the STag is 'one-shot' (in
> > > whatever
> > > > sense that restriction is defined), the important 
> > property is that 
> > > > the application can rely on the data not being changed by remote 
> > > > access after the buffer has been passed to the 
> > application.  If the 
> > > > WG is prepared to restrict all STags to be 'one-shot' so 
> > that at the
> > > point
> > > > where the buffer is passed to the application, the STag used to
> > > deliver
> > > > the data MUST be invalid (and the RDDP implementation is 
> > responsible 
> > > > for ensuring this), then it should be possible to avoid 
> > additional 
> > > > security requirements in this area.
> > > >
> > > > [... snip ...]
> > > >
> > > > > Why is DDP being asked to implement a mandatory
> > > > > solution that protects the transport from MITM attacks?
> > > >
> > > > Protection of the transport is not being required.  What is being
> > > > required is to be able to protect the application from 
> > exploitation of
> > > 
> > > > memory exposure enabled by RDDP functionality that is 
> > beyond that of
> > > > the underlying transport.  If RDDP is willing to forego that 
> > > > additional functionality, there should no longer be a 
> > problem that 
> > > > needs a mandatory solution.
> > > >
> > > > > I acknowledge
> > > > > that DDP is in a gray area between transport and ULP, but either
> > > > > way, there should be consistency for all new ULPs 
> > and/or transports.
> > > 
> > > > > Where is the cry for mandatory IPSEC on SCTP?
> > > >
> > > > The ULP can choose how it wants to secure its data.  TLS is among 
> > > > the
> > > > possibilities and can be used over SCTP.  Beyond this, if 
> > SCTP runs 
> > > > over IPv6, IPsec is mandatory, and I would expect that if 
> > any of the 
> > > > IP Storage protocols (iSCSI, FCIP, iFCP) are defined over 
> > SCTP, IPsec 
> > > > will remain mandatory for them.  In any case, IPsec is 
> > sufficient, but
> > > 
> > > > not necessary for RDDP.  A mechanism that prevents MITM misuse of 
> > > > RDDP
> > > 
> > > > headers is a possible alternative.
> > > >
> > > > > BTW - my recollection of the year old Stag security issue was
> > > > > related to the necessary isolations/associations of an 
> > Stag with 
> > > > > each transport stream, a local peer security issue.
> > > >
> > > > That was a related, but different issue.  The ability to control 
> > > > STag
> > > > association with transport streams is still necessary.
> > > >
> > > > 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: Barron, Dwight [mailto:dwight.barron at hp.com]
> > > > > Sent: Friday, June 04, 2004 7:51 PM
> > > > > To: Black_David at emc.com; rddp at ietf.org
> > > > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > > > >
> > > > >
> > > > > Sorry to be dense, but I'm still having trouble visualizing the
> > > > > attack that makes DDP more vulnerable. I think it has 
> > been relegated
> > > 
> > > > > to a man in the middle attack scenario, as bogus data from the 
> > > > > real
> > > > > peer always gets through, even with IPSEC enabled. The 
> > transport 
> > > > > layer behavior is the same with/without DDP headers; a 
> > packet with 
> > > > > an appropriate transport sequence number gets ACKed and passed 
> > > > > upstream to be placed in a buffer. The buffer 
> > eventually gets passed
> > > 
> > > > > to the application. The only difference I see is in the buffer
> > > > > model, random access within the scope of an Stag vs. 
> > being put in a 
> > > > > pre-posted buffer. Either way, the wrong data gets 
> > passed to the 
> > > > > upper layer because of spoofing that got past the 
> > transport layer. 
> > > > > Why is DDP being asked to implement a mandatory solution that 
> > > > > protects the transport from MITM attacks? I acknowledge 
> > that DDP is 
> > > > > in a gray area between transport and ULP, but either way, there 
> > > > > should be consistency for all new ULPs and/or 
> > transports. Where is 
> > > > > the cry for mandatory IPSEC on SCTP?
> > > > >
> > > > > BTW - my recollection of the year old Stag security issue was
> > > > > related to the necessary isolations/associations of an 
> > Stag with 
> > > > > each transport stream, a local peer security issue.
> > > > >
> > > > > Regards,
> > > > > Dwight
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> > > > > > Behalf Of Black_David at emc.com
> > > > > > Sent: Wednesday, June 02, 2004 9:32 AM
> > > > > > To: rddp at ietf.org
> > > > > > Subject: RE: [rddp] IPsec and RDDP as a transport
> > > > > >
> > > > > >
> > > > > > Caitlin Bestler writes:
> > > > > >
> > > > > > > That would only be true if the DDP header posed a new
> > > > > > security risk,
> > > > > > > one not faced by an equivalent LLP-only application.
> > > > > > >
> > > > > > > I do not believe that this analysis is shared by the WG. I
> > > > > > > certainly do not accept it.
> > > > > > >
> > > > > > > A DDP Header has no magic access to user memory. Just as any
> > > > > > > above-transport-header, it only has access to user 
> > memory to the
> > > 
> > > > > > > extent authorized by the ULP.
> > > > > > >
> > > > > > > I do not believe that you, or anyone else, has disputed that
> > > > > > > assertion.
> > > > > >
> > > > > > The latter assertion is correct, but it does not imply that a 
> > > > > > DDP
> > > > > > header creates no risks beyond an equivalent LLP-only 
> > application.
> > > 
> > > > > > For an LLP-only application transport buffers are always 
> > > > > > one-shot
> > > > > > and receive addresses in memory are determined by the 
> > receiver, 
> > > > > > not the sender.  If the WG were prepared to limit 
> > itself to this 
> > > > > > behavior by requiring that all STags be one-shot, then the 
> > > > > > position that there are no new security risks should be 
> > > > > > defensible.  The WG does not appear to be prepared to 
> > make this 
> > > > > > restriction.
> > > > > >
> > > > > > More importantly, relying on the "authorized by the ULP" 
> > > > > > assertion
> > > 
> > > > > > is not acceptable to the IESG.  That approach amounts to an
> > > > > > instruction to ULP developers not to use long-lived 
> > STags if they 
> > > > > > are a potential cause of security problems and also 
> > an instruction
> > > 
> > > > > > to users not to use ULPs that employ long-lived STags if
> > > > > > long-lived STags will cause security problems on 
> > their network(s).
> > > 
> > > > > > I've recently had to deal with another draft that tried this 
> > > > > > sort
> > > > > > of "don't use feature <X> if it will cause security problems" 
> > > > > > approach; the IESG rejected that approach, and the security 
> > > > > > considerations section of the draft had to be revised.
> > > > > >
> > > > > > The bottom line is that long-lived STags create additional 
> > > > > > memory
> > > > > > exposure that is not present in an equivalent LLP-only 
> > > > > > application.  The fact that the ULP chose to create 
> > the exposure 
> > > > > > does not absolve RDDP of providing security measures 
> > to deal with 
> > > > > > it.  IETF requires that protocols which create 
> > security issues 
> > > > > > deal with those security issues and not palm them off 
> > on other 
> > > > > > protocols (e.g., by asserting that all security 
> > issues created by 
> > > > > > long-lived RDDP STags are ULP problems because the 
> > ULP chose to 
> > > > > > use them).
> > > > > >
> > > > > > I've just updated and resubmitted 
> > draft-ietf-rddp-rdma-concerns
> > > > > > (will appear shortly as a -01
> > > > > > version) - it contains nearly 2-year-old text in its security 
> > > > > > considerations section pointing out this memory 
> > exposure issue.
> > > > > >
> > > > > > 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
> > > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > > 
> > > 
> > 
> > _______________________________________________
> > 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]>
Subject: RE: [rddp] IPsec and RDDP as a transport -- one-shot STags
From: "Carrier, John" <[email-masked]>
Date: Mon, 7 Jun 2004 13:50:51 -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: AcRMmll+SO9/89eiS7edYO9ZA3/w/gALbMQA
Thread-topic: [rddp] IPsec and RDDP as a transport

The "hole" being discussed occurs anytime DDP uses an STag to place data into a sink buffer in host memory (ie during RDMA Writes or RDMA Read Responses).  
 
As David & Caitlin have explained, with a 'persistent' STag, the ULP may begin using the buffer while the RNIC is overwriting the buffer with new data.   This new data doesn't have to come from a man-in-the-middle, it could be from the peer ULP too.  The problem is one of synchronization between the RNIC and peer ULP:  STag invalidation is the synchronization mechanism available at the RDDP layer. 

We already have 'send & invalidate' where the invalidated STag is contained in the payload of a message from the remote peer.  The RNIC reads the message header, extracts the STag, then invalidates the STag before providing the receive completion to the ULP.  

Caitlin's point is that the local ULP should be in control of the invalidation -- relying on the remote peer for invalidating the STag is too risky in a client-server environment where the server may have to deal with multiple client vendors & implementations.  Her proposal is to link the STag with a specific receive buffer.  The RNIC is to invalidate the STag when it consumes this specific untagged message buffer.  

Both of these proposals create a 'short-lived' or 'one-shot' STag that guarantees the invalidation of the STag before the ULP consumes the tagged buffer.  The remote peer may use the STag in multiple RDMAP messages, but signals that it is finished with the STag by sending an untagged message to the local peer.  This untagged message triggers the RNIC to invalidate the local STag.  

Neither of these proposals, however, deal with the synchronization between the RNIC and the local peer.  It is still possible for multiple RDMAP messages to target the same offset in the same sink buffer before the ULP sees it.

Another option is to restrict STags to a single RDMAP message and have the RNIC automatically invalidate the STag itself.  The RNIC is responsible for managing the STag state after the ULP registers a region or binds a window to the STag.  By default all 'valid' STags are 'one-shot' unless the ULP explicitly specifies that the STag is 'persistent'.  

  *  For 'one-shot' STags, the RNIC invalidates the local STag after it places the last DDP segment for the RDMAP message in host memory.  If another message from the remote peer requests the same STag, that RDMAP message would be rejected.  

  * For 'persistent' STags,  the RNIC does no STag invalidation unless instructed to do so by the ULP (explicitly by the local ULP or through a 'send & invalidate' message from the remote ULP).

With the RNIC in control of the STag invalidation, a sink buffer can only be written to once.   The question if this new mechanism breaks existing ULP usage models.  

--jc 

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

To: [email-masked]
Subject: [rddp] Long-lived Stags: Why?
From: [email-masked]
Date: Tue, 8 Jun 2004 00:37:32 -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]

Dwight,

> This compromize includes two components, one a successful spoofing of
> the transport layer, in which RDDP is no more or less vulernable (same
> transports) and a second component which is the demarcation point at
> which the ULP can be assured that the buffer is no longer available for
> modification by a remote peer. I believe that iSER has correctly
> addressed this issue (see John Hufferd's clarification). The Stag will
> be un-allocated before notification/completion of the SCSI command. 

iSER is one way to design/implement iSCSI over RDMA - it is not
the only one, and my posts were based on a different architectural
approach.  Nonetheless, the fact that iSER considers STag reuse to
be sufficiently dangerous that it applies several "MUST" requirements
to STag invalidation ought to be (IMHO) a visible nail in the coffin
of long-lived STags.

Would someone remind us why long-lived STag support should be retained
given the security pain and suffering it's causing (e.g., what is the
compelling use for this functionality)?  The simplest solution here
is to take it out, especially if there's no compelling use for it ...

Looking back over the list emails, the reasons I think I see for
long-lived STags are:

(1) Allow storage protocols to stage transfer based on available
	resources. (John Hufferd)  Also applies to HPC protocols like
	MPI. (Jim Pinkerton).
(2) Compatibility with InfiniBand. (John Hufferd)
(3) Avoid limiting flexibility. (Caitlin Bestler)
(4) Allow applications to innovate around long-lived STags.
	(Jim Pinkerton)

I believe that staged transfer (1) is compatible with a suitable
definition of "one-shot" STags - after completion of data transfer,
the buffer becomes not writable from the network before completion
is reported to the ULP application (there are details to be worked
out in the definition of "one-shot" that may impact the protocols).

I have a hard time with InfiniBand compatibility as a motivation
given the serious incompatibility between iSER and SRP (the native
SCSI encapsulation on InfiniBand).  Flexibility and innovation
in the absence of other compelling uses of long lived STag
functionality strike me as reasons to put the RDDP protocols (or
possibly the long-lived STag extensions to them) on the experimental
RFC track rather than the standards track (i.e., publish them as
Experimental RFCs rather than Proposed Standard) until the
compelling benefits that outweigh the security risks can
be demonstrated.

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 Barron, Dwight
> Sent: Monday, June 07, 2004 4:27 PM
> To: Somesh Gupta; Uri Elzur; rddp at ietf.org
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> This compromize includes two components, one a successful spoofing of
> the transport layer, in which RDDP is no more or less vulernable (same
> transports) and a second component which is the demarcation point at
> which the ULP can be assured that the buffer is no longer 
> available for
> modification by a remote peer. I believe that iSER has correctly
> addressed this issue (see John Hufferd's clarification). The Stag will
> be un-allocated before notification/completion of the SCSI command. 
> 
> Regards,
> Dwight
> 
> > -----Original Message-----
> > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> > Behalf Of Somesh Gupta
> > Sent: Monday, June 07, 2004 12:58 PM
> > To: Uri Elzur; rddp at ietf.org
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> > 
> > 
> > Uri,
> > 
> > With iSCSI, there is a delineation process on the byte
> > stream before processing the data. In other words,
> > if one packet or sequence of packets is injected by
> > the rogue, it will be detected because the delineation
> > process or CRC check or both will fail. There is one
> > exception to this which is if the attacker can also
> > predict the location of PDU header or data boundary in the 
> > byte stream at the same time.
> > 
> > However RDMA writes offers no such protection. Out of
> > order RDMA writes can be completed, corrupting data.
> > Even when the holes are filled and if there are mechanisms
> > to detect that there was mis-alignment of data,
> > the user is still Out of luck because the data may already
> > have been consumed.
> > 
> > Somesh

[.. remainder snipped ...]

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

To: [email-masked], [email-masked]
Subject: Re: [rddp] Long-lived Stags: Why?
From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 8 Jun 2004 02:09:12 -0500 (CDT)
Importance: Normal
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]
User-agent: SquirrelMail/1.4.2

Black_David at emc.com asked:

>
> Would someone remind us why long-lived STag support should be retained
> given the security pain and suffering it's causing (e.g., what is the
> compelling use for this functionality)?  The simplest solution here
> is to take it out, especially if there's no compelling use for it ...
>

In my opinion there is no justification for the most common use
of persistent STags: registering a global heap once, and then simply
using it. It leaves *all* validation of that buffer access is legitimate
to the ULP iteself. As you pointed out, even when there is no chance
of a man-in-the-middle attack, this practice is still highly vulnerable
to bugs.

There are however, numerous uses of STags that have a life cycle that
is not easily understood by the RDDP layer.

Generically, the Data Sink advertises a buffer. The Data Source updates
that buffer, and informs the Data Sink that it has completed doing so
with an untagged message.

In the most common case, which tagged buffer will be completed by
which untagged message is actually fully predictable by the local ULP.
This is where a "local Receive with Invalidate" verb would be the most
useful. The best example of this type of application would be DAFS.

The next case is where the Data Sink advertises a pool of buffers,
but the Data Source is free to choose which buffer to use with each
message. Typically this would involve transfers that vary in size,
and presumably the Data Source is selecting the target buffer based
on how big the requested file/asset/whatever turned out to be.

This is the model that the "Send with Invalidate" message was
designed to support (it also covers the simpler earlier case if
the Data Source is a good citizen and always uses Send with
Invalidate).

The third case would be where the Data Sink advertises a circular
buffer to deal with a variable rate transfer. The primary example
that comes to mind would be a streaming media transfer.
The sustained rate of the transfer, and hence the total buffer
size is quite predictable. But the amount that needs to be
transferred in any tenth of a second can vary considerably.

Further, existing application logic may already be accustomed
to "playing" the received content from a circular buffer, and
merely wants the transport to place the content in the buffer
and inform it of how far it is allowed to play.

The Data Sink cannot pre-designate an STag that matches
the nth untagged message because it does not know its size,
and because it wants it to follw the portion completed by
untagged message n-1.

WIth current verbs, such an application would have little choice
but to leave itself open to MITM attacks. One of my proposed
local interface enhancements would allow the Data Sink ULP
to shrink an STag without invalidating it. That would fully
address this type of application.

Beyond that, theoretically an STag *could* represent any
set of byte storage assets designated by the ULP.

Realistically, we all know that this must be a contiguous
range of bytes within a virtual address space. Some verbs
will essentially allow a virtual address space to be formed
out of physical pages to make a new virtual address space
that would not have otherwise existed, but a cautious ULP
designer would not rely on such a capability being available
(and if it is available, it will typicallly only be available to
highly privileged applications and/or kernel modules).

I believe we can ignore this set of applications, and in
describing the requirements for a secure local interface
simply leave a loop-hole for "those running in the kernel
or with full physical memory access are presumed to know
what they are doing".

I do not believe it is necessary for RDDP to *prevent* applications
from doing stupid things. It should be adequate to provide
adequate tools to enable the application to protect itself,
and to make sure that the application is not encouraged
to avoid these tools in any way. That is, by default, protection
must be enabled.

That said, once you get past the simplest STag life cycle,
I do not believe it is possible for the RDDP layer to detect
the difference between a valid, but complex, STag allocation
plan and a sloppy/lazy "we don't need no security here"
STag allocation plan.

This is much akin to the requirement for ULP flow control
on untagged messages. We can state that a ULP MUST have
it, but there is no way to enforce it at run-time. The only
effect of such statements is to encourage good design, and
perhaps constrain IETF approved ULP drafts to conform.

Also keep in mind, that the lazy/sloppy application that is
recklessly leaving STags open *is* exposing its own memory.

I believe that existing "custodian ULPs" that are exposing the
memory of *their* ULP rather than their own memory have
already specified proper use of non-persistent STags.

--
Caitlin Bestler
http://asomi.com/

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

To: "Caitlin Bestler" <[email-masked]>
Subject: Re: [rddp] Long-lived Stags: Why?
From: John Hufferd <[email-masked]>
Date: Tue, 8 Jun 2004 00:46:57 -0700
Cc: Black_David at emc.com, rddp at ietf.org
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>
Sender: [email-masked]

Just one caution here, I am not sure you really meant "Receive with invalidate" but I think that might be problematical with Shared Receive Queue (SRQ).

Also I think I agree that unless the HW or OS enforces an invalidate after each simple operation, which I strongly disagree with since it would not match many "transaction" models, I do not see how the HW or the OS, can enforce the invalidation after each "transaction".  And if neither the HW or the OS can enforce it, I am not sure what the words should say, and how compliance could be certified.  Further, I am not certain that I understand the full purpose of the words, in that case, what ever they are.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd at us.ibm.com

"Caitlin Bestler" <cait at asomi.com>
Sent by: rddp-bounces at ietf.org

06/08/2004 12:09 AM
To
Black_David at emc.com, rddp at ietf.org
cc
Subject
Re: [rddp] Long-lived Stags: Why?

Black_David at emc.com asked:

>
> Would someone remind us why long-lived STag support should be retained
> given the security pain and suffering it's causing (e.g., what is the
> compelling use for this functionality)?  The simplest solution here
> is to take it out, especially if there's no compelling use for it ...
>

In my opinion there is no justification for the most common use
of persistent STags: registering a global heap once, and then simply
using it. It leaves *all* validation of that buffer access is legitimate
to the ULP iteself. As you pointed out, even when there is no chance
of a man-in-the-middle attack, this practice is still highly vulnerable
to bugs.

There are however, numerous uses of STags that have a life cycle that
is not easily understood by the RDDP layer.

Generically, the Data Sink advertises a buffer. The Data Source updates
that buffer, and informs the Data Sink that it has completed doing so
with an untagged message.

In the most common case, which tagged buffer will be completed by
which untagged message is actually fully predictable by the local ULP.
This is where a "local Receive with Invalidate" verb would be the most
useful. The best example of this type of application would be DAFS.

The next case is where the Data Sink advertises a pool of buffers,
but the Data Source is free to choose which buffer to use with each
message. Typically this would involve transfers that vary in size,
and presumably the Data Source is selecting the target buffer based
on how big the requested file/asset/whatever turned out to be.

This is the model that the "Send with Invalidate" message was
designed to support (it also covers the simpler earlier case if
the Data Source is a good citizen and always uses Send with
Invalidate).

The third case would be where the Data Sink advertises a circular
buffer to deal with a variable rate transfer. The primary example
that comes to mind would be a streaming media transfer.
The sustained rate of the transfer, and hence the total buffer
size is quite predictable. But the amount that needs to be
transferred in any tenth of a second can vary considerably.

Further, existing application logic may already be accustomed
to "playing" the received content from a circular buffer, and
merely wants the transport to place the content in the buffer
and inform it of how far it is allowed to play.

The Data Sink cannot pre-designate an STag that matches
the nth untagged message because it does not know its size,
and because it wants it to follw the portion completed by
untagged message n-1.

WIth current verbs, such an application would have little choice
but to leave itself open to MITM attacks. One of my proposed
local interface enhancements would allow the Data Sink ULP
to shrink an STag without invalidating it. That would fully
address this type of application.

Beyond that, theoretically an STag *could* represent any
set of byte storage assets designated by the ULP.

Realistically, we all know that this must be a contiguous
range of bytes within a virtual address space. Some verbs
will essentially allow a virtual address space to be formed
out of physical pages to make a new virtual address space
that would not have otherwise existed, but a cautious ULP
designer would not rely on such a capability being available
(and if it is available, it will typicallly only be available to
highly privileged applications and/or kernel modules).

I believe we can ignore this set of applications, and in
describing the requirements for a secure local interface
simply leave a loop-hole for "those running in the kernel
or with full physical memory access are presumed to know
what they are doing".

I do not believe it is necessary for RDDP to *prevent* applications
from doing stupid things. It should be adequate to provide
adequate tools to enable the application to protect itself,
and to make sure that the application is not encouraged
to avoid these tools in any way. That is, by default, protection
must be enabled.

That said, once you get past the simplest STag life cycle,
I do not believe it is possible for the RDDP layer to detect
the difference between a valid, but complex, STag allocation
plan and a sloppy/lazy "we don't need no security here"
STag allocation plan.

This is much akin to the requirement for ULP flow control
on untagged messages. We can state that a ULP MUST have
it, but there is no way to enforce it at run-time. The only
effect of such statements is to encourage good design, and
perhaps constrain IETF approved ULP drafts to conform.

Also keep in mind, that the lazy/sloppy application that is
recklessly leaving STags open *is* exposing its own memory.

I believe that existing "custodian ULPs" that are exposing the
memory of *their* ULP rather than their own memory have
already specified proper use of non-persistent STags.

--
Caitlin Bestler
http://asomi.com/

_______________________________________________
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: "John Hufferd" <[email-masked]>
Subject: Re: [rddp] Long-lived Stags: Why?
From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 8 Jun 2004 04:05:34 -0500 (CDT)
Cc: black_david at emc.com, rddp at ietf.org
Importance: Normal
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]> <[email-masked]>
Sender: [email-masked]
User-agent: SquirrelMail/1.4.2

John Hufferd said:
> Just one caution here, I am not sure you really meant "Receive with
> invalidate" but I think that might be problematical with Shared Receive
> Queue (SRQ).
>

Yes it would require that a "Receive Operation" be posted to the QP
that had the SRQ, but the Receive Operation would only provide the
authorization to receive and indicate the desire to invalidate -- it
would not supply an untagged buffer. That would still come from the SRQ.

Alternately, this "QP-with-SRQ receive operation" could actually be
a queue for a shim layer, which would simply match completions
based upon the QP and perform any required invalidation. It could
also ex-post-facto notice excessive completions and trigger an
automatic response -- dealing with the already idenfitifed security
vulnerability for shared resource queues.

> Also I think I agree that unless the HW or OS enforces an invalidate after
> each simple operation, which I strongly disagree with since it would not
> match many "transaction" models, I do not see how the HW or the OS, can
> enforce the invalidation after each "transaction".  And if neither the HW
> or the OS can enforce it, I am not sure what the words should say, and how
> compliance could be certified.  Further, I am not certain that I
> understand the full purpose of the words, in that case, what ever they
> are.
> .

A "transaction" is not a transaction until the Data Sink reaps a completion.
All time between completions is an area of quantum uncertainty. The
application should not be processing the associated tagged buffer
until its availability has been communicated through a ULP speciific
mechanism that *must* involve a completion over the same DDP stream.

The hardware cannot enforce such rules. Like ULP flow control, it can
only enable compliant ULPs to do so easily.

What is proposed are improvements to the local interface which would
make proper usage of these tools the default, so the applications would
inadvertantly leave themselves vulnerable.

The key is that the Data Sink ULP will not apply its own validation
to the buffer until *after* the STag exposure for it has been eliminated.
Now obviously, hardware will not run around trying to ensure that a
different STag has exposed the same buffer any more than C run-time
libraries check to make sure that a destination buffer isn't the stack
location that marks the return from the call.

Applications that insist on doing very stupid things can already kill
themselves in numerous ways, this is not a *new* vulnerability.

But neglecting to check that your peer invalidated an STag in its
response, or even leaving it open to use "next time" is something
a developer new to RDMA could easily do without understanding
the consequences. What is suggested is that the local interface
MUST NOT/SHOULD NOT make such practices the default.

Appications that wish to post the kernel stack as the target
of an RDMA Read cannot expect the RNIC to stop them.

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

To: "Barron, Dwight" <[email-masked]>
Subject: RE: [rddp] IPsec and RDDP as a transport
From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 8 Jun 2004 06:04:36 -0500 (CDT)
Cc: rddp at ietf.org
Importance: Normal
In-reply-to: <[email-masked] t>
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]
User-agent: SquirrelMail/1.4.2

Barron, Dwight said:
> Caitlin wrote:
>> > Or more generally, a buffer that the application intends to use is
>> > still exposed to update from non-authenticated DDP packets.
>>
> David Black responded:
>> The latter is the better statement of the vulnerability, as
>> it includes man-in-the-middle traffic injection, e.g., via a
>> connection hijack.
>
> Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP, MPI)
> and ad-hoc applications in determining responsibility of implementing
> protocol behaviors that do not leave themselves vulnerable? I believe it
> is quite innoccuous and appropriate to require that IETF (or other)
> ULPs be designed in a matter that does not notify ULP consumers of
> available data while an Stag is still mapped to that data. Both remote
> and local Stag invalidations are envisioned to be very
> lightweight operations. I also believe that the vast majority of data
> movement and usage of DDP will occur through these and other
> defined ULPs.
>

The difference between NFS/iSER/SDP/DAFS/MPI/etc and a specialty
application is intuitively obvious, but I'm not sure how you would
phrase it in a draft.

For one thing, the RDMAP/DDP local interface has no way to validate
that the Consumer calling it is an implementation of a protocol that
supplies its own IETF-compliant security procedures beyond putting
a comment in the header file saying "don't use this routine unless..."

So ultimately I think this an example of why we should be concentrating
on *enabling* the ULP to protect its own buffers rather than *preventing*
the ULP from doing things, and then making sure that a decision *not*
to use these tools is based on a true lack of need (I'm solving it myself)
rather than lack of understanding or laziness ("oh, I was supposed to
invalidate the STag? Why bother, I'll be exiting after two more iterations
anyway.")

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

To: [email-masked]
Subject: Re: [rddp] Long-lived Stags: Why?
From: Michael Krause <[email-masked]>
Date: Tue, 08 Jun 2004 07:06:39 -0700
In-reply-to: <[email-masked] om>
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]

At 09:37 PM 6/7/2004, Black_David at emc.com wrote:

Dwight,

> This compromize includes two components, one a successful spoofing of
> the transport layer, in which RDDP is no more or less vulernable (same
> transports) and a second component which is the demarcation point at
> which the ULP can be assured that the buffer is no longer available for
> modification by a remote peer. I believe that iSER has correctly
> addressed this issue (see John Hufferd's clarification). The Stag will
> be un-allocated before notification/completion of the SCSI command.

iSER is one way to design/implement iSCSI over RDMA - it is not
the only one, and my posts were based on a different architectural
approach.  Nonetheless, the fact that iSER considers STag reuse to
be sufficiently dangerous that it applies several "MUST" requirements
to STag invalidation ought to be (IMHO) a visible nail in the coffin
of long-lived STags.

Would someone remind us why long-lived STag support should be retained
given the security pain and suffering it's causing (e.g., what is the
compelling use for this functionality)?  The simplest solution here
is to take it out, especially if there's no compelling use for it ...

Looking back over the list emails, the reasons I think I see for
long-lived STags are:

(1) Allow storage protocols to stage transfer based on available
        resources. (John Hufferd)  Also applies to HPC protocols like
        MPI. (Jim Pinkerton).
(2) Compatibility with InfiniBand. (John Hufferd)
(3) Avoid limiting flexibility. (Caitlin Bestler)
(4) Allow applications to innovate around long-lived STags.
        (Jim Pinkerton)

Add my name and I'm sure many others who have spoken up about this issue to all of these values.

I believe that staged transfer (1) is compatible with a suitable
definition of "one-shot" STags - after completion of data transfer,
the buffer becomes not writable from the network before completion
is reported to the ULP application (there are details to be worked
out in the definition of "one-shot" that may impact the protocols).

I have a hard time with InfiniBand compatibility as a motivation
given the serious incompatibility between iSER and SRP (the native
SCSI encapsulation on InfiniBand).

There is an effort within an open source group to provide iSCSI and iSCSI / iSER over InfiniBand. These are already well underway.

As for compatibility with InfiniBand, need to keep in mind that much of the existing ULP that use RDMA as well as many user applications already operate over InfiniBand. Various OSV already have a solid RDMA infrastructure capable of supporting InfiniBand. Many ISV have products already using InfiniBand. In general, there is a reasonably sized and solid ecosystem that supports the InfiniBand operational semantics which were used as the basis for RDDP semantics. The basic RDDP semantics have been incorporated back into InfiniBand as well enabling the industry to have a single set that semantics that are interconnect independent. As such, it would be very bad for the industry and customers to state compatibility with InfiniBand (an interconnect that is recognized and has associated IETF specifications) as insufficient motivation based solely on SRP / iSER compatibility.

    Flexibility and innovation in the absence of other compelling uses of long lived STag functionality strike me as reasons to put the RDDP protocols (or possibly the long-lived STag extensions to them) on the experimental RFC track rather than the standards track (i.e., publish them as Experimental RFCs rather than Proposed Standard) until the compelling benefits that outweigh the security risks can
    be demonstrated. 

This is just coming down to whether to mandate IPSec or not and proceed with the existing specifications through the standards track. I don't think we are to the point of just tossing the specs to experimental over this one question.

Mike

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

To: [email-masked]
Subject: Re: [rddp] Long-lived Stags: Why?
From: John Hufferd <[email-masked]>
Date: Tue, 8 Jun 2004 11:05:37 -0700
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>
Sender: [email-masked]

My statements about InfiniBand were targeted at the exact point that Michael makes below.  There is a lot of industry work going on to use iSCSI and the infrastructure around it on InfiniBand.  That work is focused on taking the iSCSI/iSER and having it operate on InfiniBand, so that we do not have to reinvent all the management and discovery stuff on InfiniBand for use by SRP (especially since iSCSI/iSER has more capabilities than SRP).

SRP is NOT an "Official" InfiniBand Architecture, but is an IEEE thing and the folks that have defined the InfiniBand Spec only refer to SRP as an "Example" of a storage protocol on InfiniBand.

With respect to the point here however, the reason that I was concerned about the InfiniBand was that most of the RDMA/iWARP operations can be directly mapped against InfiniBand, and therefore we only need to have single versions of applications that can operate on both RDMA/iWARP and InfiniBand.  However, I was worried that if this "Single Shot" discussion got going such that the RNIC was expected to automatically invalidate an STag when ever it received or extracted data, significant incompatibilities would exist between RDMA/iWARP and InfiniBand which have otherwise been resolved.

If we are moving away from any such consideration for the RNIC, then this whole issue of RDMA/iWARP can be put aside and handled in what ever other venue's that are approprate.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd at us.ibm.com

Michael Krause <krause at cup.hp.com>
Sent by: rddp-bounces at ietf.org

06/08/2004 07:06 AM
To
rddp at ietf.org
cc
Subject
Re: [rddp] Long-lived Stags: Why?

At 09:37 PM 6/7/2004, Black_David at emc.com wrote:
>Dwight,
>
> > This compromize includes two components, one a successful spoofing of
> > the transport layer, in which RDDP is no more or less vulernable (same
> > transports) and a second component which is the demarcation point at
> > which the ULP can be assured that the buffer is no longer available for
> > modification by a remote peer. I believe that iSER has correctly
> > addressed this issue (see John Hufferd's clarification). The Stag will
> > be un-allocated before notification/completion of the SCSI command.
>
>iSER is one way to design/implement iSCSI over RDMA - it is not
>the only one, and my posts were based on a different architectural
>approach.  Nonetheless, the fact that iSER considers STag reuse to
>be sufficiently dangerous that it applies several "MUST" requirements
>to STag invalidation ought to be (IMHO) a visible nail in the coffin
>of long-lived STags.
>
>Would someone remind us why long-lived STag support should be retained
>given the security pain and suffering it's causing (e.g., what is the
>compelling use for this functionality)?  The simplest solution here
>is to take it out, especially if there's no compelling use for it ...
>
>Looking back over the list emails, the reasons I think I see for
>long-lived STags are:
>
>(1) Allow storage protocols to stage transfer based on available
>         resources. (John Hufferd)  Also applies to HPC protocols like
>         MPI. (Jim Pinkerton).
>(2) Compatibility with InfiniBand. (John Hufferd)
>(3) Avoid limiting flexibility. (Caitlin Bestler)
>(4) Allow applications to innovate around long-lived STags.
>         (Jim Pinkerton)

Add my name and I'm sure many others who have spoken up about this issue to
all of these values.

>I believe that staged transfer (1) is compatible with a suitable
>definition of "one-shot" STags - after completion of data transfer,
>the buffer becomes not writable from the network before completion
>is reported to the ULP application (there are details to be worked
>out in the definition of "one-shot" that may impact the protocols).
>
>I have a hard time with InfiniBand compatibility as a motivation
>given the serious incompatibility between iSER and SRP (the native
>SCSI encapsulation on InfiniBand).

There is an effort within an open source group to provide iSCSI and iSCSI /
iSER over InfiniBand.  These are already well underway.

As for compatibility with InfiniBand, need to keep in mind that much of the
existing ULP that use RDMA as well as many user applications already
operate over InfiniBand.  Various OSV already have a solid RDMA
infrastructure capable of supporting InfiniBand.  Many ISV have products
already using InfiniBand.  In general, there is a reasonably sized and
solid ecosystem that supports the InfiniBand operational semantics which
were used as the basis for RDDP semantics.  The basic RDDP semantics have
been incorporated back into InfiniBand as well enabling the industry to
have a single set that semantics that are interconnect independent.  As
such, it would be very bad for the industry and customers to state
compatibility with InfiniBand (an interconnect that is recognized and has
associated IETF specifications) as insufficient motivation based solely on
SRP / iSER compatibility.

>Flexibility and innovation in the absence of other compelling uses of long
>lived STag functionality strike me as reasons to put the RDDP protocols
>(or possibly the long-lived STag extensions to them) on the experimental
>RFC track rather than the standards track (i.e., publish them as
>Experimental RFCs rather than Proposed Standard) until the compelling
>benefits that outweigh the security risks can
>be demonstrated.

This is just coming down to whether to mandate IPSec or not and proceed
with the existing specifications through the standards track.  I don't
think we are to the point of just tossing the specs to experimental over
this one question.

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]
Subject: [rddp] Why IPsec is needed for iSCSI but might not be needed for RDDP/iWARP
From: John Hufferd <[email-masked]>
Date: Tue, 8 Jun 2004 11:54:41 -0700
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]

David,

Perhaps you could explain again for me and perhaps some other "dense" folks why IPsec would be a MUST implement (but optional to use) for iSCSI but we are attempting to not say similar things for RDMA/iWARP.

I am not pushing an agenda here, I know that if we do not need IPsec for RDMA/iWARP on clusters and other such reasonably secure environments, the requirements of IPsec as a MUST implement in all cases will NOT be approprate.  (And often the RNIC used for such clustering environment is on its own Subnet and not part of a general communication network.) But I also feel that when RNICs are used on less secure environments, that the environment looks similar to iSCSI.  Perhaps even less secure because of the RNIC holding the placement open to a storage location were with HW iSCSI, the direct placement and the protocol are closely combined so that Buffers are not left open for the intruder (at least not as much).

So based on the above thoughts, I am not sure why it was required for iSCSI to use IPsec (when iSCSI HW is more secure than RNICs) and not an issue for RDMA/iWARP.

I get (but do not buy) the arguments that RDMA/iWARP is just using the TCP/IP (or SCTP) and as such does not need any other protection that is given to that, but then so was iSCSI.

So your thoughts about why it would be needed in one and not the other would be of interest.  Since I do not see that a solution for protecting the Buffers (single shot or what ever) changes the issue of why iSCSI and not RDMA/iWARP.  If we protect the Buffers, then the results will have a similar profile to iSCSI.  So that alone can not be a full solution.

If your position is that it is needed for both regardless of the buffer protection, and you are suggesting that we might come up with something that handles "authentication" at the DDP layer via Cryptographic approaches as a possible approach to meeting the need, then I can understand the logic as far as it goes.  But you have not said anything about the need for Privacy (Encryption).  I thought that was also an important consideration.  

Anyway, perhaps you could address the above, and help clarify the issues for some of us.

Also as a second point, does it make since to attempt to define environments where RDMA/iWARP would be approprate without the additional Cryptographic or IPsec implementations (such as within clusters on their own physical subnets, etc.), and then require IPsec in other less secure environments?

.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd at us.ibm.com

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

To: [email-masked]
Subject: RE: [rddp] Why IPsec is needed for iSCSI but might not be needed for RDDP/iWARP
From: [email-masked]
Date: Wed, 9 Jun 2004 00:32:53 -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]

John,

> Perhaps you could explain again for me and perhaps some other "dense"
> folks why IPsec would be a MUST implement (but optional to use) for
> iSCSI but we are attempting to not say similar things for RDMA/iWARP.

iSCSI is responsible for its data - there is no ULP further up the stack
that is in a position to handle the security issues addressed by IPsec.
In contrast, I'm prepared to advocate on behalf of the WG that RDDP is
a transport used by a ULP, and as such the ULP bears the primary
responsibility for specifying and meeting the security requirements of
the ULP's data; we'll have to see how that fares.  I'm not promising
success in getting this distinction accepted, but I think there's enough
technical merit that it would be irresponsible of me to dismiss this
out of hand.  Depending on the ULP, IPsec could still being required - for
example, iSCSI over RDDP will probably need to require IPsec for iSCSI 
reasons.

> I am not pushing an agenda here, I know that if we do not need IPsec
> for RDMA/iWARP on clusters and other such reasonably secure environments,
> the requirements of IPsec as a MUST implement in all cases will NOT be
> appropriate.  (And often the RNIC used for such clustering environment
> is on its own Subnet and not part of a general communication network.)
> But I also feel that when RNICs are used on less secure environments,
> that the environment looks similar to iSCSI.  Perhaps even less secure
> because of the RNIC holding the placement open to a storage location
> were with HW iSCSI, the direct placement and the protocol are closely
> combined so that Buffers are not left open for the intruder (at least
> not as much).

IETF RFCs are written for "less secure environments" like the public
Internet.  If an implementer wants to take liberties with the security
requirements of an RFC for use in a "reasonably secure environment",
that implementer does so without the IETF's approval, and cannot point
to the IETF as justification when that insecure implementation is used
in a less secure environment and is compromised by a foreseeable attack.

> So based on the above thoughts, I am not sure why it was required for
> iSCSI to use IPsec (when iSCSI HW is more secure than RNICs) and not
> an issue for RDMA/iWARP. 
> 
> I get (but do not buy) the arguments that RDMA/iWARP is just using the
> TCP/IP (or SCTP) and as such does not need any other protection that
> is given to that, but then so was iSCSI.

The key issue is not what's below the protocol, but what's above it -
there's no ULP above iSCSI that can protect iSCSI's data (for data
transfer, the next layer up is SAM-2, which is not a protocol).  A
similar line of reasoning was successful in avoiding a requirement to
add inband authentication to IPS's FC protocols - that is better done
at the higher FC level (and in fact T11 is working on this).

> So your thoughts about why it would be needed in one and not the other
> would be of interest.  Since I do not see that a solution for protecting
> the Buffers (single shot or what ever) changes the issue of why iSCSI
> and not RDMA/iWARP.  If we protect the Buffers, then the results will
> have a similar profile to iSCSI.  So that alone can not be a full
> solution.

I think there will need to be a resolution of the local interface
requirements from the "single shot" discussion, as they are the only
mechanism available to protect a server against a malicious client
that can successfully authenticate.

> If your position is that it is needed for both regardless of the buffer
> protection, and you are suggesting that we might come up with something
> that handles "authentication" at the DDP layer via Cryptographic
> approaches as a possible approach to meeting the need, then I can
> understand the logic as far as it goes.  But you have not said anything
> about the need for Privacy (Encryption).  I thought that was also an
> important consideration.

Whether it's going to be needed regardless of buffer protection remains
to be seen, as I don't know how strong the eventual local interface buffer
protection requirements are going to be - that discussion does not appear
to have concluded.

> But you have not said anything about the need
> for Privacy (Encryption).  I thought that was also an important
consideration.

Confidentiality (e.g., via encryption) is important for RDDP's placed data.
It is not clear to me that the RDDP headers require confidentiality,
although
we may wind up with a requirement that STags be randomly generated in some
fashion  (and an optional means of providing "authentication" of the RDDP
headers could meet this requirement).  Again, this depends in some fashion
on the buffer protection discussion outcome.

> Anyway, perhaps you could address the above, and help clarify the issues
> for some of us.

Here's an attempt to summarize my current view of this:

(1) Something needs to be done in the area of buffer protection
	requirements, because:
	- Support for long-lived STags makes it too easy to expose
		received data to further modification after delivery
		to the ULP.
	- Unlike cryptographic mechanisms (including IPsec), buffer
		protection can protect against a malicious client that
		can successfully authenticate.
	I don't think strict single-shot (each RDDP operation always
	invalidates the associated STag) is necessary, but the
	strength of what is done here may affect what is necessary
	elsewhere - see (3).
(2) The "RDDP is a transport" approach that makes ULPs responsible
	for specifying security requirements for ULP data appears to
	be worth pursuing.  I can't promise success, but I would be
	remiss in not trying.  If this approach fails, "MUST implement
	IPsec" is the most likely result.
(3) If the "RDDP is a transport" approach is accepted, then RDDP is
	responsible for preventing misuse of the RDDP headers.  There
	are several possibilities here:
	- The buffer protection requirements from (1) could be strong
		enough to reduce any possible misuse to that which can
		be attempted against a transport like SCTP.  This could be
		accompanied by a requirement for randomly generate STag
		values.
	- A "MUST implement" RDDP security header could be defined to
		block replay, connection hijacking, and other man-in-the-
		middle attacks.
	- "MUST implement IPsec" is sufficient, but probably more
		mechanism than is necessary in this situation.

At the moment, I think I see WG rough consensus to try (2), although
anyone is welcome to try to convince me otherwise.  OTOH, the WG should
consider itself instructed to do something about (1) [local interface
requirements for buffer protection].  In addition to the above, another
reason for this is in response to something Dwight asked earlier:

> Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP, MPI)
> and ad-hoc applications in determining responsibility of implementing
> protocol behaviors that do not leave themselves vulnerable? I believe it
> is quite innoccuous and appropriate to require that IETF (or other)
> ULPs be designed in a matter that does not notify ULP consumers of
> available data while an Stag is still mapped to that data.

The distinction that concerns me is that the defined ULPs are being
specified by very talented RDDP experts.  If it takes that level of
expertise to get STag invalidation right in order to avoid memory
exposure security holes, RDDP will not be a mechanism that will be
generally usable in a safe fashion.  In essence, I am not convinced
of Dwight's "innocuous and appropriate" statement above,
because I worry that meeting the requirement requires application
of an unusual level of talent/expertise in the absence of doing
something better in the area of "buffer protection", although I'm
sure Dwight has that level of talent/expertise.

Returning to John's final point:

> Also as a second point, does it make since to attempt to define
environments
> where RDMA/iWARP would be approprate without the additional Cryptographic
or
> IPsec implementations (such as within clusters on their own physical
subnets,
> etc.), and then require IPsec in other less secure environments? 

** NO ** !!!  This was tried for one of the IPS protocols at the London
IESG plenary not too long ago and it went down in flames ... 

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: John Hufferd <[email-masked]>, RDDP <[email-masked]>
Subject: Re: [rddp] Why IPsec is needed for iSCSI but might not be needed for RDDP/iWARP
From: Caitlin Bestler <[email-masked]>
Date: Wed, 9 Jun 2004 10:05:15 -0500
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 Jun 8, 2004, at 1:54 PM, John Hufferd wrote:

David,

    Perhaps you could explain again for me and perhaps some other "dense" folks why
    IPsec would be a MUST implement (but optional to use) for iSCSI but we are
    attempting to not say similar things for RDMA/iWARP.

There are several valid distinctions between RDDP and iSCSI. David's
response detailed one. Some others:

- iSCSI as a new protocol is replacing non-IP networks and/or direct
  connections. The security vulnerabilities inherent in IP are therefore
  totally new. RDDP is an enhancement layer to the transport, it is
  replacing/enhancing that existing transport. Therefore it is only
  responsible for the security vulnerabilities that it *adds*.

  If it was unsuitable for an application to run over unsecure TCP,
  it will remain unsuitable for it to run over unsecure RDDP.

- It is difficult to imagine a scenario where tampering with
  iSCSI payload would not have an adverse potentially persistent
  impact. RDDP could be used by ULP that are immune to any
  persistent side affects from data tampering. Successfully
  inserting data into a real-time voice transimission, for
  example, is highly unlikely to do anything more than generate
  noise or perhaps force a disconnection (and a MITM-attacker
  can always force a disconnection even with authentication).

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

To: RDDP <[email-masked]>, John Hufferd <[email-masked]>
Subject: Re: [rddp] Why IPsec is needed for iSCSI but might not be needed for RDDP/iWARP
From: Caitlin Bestler <[email-masked]>
Date: Wed, 9 Jun 2004 10:32:56 -0500
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 Jun 8, 2004, at 11:32 PM, Black_David at emc.com wrote:

But you have not said anything about the need
for Privacy (Encryption).  I thought that was also an important
consideration.

    Confidentiality (e.g., via encryption) is important for RDDP's placed data.
    It is not clear to me that the RDDP headers require confidentiality,
    although we may wind up with a requirement that STags be randomly generated
    in some fashion (and an optional means of providing "authentication" of the RDDP
    headers could meet this requirement). Again, this depends in some fashion
    on the buffer protection discussion outcome. 

Confidentiality is a ULP issue. Any rationale for use of IPsec
is Authentication, not privacy.

I believe a fair summation would be that the RDDP Consumer must
be able to protect against unauthenticated updates of untagged
buffers it has taken delivery of.

There are two methods of doing this:

-- local interface enhancements that allow the RDDP Consumer to
   protect against *any* access to an untagged buffer that it
   taken delivery of, authenticated or not. This provides increases
   robustness in the face of client errors, or even in the face of
   clients that are deliberately attacking but are relying on the
   being relatively anonymous because some servers accept connections
   from a very wide number of potential clients running diverse
   implementations.

-- authentication the DDP packets, providing protection against
   un-authenticated updates even while the Data Sink is receiving data.

   Within the latter option there is technically a choice between
   authentication at the IP layer or authenticating the RDDP header
   itself. I do not believe there is *any* interest in the latter
   approach at this time.

I think it should also be emphasized, that which security enhancement
is specified, it is a relatively minor change (although it might be
expensive in the case of IPsec). It is *not* starting over from scratch
or anything like that.

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

To: RDDP <[email-masked]>
Subject: Re: [rddp] Why IPsec is needed for iSCSI but might not be needed for RDDP/iWARP
From: Caitlin Bestler <[email-masked]>
Date: Wed, 9 Jun 2004 12:04:34 -0500
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]> <[email-masked]>
Sender: [email-masked]

On Jun 9, 2004, at 10:32 AM, Caitlin Bestler wrote:

On Jun 8, 2004, at 11:32 PM, Black_David at emc.com wrote:

But you have not said anything about the need
for Privacy (Encryption).  I thought that was also an important
consideration.

        Confidentiality (e.g., via encryption) is important for RDDP's placed data.
        It is not clear to me that the RDDP headers require confidentiality,
        although we may wind up with a requirement that STags be randomly generated
        in some fashion (and an optional means of providing "authentication" of the RDDP
        headers could meet this requirement). Again, this depends in some fashion
        on the buffer protection discussion outcome. 

Confidentiality is a ULP issue. Any rationale for use of IPsec
is Authentication, not privacy.

I believe a fair summation would be that the RDDP Consumer must
be able to protect against unauthenticated updates of untagged
buffers it has taken delivery of.

Oops, that's of *tagged* buffers -- I should be more careful when
posting right after transatlantic flights.

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

To: <[email-masked]>
Subject: RE: [rddp] Why IPsec is needed for iSCSI but might not be needed for RDDP/iWARP
From: "Barron, Dwight" <[email-masked]>
Date: Wed, 9 Jun 2004 14:15:27 -0500
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]
Thread-index: AcRN3i1N3LSzUDBnRHOVNmLXi9yi/QAc1OXA
Thread-topic: [rddp] Why IPsec is needed for iSCSI but might not be needed for RDDP/iWARP

David,
Thanks for the effort in trying number 2 below, but several private
conversations have convinced me that mandatory IPSEC may not be so bad
after all. There are really three facets to the argument.  

- The first is the desire to err on the conservative side when it comes
to security. IPSEC clearly does that. The header remedies suggested in
your item 3, along with one-shot Stags, are attempts to deal with the
threats as we identify them, while IPSEC effectively deals with threats
we haven't yet identified.
- The second is the more pragmatic thought of the iSCSI scenario
repeating itself in the market and implementations manifest without
IPSEC enabled.  Well designed ULPs will represent the bulk of the
traffic and won't be exposing known holes. This is not an attempt to
encourage this behavior, but rather to make sure are not remiss in
anticipating it.
- Finally, the thought of eliminating long lived Stags defeats one of
the primary benefits of RDDP, which is to publish access to memory with
as little CPU overhead as possible. 

Regards,
Dwight

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of Black_David at emc.com
> Sent: Tuesday, June 08, 2004 11:33 PM
> To: hufferd at us.ibm.com
> Cc: rddp at ietf.org
> Subject: RE: [rddp] Why IPsec is needed for iSCSI but might 
> not be needed for RDDP/iWARP
> 
> 
> John,
> 
> > Perhaps you could explain again for me and perhaps some 
> other "dense" 
> > folks why IPsec would be a MUST implement (but optional to use) for 
> > iSCSI but we are attempting to not say similar things for 
> RDMA/iWARP.
> 
> iSCSI is responsible for its data - there is no ULP further 
> up the stack that is in a position to handle the security 
> issues addressed by IPsec. In contrast, I'm prepared to 
> advocate on behalf of the WG that RDDP is a transport used by 
> a ULP, and as such the ULP bears the primary responsibility 
> for specifying and meeting the security requirements of the 
> ULP's data; we'll have to see how that fares.  I'm not 
> promising success in getting this distinction accepted, but I 
> think there's enough technical merit that it would be 
> irresponsible of me to dismiss this out of hand.  Depending 
> on the ULP, IPsec could still being required - for example, 
> iSCSI over RDDP will probably need to require IPsec for iSCSI 
> reasons.
> 
> > I am not pushing an agenda here, I know that if we do not 
> need IPsec 
> > for RDMA/iWARP on clusters and other such reasonably secure 
> > environments, the requirements of IPsec as a MUST implement in all 
> > cases will NOT be appropriate.  (And often the RNIC used for such 
> > clustering environment is on its own Subnet and not part of 
> a general 
> > communication network.) But I also feel that when RNICs are used on 
> > less secure environments, that the environment looks 
> similar to iSCSI.  
> > Perhaps even less secure because of the RNIC holding the placement 
> > open to a storage location were with HW iSCSI, the direct placement 
> > and the protocol are closely combined so that Buffers are not left 
> > open for the intruder (at least not as much).
> 
> IETF RFCs are written for "less secure environments" like the 
> public Internet.  If an implementer wants to take liberties 
> with the security requirements of an RFC for use in a 
> "reasonably secure environment", that implementer does so 
> without the IETF's approval, and cannot point to the IETF as 
> justification when that insecure implementation is used in a 
> less secure environment and is compromised by a foreseeable attack.
> 
> > So based on the above thoughts, I am not sure why it was 
> required for 
> > iSCSI to use IPsec (when iSCSI HW is more secure than 
> RNICs) and not 
> > an issue for RDMA/iWARP.
> > 
> > I get (but do not buy) the arguments that RDMA/iWARP is 
> just using the 
> > TCP/IP (or SCTP) and as such does not need any other 
> protection that 
> > is given to that, but then so was iSCSI.
> 
> The key issue is not what's below the protocol, but what's 
> above it - there's no ULP above iSCSI that can protect 
> iSCSI's data (for data transfer, the next layer up is SAM-2, 
> which is not a protocol).  A similar line of reasoning was 
> successful in avoiding a requirement to add inband 
> authentication to IPS's FC protocols - that is better done at 
> the higher FC level (and in fact T11 is working on this).
> 
> > So your thoughts about why it would be needed in one and 
> not the other 
> > would be of interest.  Since I do not see that a solution for 
> > protecting the Buffers (single shot or what ever) changes 
> the issue of 
> > why iSCSI and not RDMA/iWARP.  If we protect the Buffers, then the 
> > results will have a similar profile to iSCSI.  So that 
> alone can not 
> > be a full solution.
> 
> I think there will need to be a resolution of the local 
> interface requirements from the "single shot" discussion, as 
> they are the only mechanism available to protect a server 
> against a malicious client that can successfully authenticate.
> 
> > If your position is that it is needed for both regardless of the 
> > buffer protection, and you are suggesting that we might 
> come up with 
> > something that handles "authentication" at the DDP layer via 
> > Cryptographic approaches as a possible approach to meeting 
> the need, 
> > then I can understand the logic as far as it goes.  But you 
> have not 
> > said anything about the need for Privacy (Encryption).  I 
> thought that 
> > was also an important consideration.
> 
> Whether it's going to be needed regardless of buffer 
> protection remains to be seen, as I don't know how strong the 
> eventual local interface buffer protection requirements are 
> going to be - that discussion does not appear to have concluded.
> 
> > But you have not said anything about the need
> > for Privacy (Encryption).  I thought that was also an important
> consideration.
> 
> Confidentiality (e.g., via encryption) is important for 
> RDDP's placed data. It is not clear to me that the RDDP 
> headers require confidentiality, although we may wind up with 
> a requirement that STags be randomly generated in some 
> fashion  (and an optional means of providing "authentication" 
> of the RDDP headers could meet this requirement).  Again, 
> this depends in some fashion on the buffer protection 
> discussion outcome.
> 
> > Anyway, perhaps you could address the above, and help clarify the 
> > issues for some of us.
> 
> Here's an attempt to summarize my current view of this:
> 
> (1) Something needs to be done in the area of buffer protection
> 	requirements, because:
> 	- Support for long-lived STags makes it too easy to expose
> 		received data to further modification after delivery
> 		to the ULP.
> 	- Unlike cryptographic mechanisms (including IPsec), buffer
> 		protection can protect against a malicious client that
> 		can successfully authenticate.
> 	I don't think strict single-shot (each RDDP operation always
> 	invalidates the associated STag) is necessary, but the
> 	strength of what is done here may affect what is necessary
> 	elsewhere - see (3).
> (2) The "RDDP is a transport" approach that makes ULPs responsible
> 	for specifying security requirements for ULP data appears to
> 	be worth pursuing.  I can't promise success, but I would be
> 	remiss in not trying.  If this approach fails, "MUST implement
> 	IPsec" is the most likely result.
> (3) If the "RDDP is a transport" approach is accepted, then RDDP is
> 	responsible for preventing misuse of the RDDP headers.  There
> 	are several possibilities here:
> 	- The buffer protection requirements from (1) could be strong
> 		enough to reduce any possible misuse to that which can
> 		be attempted against a transport like SCTP.  
> This could be
> 		accompanied by a requirement for randomly generate STag
> 		values.
> 	- A "MUST implement" RDDP security header could be defined to
> 		block replay, connection hijacking, and other 
> man-in-the-
> 		middle attacks.
> 	- "MUST implement IPsec" is sufficient, but probably more
> 		mechanism than is necessary in this situation.
> 
> At the moment, I think I see WG rough consensus to try (2), 
> although anyone is welcome to try to convince me otherwise.  
> OTOH, the WG should consider itself instructed to do 
> something about (1) [local interface requirements for buffer 
> protection].  In addition to the above, another reason for 
> this is in response to something Dwight asked earlier:
> 
> > Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP, 
> > MPI) and ad-hoc applications in determining responsibility of 
> > implementing protocol behaviors that do not leave themselves 
> > vulnerable? I believe it is quite innoccuous and appropriate to 
> > require that IETF (or other) ULPs be designed in a matter that does 
> > not notify ULP consumers of available data while an Stag is still 
> > mapped to that data.
> 
> The distinction that concerns me is that the defined ULPs are 
> being specified by very talented RDDP experts.  If it takes 
> that level of expertise to get STag invalidation right in 
> order to avoid memory exposure security holes, RDDP will not 
> be a mechanism that will be generally usable in a safe 
> fashion.  In essence, I am not convinced of Dwight's 
> "innocuous and appropriate" statement above, because I worry 
> that meeting the requirement requires application of an 
> unusual level of talent/expertise in the absence of doing 
> something better in the area of "buffer protection", although 
> I'm sure Dwight has that level of talent/expertise.
> 
> Returning to John's final point:
> 
> > Also as a second point, does it make since to attempt to define
> environments
> > where RDMA/iWARP would be approprate without the additional 
> > Cryptographic
> or
> > IPsec implementations (such as within clusters on their own physical
> subnets,
> > etc.), and then require IPsec in other less secure environments?
> 
> ** NO ** !!!  This was tried for one of the IPS protocols at 
> the London IESG plenary not too long ago and it went down in 
> flames ... 
> 
> 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
> 

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

To: "Barron, Dwight" <[email-masked]>
Subject: RE: [rddp] Why IPsec is needed for iSCSI but might not be needed for RDDP/iWARP
From: John Hufferd <[email-masked]>
Date: Wed, 9 Jun 2004 12:50:11 -0700
Cc: Black_David at emc.com, rddp at ietf.org
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>
Sender: [email-masked]

I guess I too agree with Dwight, for all the same reasons he has specified.  I am afraid that coming up with our own security stuff will take us down a long hard road which will lengthen our closure on this spec.

.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd at us.ibm.com

"Barron, Dwight" <dwight.barron at hp.com>
Sent by: rddp-bounces at ietf.org

06/09/2004 12:15 PM
To
<Black_David at emc.com>
cc
rddp at ietf.org
Subject
RE: [rddp] Why IPsec is needed for iSCSI but might not be needed for        RDDP/iWARP

David,
Thanks for the effort in trying number 2 below, but several private
conversations have convinced me that mandatory IPSEC may not be so bad
after all. There are really three facets to the argument.  

- The first is the desire to err on the conservative side when it comes
to security. IPSEC clearly does that. The header remedies suggested in
your item 3, along with one-shot Stags, are attempts to deal with the
threats as we identify them, while IPSEC effectively deals with threats
we haven't yet identified.
- The second is the more pragmatic thought of the iSCSI scenario
repeating itself in the market and implementations manifest without
IPSEC enabled.  Well designed ULPs will represent the bulk of the
traffic and won't be exposing known holes. This is not an attempt to
encourage this behavior, but rather to make sure are not remiss in
anticipating it.
- Finally, the thought of eliminating long lived Stags defeats one of
the primary benefits of RDDP, which is to publish access to memory with
as little CPU overhead as possible.

Regards,
Dwight

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> Behalf Of Black_David at emc.com
> Sent: Tuesday, June 08, 2004 11:33 PM
> To: hufferd at us.ibm.com
> Cc: rddp at ietf.org
> Subject: RE: [rddp] Why IPsec is needed for iSCSI but might
> not be needed for RDDP/iWARP
>
>
> John,
>
> > Perhaps you could explain again for me and perhaps some
> other "dense"
> > folks why IPsec would be a MUST implement (but optional to use) for
> > iSCSI but we are attempting to not say similar things for
> RDMA/iWARP.
>
> iSCSI is responsible for its data - there is no ULP further
> up the stack that is in a position to handle the security
> issues addressed by IPsec. In contrast, I'm prepared to
> advocate on behalf of the WG that RDDP is a transport used by
> a ULP, and as such the ULP bears the primary responsibility
> for specifying and meeting the security requirements of the
> ULP's data; we'll have to see how that fares.  I'm not
> promising success in getting this distinction accepted, but I
> think there's enough technical merit that it would be
> irresponsible of me to dismiss this out of hand.  Depending
> on the ULP, IPsec could still being required - for example,
> iSCSI over RDDP will probably need to require IPsec for iSCSI
> reasons.
>
> > I am not pushing an agenda here, I know that if we do not
> need IPsec
> > for RDMA/iWARP on clusters and other such reasonably secure
> > environments, the requirements of IPsec as a MUST implement in all
> > cases will NOT be appropriate.  (And often the RNIC used for such
> > clustering environment is on its own Subnet and not part of
> a general
> > communication network.) But I also feel that when RNICs are used on
> > less secure environments, that the environment looks
> similar to iSCSI.  
> > Perhaps even less secure because of the RNIC holding the placement
> > open to a storage location were with HW iSCSI, the direct placement
> > and the protocol are closely combined so that Buffers are not left
> > open for the intruder (at least not as much).
>
> IETF RFCs are written for "less secure environments" like the
> public Internet.  If an implementer wants to take liberties
> with the security requirements of an RFC for use in a
> "reasonably secure environment", that implementer does so
> without the IETF's approval, and cannot point to the IETF as
> justification when that insecure implementation is used in a
> less secure environment and is compromised by a foreseeable attack.
>
> > So based on the above thoughts, I am not sure why it was
> required for
> > iSCSI to use IPsec (when iSCSI HW is more secure than
> RNICs) and not
> > an issue for RDMA/iWARP.
> >
> > I get (but do not buy) the arguments that RDMA/iWARP is
> just using the
> > TCP/IP (or SCTP) and as such does not need any other
> protection that
> > is given to that, but then so was iSCSI.
>
> The key issue is not what's below the protocol, but what's
> above it - there's no ULP above iSCSI that can protect
> iSCSI's data (for data transfer, the next layer up is SAM-2,
> which is not a protocol).  A similar line of reasoning was
> successful in avoiding a requirement to add inband
> authentication to IPS's FC protocols - that is better done at
> the higher FC level (and in fact T11 is working on this).
>
> > So your thoughts about why it would be needed in one and
> not the other
> > would be of interest.  Since I do not see that a solution for
> > protecting the Buffers (single shot or what ever) changes
> the issue of
> > why iSCSI and not RDMA/iWARP.  If we protect the Buffers, then the
> > results will have a similar profile to iSCSI.  So that
> alone can not
> > be a full solution.
>
> I think there will need to be a resolution of the local
> interface requirements from the "single shot" discussion, as
> they are the only mechanism available to protect a server
> against a malicious client that can successfully authenticate.
>
> > If your position is that it is needed for both regardless of the
> > buffer protection, and you are suggesting that we might
> come up with
> > something that handles "authentication" at the DDP layer via
> > Cryptographic approaches as a possible approach to meeting
> the need,
> > then I can understand the logic as far as it goes.  But you
> have not
> > said anything about the need for Privacy (Encryption).  I
> thought that
> > was also an important consideration.
>
> Whether it's going to be needed regardless of buffer
> protection remains to be seen, as I don't know how strong the
> eventual local interface buffer protection requirements are
> going to be - that discussion does not appear to have concluded.
>
> > But you have not said anything about the need
> > for Privacy (Encryption).  I thought that was also an important
> consideration.
>
> Confidentiality (e.g., via encryption) is important for
> RDDP's placed data. It is not clear to me that the RDDP
> headers require confidentiality, although we may wind up with
> a requirement that STags be randomly generated in some
> fashion  (and an optional means of providing "authentication"
> of the RDDP headers could meet this requirement).  Again,
> this depends in some fashion on the buffer protection
> discussion outcome.
>
> > Anyway, perhaps you could address the above, and help clarify the
> > issues for some of us.
>
> Here's an attempt to summarize my current view of this:
>
> (1) Something needs to be done in the area of buffer protection
>                  requirements, because:
>                  - Support for long-lived STags makes it too easy to expose
>                                   received data to further modification after delivery
>                                   to the ULP.
>                  - Unlike cryptographic mechanisms (including IPsec), buffer
>                                   protection can protect against a malicious client that
>                                   can successfully authenticate.
>                  I don't think strict single-shot (each RDDP operation always
>                  invalidates the associated STag) is necessary, but the
>                  strength of what is done here may affect what is necessary
>                  elsewhere - see (3).
> (2) The "RDDP is a transport" approach that makes ULPs responsible
>                  for specifying security requirements for ULP data appears to
>                  be worth pursuing.  I can't promise success, but I would be
>                  remiss in not trying.  If this approach fails, "MUST implement
>                  IPsec" is the most likely result.
> (3) If the "RDDP is a transport" approach is accepted, then RDDP is
>                  responsible for preventing misuse of the RDDP headers.  There
>                  are several possibilities here:
>                  - The buffer protection requirements from (1) could be strong
>                                   enough to reduce any possible misuse to that which can
>                                   be attempted against a transport like SCTP.  
> This could be
>                                   accompanied by a requirement for randomly generate STag
>                                   values.
>                  - A "MUST implement" RDDP security header could be defined to
>                                   block replay, connection hijacking, and other
> man-in-the-
>                                   middle attacks.
>                  - "MUST implement IPsec" is sufficient, but probably more
>                                   mechanism than is necessary in this situation.
>
> At the moment, I think I see WG rough consensus to try (2),
> although anyone is welcome to try to convince me otherwise.  
> OTOH, the WG should consider itself instructed to do
> something about (1) [local interface requirements for buffer
> protection].  In addition to the above, another reason for
> this is in response to something Dwight asked earlier:
>
> > Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP,
> > MPI) and ad-hoc applications in determining responsibility of
> > implementing protocol behaviors that do not leave themselves
> > vulnerable? I believe it is quite innoccuous and appropriate to
> > require that IETF (or other) ULPs be designed in a matter that does
> > not notify ULP consumers of available data while an Stag is still
> > mapped to that data.
>
> The distinction that concerns me is that the defined ULPs are
> being specified by very talented RDDP experts.  If it takes
> that level of expertise to get STag invalidation right in
> order to avoid memory exposure security holes, RDDP will not
> be a mechanism that will be generally usable in a safe
> fashion.  In essence, I am not convinced of Dwight's
> "innocuous and appropriate" statement above, because I worry
> that meeting the requirement requires application of an
> unusual level of talent/expertise in the absence of doing
> something better in the area of "buffer protection", although
> I'm sure Dwight has that level of talent/expertise.
>
> Returning to John's final point:
>
> > Also as a second point, does it make since to attempt to define
> environments
> > where RDMA/iWARP would be approprate without the additional
> > Cryptographic
> or
> > IPsec implementations (such as within clusters on their own physical
> subnets,
> > etc.), and then require IPsec in other less secure environments?
>
> ** NO ** !!!  This was tried for one of the IPS protocols at
> the London IESG plenary not too long ago and it went down in
> flames ...
>
> 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
>

_______________________________________________
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] Long-lived Stags: Why?
From: [email-masked]
Date: Thu, 10 Jun 2004 14:45:34 -0600
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: AcRNnWcACFxbrXgbTwujbBFEASv+dwBi91ow
Thread-topic: [rddp] Long-lived Stags: Why?

John,
 
"Single shot" automatic invalidation of STags wouldn't break other things in addition to breaking apps written for Infiniband. For inster it would break iSER and modifying iSER to allow it would lead to very inefficient undesireable operation characterists. One needs to be able to have one side set up a large buffer for a transfer and allow the other side to use smaller buffers to handle that transaction a piece at a time as happens when a SCSI initiator sets up a buffer for a large Read and the SCSI target uses multiple RDMA Writes to transfer the data.
 
In iSER we did put in a specific requirement that iSER check that the Send carrying the Status for a command also invalidated the STag for that command and doing the invalidation if the Send didn't.
 
It would probably be appropriate to put a SHOULD statement into RDMAP and/or DDP about the ULP ensuring that an STag was invalidated for remote access before it tells the application that the data is in the buffer. This would say that other ULP's should do something similar to what we put into iSER. Given that "single shot" would be undesireable, there is no way for DDP or RDMAP to enforce the invalidation because they don't know when the ULP operation has been completed. The requirement for ULPs should be stated. If one can put a MUST on a ULP, then it could be a MUST.
 
Regards,
Pat

    -----Original Message-----
    From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org]On Behalf Of John Hufferd
    Sent: Tuesday, June 08, 2004 11:06 AM
    To: rddp at ietf.org
    Subject: Re: [rddp] Long-lived Stags: Why?

    My statements about InfiniBand were targeted at the exact point that Michael makes below.  There is a lot of industry work going on to use iSCSI and the infrastructure around it on InfiniBand.  That work is focused on taking the iSCSI/iSER and having it operate on InfiniBand, so that we do not have to reinvent all the management and discovery stuff on InfiniBand for use by SRP (especially since iSCSI/iSER has more capabilities than SRP).

    SRP is NOT an "Official" InfiniBand Architecture, but is an IEEE thing and the folks that have defined the InfiniBand Spec only refer to SRP as an "Example" of a storage protocol on InfiniBand.

    With respect to the point here however, the reason that I was concerned about the InfiniBand was that most of the RDMA/iWARP operations can be directly mapped against InfiniBand, and therefore we only need to have single versions of applications that can operate on both RDMA/iWARP and InfiniBand.  However, I was worried that if this "Single Shot" discussion got going such that the RNIC was expected to automatically invalidate an STag when ever it received or extracted data, significant incompatibilities would exist between RDMA/iWARP and InfiniBand which have otherwise been resolved.

    If we are moving away from any such consideration for the RNIC, then this whole issue of RDMA/iWARP can be put aside and handled in what ever other venue's that are approprate.
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/System Group, San Jose CA
    Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
    Alt Office: (408) 997-6136, Cell: (408) 499-9702
    Internet Address: hufferd at us.ibm.com

    Michael Krause <krause at cup.hp.com>
    Sent by: rddp-bounces at ietf.org

    06/08/2004 07:06 AM
    To
    rddp at ietf.org
    cc
    Subject
    Re: [rddp] Long-lived Stags: Why?

    At 09:37 PM 6/7/2004, Black_David at emc.com wrote:
    >Dwight,
    >
    > > This compromize includes two components, one a successful spoofing of
    > > the transport layer, in which RDDP is no more or less vulernable (same
    > > transports) and a second component which is the demarcation point at
    > > which the ULP can be assured that the buffer is no longer available for
    > > modification by a remote peer. I believe that iSER has correctly
    > > addressed this issue (see John Hufferd's clarification). The Stag will
    > > be un-allocated before notification/completion of the SCSI command.
    >
    >iSER is one way to design/implement iSCSI over RDMA - it is not
    >the only one, and my posts were based on a different architectural
    >approach.  Nonetheless, the fact that iSER considers STag reuse to
    >be sufficiently dangerous that it applies several "MUST" requirements
    >to STag invalidation ought to be (IMHO) a visible nail in the coffin
    >of long-lived STags.
    >
    >Would someone remind us why long-lived STag support should be retained
    >given the security pain and suffering it's causing (e.g., what is the
    >compelling use for this functionality)?  The simplest solution here
    >is to take it out, especially if there's no compelling use for it ...
    >
    >Looking back over the list emails, the reasons I think I see for
    >long-lived STags are:
    >
    >(1) Allow storage protocols to stage transfer based on available
    >         resources. (John Hufferd)  Also applies to HPC protocols like
    >         MPI. (Jim Pinkerton).
    >(2) Compatibility with InfiniBand. (John Hufferd)
    >(3) Avoid limiting flexibility. (Caitlin Bestler)
    >(4) Allow applications to innovate around long-lived STags.
    >         (Jim Pinkerton)

    Add my name and I'm sure many others who have spoken up about this issue to
    all of these values.

    >I believe that staged transfer (1) is compatible with a suitable
    >definition of "one-shot" STags - after completion of data transfer,
    >the buffer becomes not writable from the network before completion
    >is reported to the ULP application (there are details to be worked
    >out in the definition of "one-shot" that may impact the protocols).
    >
    >I have a hard time with InfiniBand compatibility as a motivation
    >given the serious incompatibility between iSER and SRP (the native
    >SCSI encapsulation on InfiniBand).

    There is an effort within an open source group to provide iSCSI and iSCSI /
    iSER over InfiniBand.  These are already well underway.

    As for compatibility with InfiniBand, need to keep in mind that much of the
    existing ULP that use RDMA as well as many user applications already
    operate over InfiniBand.  Various OSV already have a solid RDMA
    infrastructure capable of supporting InfiniBand.  Many ISV have products
    already using InfiniBand.  In general, there is a reasonably sized and
    solid ecosystem that supports the InfiniBand operational semantics which
    were used as the basis for RDDP semantics.  The basic RDDP semantics have
    been incorporated back into InfiniBand as well enabling the industry to
    have a single set that semantics that are interconnect independent.  As
    such, it would be very bad for the industry and customers to state
    compatibility with InfiniBand (an interconnect that is recognized and has
    associated IETF specifications) as insufficient motivation based solely on
    SRP / iSER compatibility.

    >Flexibility and innovation in the absence of other compelling uses of long
    >lived STag functionality strike me as reasons to put the RDDP protocols
    >(or possibly the long-lived STag extensions to them) on the experimental
    >RFC track rather than the standards track (i.e., publish them as
    >Experimental RFCs rather than Proposed Standard) until the compelling
    >benefits that outweigh the security risks can
    >be demonstrated.

    This is just coming down to whether to mandate IPSec or not and proceed
    with the existing specifications through the standards track.  I don't
    think we are to the point of just tossing the specs to experimental over
    this one question.

    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]
Subject: Re: [rddp] Why IPsec is needed for iSCSI but might not be needed for RDDP/iWARP
From: "Mallikarjun C." <[email-masked]>
Date: Thu, 10 Jun 2004 17:06:09 -0700
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]
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

Agree with Dwight's note. Let me add one additional comment since my listing of iSER MUST/SHOULD requirements earlier on a related thread wrt long-lived STags may have led some to believe that long-lived STags are not currently useful.

iSER assumes/requires the use of a single valid STag across multiple RDMA ops during the course of one I/O. The # of ops (launched by the SCSI target) on the STag is unlimited and is a function of the target controller memory in most cases. A similar design principle is applied in the opposite direction as well. So from iSER's perspective, "long-lived" is "valid beyond one I/O", mandatory one-shot STags would spell serious trouble for iSER (note that iSER would be accompanied by a mandatory-to-implement IPSec, since it's simply an iSCSI extension).
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

Barron, Dwight wrote:

    David,
    Thanks for the effort in trying number 2 below, but several private
    conversations have convinced me that mandatory IPSEC may not be so bad
    after all. There are really three facets to the argument.

    - The first is the desire to err on the conservative side when it comes
    to security. IPSEC clearly does that. The header remedies suggested in
    your item 3, along with one-shot Stags, are attempts to deal with the
    threats as we identify them, while IPSEC effectively deals with threats
    we haven't yet identified.
    - The second is the more pragmatic thought of the iSCSI scenario
    repeating itself in the market and implementations manifest without
    IPSEC enabled. Well designed ULPs will represent the bulk of the
    traffic and won't be exposing known holes. This is not an attempt to
    encourage this behavior, but rather to make sure are not remiss in
    anticipating it.
    - Finally, the thought of eliminating long lived Stags defeats one of
    the primary benefits of RDDP, which is to publish access to memory with
    as little CPU overhead as possible.

Regards,
Dwight

        -----Original Message-----
        From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf Of Black_David at emc.com
        Sent: Tuesday, June 08, 2004 11:33 PM
        To: hufferd at us.ibm.com
        Cc: rddp at ietf.org
        Subject: RE: [rddp] Why IPsec is needed for iSCSI but might not be needed for RDDP/iWARP

John,

            Perhaps you could explain again for me and perhaps some 

        other "dense"

            folks why IPsec would be a MUST implement (but optional to use) for iSCSI but we are attempting to not say similar things for 

RDMA/iWARP.

        iSCSI is responsible for its data - there is no ULP further up the stack that is in a position to handle the security issues addressed by IPsec. In contrast, I'm prepared to advocate on behalf of the WG that RDDP is a transport used by a ULP, and as such the ULP bears the primary responsibility for specifying and meeting the security requirements of the ULP's data; we'll have to see how that fares. I'm not promising success in getting this distinction accepted, but I think there's enough technical merit that it would be irresponsible of me to dismiss this out of hand. Depending on the ULP, IPsec could still being required - for example, iSCSI over RDDP will probably need to require IPsec for iSCSI reasons.

            I am not pushing an agenda here, I know that if we do not 

        need IPsec

            for RDMA/iWARP on clusters and other such reasonably secure environments, the requirements of IPsec as a MUST implement in all cases will NOT be appropriate. (And often the RNIC used for such clustering environment is on its own Subnet and not part of 

        a general

            communication network.) But I also feel that when RNICs are used on less secure environments, that the environment looks 

        similar to iSCSI.

            Perhaps even less secure because of the RNIC holding the placement open to a storage location were with HW iSCSI, the direct placement and the protocol are closely combined so that Buffers are not left open for the intruder (at least not as much). 

        IETF RFCs are written for "less secure environments" like the public Internet. If an implementer wants to take liberties with the security requirements of an RFC for use in a "reasonably secure environment", that implementer does so without the IETF's approval, and cannot point to the IETF as justification when that insecure implementation is used in a less secure environment and is compromised by a foreseeable attack.

            So based on the above thoughts, I am not sure why it was 

        required for

            iSCSI to use IPsec (when iSCSI HW is more secure than 

        RNICs) and not

an issue for RDMA/iWARP.

            I get (but do not buy) the arguments that RDMA/iWARP is 

        just using the

            TCP/IP (or SCTP) and as such does not need any other 

        protection that

            is given to that, but then so was iSCSI. 

        The key issue is not what's below the protocol, but what's above it - there's no ULP above iSCSI that can protect iSCSI's data (for data transfer, the next layer up is SAM-2, which is not a protocol). A similar line of reasoning was successful in avoiding a requirement to add inband authentication to IPS's FC protocols - that is better done at the higher FC level (and in fact T11 is working on this).

            So your thoughts about why it would be needed in one and 

        not the other

            would be of interest. Since I do not see that a solution for protecting the Buffers (single shot or what ever) changes 

        the issue of

            why iSCSI and not RDMA/iWARP. If we protect the Buffers, then the results will have a similar profile to iSCSI. So that 

        alone can not

            be a full solution. 

        I think there will need to be a resolution of the local interface requirements from the "single shot" discussion, as they are the only mechanism available to protect a server against a malicious client that can successfully authenticate.

            If your position is that it is needed for both regardless of the buffer protection, and you are suggesting that we might 

        come up with

            something that handles "authentication" at the DDP layer via Cryptographic approaches as a possible approach to meeting 

        the need,

            then I can understand the logic as far as it goes. But you 

        have not

            said anything about the need for Privacy (Encryption). I 

        thought that

            was also an important consideration. 

        Whether it's going to be needed regardless of buffer protection remains to be seen, as I don't know how strong the eventual local interface buffer protection requirements are going to be - that discussion does not appear to have concluded.

But you have not said anything about the need
for Privacy (Encryption).  I thought that was also an important

consideration.

        Confidentiality (e.g., via encryption) is important for RDDP's placed data. It is not clear to me that the RDDP headers require confidentiality, although we may wind up with a requirement that STags be randomly generated in some fashion (and an optional means of providing "authentication" of the RDDP headers could meet this requirement). Again, this depends in some fashion on the buffer protection discussion outcome.

            Anyway, perhaps you could address the above, and help clarify the issues for some of us. 

Here's an attempt to summarize my current view of this:

        (1) Something needs to be done in the area of buffer protection
        requirements, because:
        - Support for long-lived STags makes it too easy to expose
        received data to further modification after delivery
        to the ULP.
        - Unlike cryptographic mechanisms (including IPsec), buffer
        protection can protect against a malicious client that
        can successfully authenticate.
        I don't think strict single-shot (each RDDP operation always
        invalidates the associated STag) is necessary, but the
        strength of what is done here may affect what is necessary
        elsewhere - see (3).
        (2) The "RDDP is a transport" approach that makes ULPs responsible
        for specifying security requirements for ULP data appears to
        be worth pursuing. I can't promise success, but I would be
        remiss in not trying. If this approach fails, "MUST implement
        IPsec" is the most likely result.
        (3) If the "RDDP is a transport" approach is accepted, then RDDP is
        responsible for preventing misuse of the RDDP headers. There
        are several possibilities here:
        - The buffer protection requirements from (1) could be strong
        enough to reduce any possible misuse to that which can
        be attempted against a transport like SCTP. This could be
        accompanied by a requirement for randomly generate STag
        values.
        - A "MUST implement" RDDP security header could be defined to
        block replay, connection hijacking, and other man-in-the-
        middle attacks.
        - "MUST implement IPsec" is sufficient, but probably more
        mechanism than is necessary in this situation.

        At the moment, I think I see WG rough consensus to try (2), although anyone is welcome to try to convince me otherwise. OTOH, the WG should consider itself instructed to do something about (1) [local interface requirements for buffer protection]. In addition to the above, another reason for this is in response to something Dwight asked earlier:

            Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP, MPI) and ad-hoc applications in determining responsibility of implementing protocol behaviors that do not leave themselves vulnerable? I believe it is quite innoccuous and appropriate to require that IETF (or other) ULPs be designed in a matter that does not notify ULP consumers of available data while an Stag is still mapped to that data. 

        The distinction that concerns me is that the defined ULPs are being specified by very talented RDDP experts. If it takes that level of expertise to get STag invalidation right in order to avoid memory exposure security holes, RDDP will not be a mechanism that will be generally usable in a safe fashion. In essence, I am not convinced of Dwight's "innocuous and appropriate" statement above, because I worry that meeting the requirement requires application of an unusual level of talent/expertise in the absence of doing something better in the area of "buffer protection", although I'm sure Dwight has that level of talent/expertise.

Returning to John's final point:

            Also as a second point, does it make since to attempt to define 

environments

            where RDMA/iWARP would be approprate without the additional Cryptographic 

or

            IPsec implementations (such as within clusters on their own physical 

subnets,

            etc.), and then require IPsec in other less secure environments? 

        ** NO ** !!! This was tried for one of the IPS protocols at the London IESG plenary not too long ago and it went down in flames ...

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

_______________________________________________
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: RDDP <[email-masked]>
Subject: Re: [rddp] Long-lived Stags: Why?
From: Caitlin Bestler <[email-masked]>
Date: Fri, 11 Jun 2004 12:04:29 -0500
Cc: John Hufferd <hufferd at us.ibm.com>, Pat Thaler <pat_thaler at agilent.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 Jun 10, 2004, at 3:45 PM, pat_thaler at agilent.com wrote:

    John,
     
    "Single shot" automatic invalidation of STags wouldn't break other things in addition
    to breaking apps written for Infiniband. For inster it would break iSER and modifying
    iSER to allow it would lead to very inefficient undesireable operation characterists.
    One needs to be able to have one side set up a large buffer for a transfer and allow
    the other side to use smaller buffers to handle that transaction a piece at a time as
    happens when a SCSI initiator sets up a buffer for a large Read and the SCSI target
    uses multiple RDMA Writes to transfer the data.

I believe some clarifications are in order.

The question under discussion is whether RDDP creates new security vulnerabilities
that would not be be faced by an equivalent TCP/SCTP application.

The vulnerability identified is that a local interface may make it easy for the
ULP to leave a tagged buffer "open" at the RDDP layer when it was logically closed
according to the Upper Layer Protocol.

I have heard no disagreement with the contention that an application following
the guidance in the Security draft would have a problem. That is, the tools to
prevent this mismatch are already fully described, and in fact are available in
every known local interface.

There is a valid argument that the correct procedures are far from the default,
and that local interfaces may actually encourage over-exposing STags by requiring
extra steps to precisely tailor the RDDP layer exposure to match the logical
exposure.

So, even without any additional steps, it is arguable that RDDP as it stands
has presented a set of solutions for any increased vulnerability it may create.

Whether or not such an argument is fully defensible is probably not relevant.
I sense no clamoring for taking the most extreme position to the IESG, and
instead a consensus that *something* should be done so that applications that
simply use the STag associated with a Memory Region are not left exposed to
attacks by forged packets.

Two different strategies have been discussed to address this vulnerability:

a) blocking all unauthenticated DDP segments. Theoretically this could be
done at the RDDP layer, at the TCP or SCTP layer, or at the IP layer.
Because of the need to facilitate out-of-order handling, to leverage
existing designs, and to avoid redesigning DDP packet handling code
(and/or gates) that already exist, it is clear that the only viable
solution to authenticating DDP segments is to authenticate the IP
datagrams that carry them: which implies IPsec.

   If packet authentication is the selected solution, I believe it is
   clear that the preferred solution would not only be IPsec, but the
   exact same rules for usage of IPsec that apply to iSCSI.

b) The alternate, more minimal, approach is to eliminate the gap
   between the ULP's concept of when a buffer is writable and what
   has been communicated to RDDP using the local interface.

   One usage of the term "one shot" STag is a proposal to eliminate
   the potential mismatch by limiting the flexibility of STags.
   Many people have objected to this approach.

   But many of those objections have seemingly assumed that the
   choice was between requiring IPsec and crippling the local
   interface.

   I disagree. Enhancing the local interface can also eliminate
   the gap between ULP expectations and actual RDDP exposure.
   Doing so will result in more robust implementations, and will
   not result in the incremental per-unit cost of an IPsec solution.
   Keep in mind that most of the opinions expressed on this topic
   have agreed that for the vast majority of deployed RNICs, the
   IPsec functionality will *not* provide any additional value.
   So requiring IPsec would either impose a "compliance tax", or
   encourage non-compliant deployments. Once one IETF requirement
   has been ignored, it becomes easier to ignore others. Having
   decided that their RNIC won't support IPsec, will a manufacturer
   also be tempted to omit support for unaligned TCP segments?

   Enhancing the local interface would ensure that persistent
   STags were only used by applications that made a deliberate
   decision to do so. Typically this would be because they already
   had their own solutions in place, as is the case with iSER.

	Enhancing the local interface imposes no penalty on those
   applications that have already solved the exposure problem
   on their own.

That is why I believe these are the only two acceptable solutions.
The enhanced local interface can be implemented on top of existing
verbs, and IPsec can be inserted under an existing solution. All
other solutions break applications and/or break implementations.

     
    In iSER we did put in a specific requirement that iSER check that the Send
    carrying the Status for a command also invalidated the STag for that command
    and doing the invalidation if the Send didn't.
     
    It would probably be appropriate to put a SHOULD statement into RDMAP and/or DDP
    about the ULP ensuring that an STag was invalidated for remote access before it
    tells the application that the data is in the buffer. This would say that other
    ULP's should do something similar to what we put into iSER. Given that "single shot"
    would be undesireable, there is no way for DDP or RDMAP to enforce the invalidation
    because they don't know when the ULP operation has been completed. The requirement
    for ULPs should be stated. If one can put a MUST on a ULP, then it could be a MUST.

That is close to the first position: the Security Draft told you not to do that.
Changing it from a "please don't" to a "MUST NOT", when run-time enforcement is
impossible, isn't likely to be very persuasive to the IESG.

Stating that the local interface MUST NOT make a default out of insecure
practices, however, is enforceable and it is a requirement at the correct layer.

I see no conflict in preparing both solutions. The correct procedure is to identify
the *minimum* requirement that will address the problem. Clearly the local interface
enhancement would be the more minimal of the two solutions. However, if the IESG
does not accept our argument that it is adequate, then we would still have a
more stringent solution (IPsec) which would then be the most minimal.

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

To: <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] Long-lived Stags: Why?
From: "Jim Pinkerton" <[email-masked]>
Date: Mon, 21 Jun 2004 13:39:53 -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: AcRNFECPW94blHgSR1yLk2ac3NjWYgKt4bFA
Thread-topic: [rddp] Long-lived Stags: Why?

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.

 

Additionally, I thought it would be worthwhile to expound a bit on the reasons for a long(er) lived STag. David Black stated:

> Looking back over the list emails, the reasons I think I see for

> long-lived STags are:

>

> (1) Allow storage protocols to stage transfer based on available

>     resources. (John Hufferd)  Also applies to HPC protocols like

>     MPI. (Jim Pinkerton).

> (2) Compatibility with InfiniBand. (John Hufferd)

> (3) Avoid limiting flexibility. (Caitlin Bestler)

> (4) Allow applications to innovate around long-lived STags.

>     (Jim Pinkerton)Thought it might be worthwhile to expound a bit on how

In terms of when longer-lived STag could be used, one person on this thread (I can't find the exact quote) more-or-less stated it comes down to interpreting when to invalidate the STag and how that maps to the semantics that the ULP requires. Below are a few examples on how hard that interpretation can be (and why a simple one-shot RDMAP message substantially reduces the cases where RDMA has a compeling differentiation).

One example data transfer model is a Data Sink buffer that is huge (say, 2 GB), and the remote entity that is filling the buffer (the Data Source) wants to slice the transfer into smaller units, say 64 KB (this also happens to be a transfer model for ISCSI, including the proposed iSER protocol). Thus when to invalidate?

-        On first use? This makes slicing the buffer into smaller transfers from the remote peers perspective impossible.

-        On nth use? This requires the Data Sink to know how the data source handles its buffers. In general a bad idea.

-        Let the sender specify? Already in the protocol with Remote Invalidate.

In general it seems like there is often data transfer between machines with very different buffering capabilities. Thus allowing multi-shot STags is a good thing.

Another data transfer model is double buffering of data structures where latency is important. For example, a remote entity (for example, a sensor) is updating a central resource, and the central resource would like the most recent data, but doesn’t want to incur the additional overhead/latency skew of reading the remote sensor. A persistent STag can dramatically reduce latency skew and quite possibly total latency.

Another data transfer example is a shared time server. A central server keeps a global time count in a cluster, and time skew between nodes in a cluster is a primary concern. If the server advertises a remote STAG to allow all cluster clients to RDMA Read its current time, timer skew can be significantly reduced because there is no work that needs to be scheduled on the time server if an RNIC is used (for example, receive a packet, process it, send out the current time).

I think in general you can probably state any algorithm can be implemented with short-lived STags – but there are several significant algorithms that take a serious performance hit.

Thus I’m not at all in favor of requiring one-shot. It substantially reduces the benefit of the protocol to provide new capabilities.

 

 

Jim

 

 

> -----Original Message-----

> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf Of

> Black_David at emc.com

> Sent: Monday, June 07, 2004 9:38 PM

> To: rddp at ietf.org

> Subject: [rddp] Long-lived Stags: Why?

>

> Dwight,

>

> > This compromize includes two components, one a successful spoofing of

> > the transport layer, in which RDDP is no more or less vulernable (same

> > transports) and a second component which is the demarcation point at

> > which the ULP can be assured that the buffer is no longer available for

> > modification by a remote peer. I believe that iSER has correctly

> > addressed this issue (see John Hufferd's clarification). The Stag will

> > be un-allocated before notification/completion of the SCSI command.

>

> iSER is one way to design/implement iSCSI over RDMA - it is not

> the only one, and my posts were based on a different architectural

> approach.  Nonetheless, the fact that iSER considers STag reuse to

> be sufficiently dangerous that it applies several "MUST" requirements

> to STag invalidation ought to be (IMHO) a visible nail in the coffin

> of long-lived STags.

>

> Would someone remind us why long-lived STag support should be retained

> given the security pain and suffering it's causing (e.g., what is the

> compelling use for this functionality)?  The simplest solution here

> is to take it out, especially if there's no compelling use for it ...

>

> Looking back over the list emails, the reasons I think I see for

> long-lived STags are:

>

> (1) Allow storage protocols to stage transfer based on available

>     resources. (John Hufferd)  Also applies to HPC protocols like

>     MPI. (Jim Pinkerton).

> (2) Compatibility with InfiniBand. (John Hufferd)

> (3) Avoid limiting flexibility. (Caitlin Bestler)

> (4) Allow applications to innovate around long-lived STags.

>     (Jim Pinkerton)

>

> I believe that staged transfer (1) is compatible with a suitable

> definition of "one-shot" STags - after completion of data transfer,

> the buffer becomes not writable from the network before completion

> is reported to the ULP application (there are details to be worked

> out in the definition of "one-shot" that may impact the protocols).

>

> I have a hard time with InfiniBand compatibility as a motivation

> given the serious incompatibility between iSER and SRP (the native

> SCSI encapsulation on InfiniBand).  Flexibility and innovation

> in the absence of other compelling uses of long lived STag

> functionality strike me as reasons to put the RDDP protocols (or

> possibly the long-lived STag extensions to them) on the experimental

> RFC track rather than the standards track (i.e., publish them as

> Experimental RFCs rather than Proposed Standard) until the

> compelling benefits that outweigh the security risks can

> be demonstrated.

>

> 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 Barron, Dwight

> > Sent: Monday, June 07, 2004 4:27 PM

> > To: Somesh Gupta; Uri Elzur; rddp at ietf.org

> > Subject: RE: [rddp] IPsec and RDDP as a transport

> >

> >

> > This compromize includes two components, one a successful spoofing of

> > the transport layer, in which RDDP is no more or less vulernable (same

> > transports) and a second component which is the demarcation point at

> > which the ULP can be assured that the buffer is no longer

> > available for

> > modification by a remote peer. I believe that iSER has correctly

> > addressed this issue (see John Hufferd's clarification). The Stag will

> > be un-allocated before notification/completion of the SCSI command.

> >

> > Regards,

> > Dwight

> >

> > > -----Original Message-----

> > > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On

> > > Behalf Of Somesh Gupta

> > > Sent: Monday, June 07, 2004 12:58 PM

> > > To: Uri Elzur; rddp at ietf.org

> > > Subject: RE: [rddp] IPsec and RDDP as a transport

> > >

> > >

> > > Uri,

> > >

> > > With iSCSI, there is a delineation process on the byte

> > > stream before processing the data. In other words,

> > > if one packet or sequence of packets is injected by

> > > the rogue, it will be detected because the delineation

> > > process or CRC check or both will fail. There is one

> > > exception to this which is if the attacker can also

> > > predict the location of PDU header or data boundary in the

> > > byte stream at the same time.

> > >

> > > However RDMA writes offers no such protection. Out of

> > > order RDMA writes can be completed, corrupting data.

> > > Even when the holes are filled and if there are mechanisms

> > > to detect that there was mis-alignment of data,

> > > the user is still Out of luck because the data may already

> > > have been consumed.

> > >

> > > Somesh

>

> [.. remainder snipped ...]

>

>

> _______________________________________________

> 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] IPsec and RDDP as a transport
From: "Jim Pinkerton" <[email-masked]>
Date: Mon, 21 Jun 2004 16:15:28 -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: AcRDoFmzpeNv40I4QD6IwumJxmtSQAUOPGTw
Thread-topic: [rddp] 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: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf
Of
> Black_David at emc.com
> Sent: Wednesday, May 26, 2004 8:52 PM
> To: rddp at ietf.org
> 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
> black_david at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> _______________________________________________
> 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: "Wong, Isaac M \(U.S.A. EUD, SNSL\)" <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] SDP LocIRD and LocORD in Hello & HelloAck msg
From: "Jim Pinkerton" <[email-masked]>
Date: Tue, 22 Jun 2004 06:14:27 -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: AcQdlXFyQCuLL9ZiTZmees6/yzZcCw6YdLYw
Thread-topic: [rddp] SDP LocIRD and LocORD in Hello & HelloAck msg

This email slipped through the cracks. Apologies for the long reply
time.

You are correct that the LocIRD and LocORD are defined from the Local
Peer's perspective (i.e. the peer generating the message).

In terms of effective requirements, they are different than what you
state below. Keep in mind that the sender of an RDMA Read Request must
never send more requests than the Inbound RDMA Read Queue Depth at the
remote peer or the connection will be torn down.

	- HelloAck LocIRD >= LocORD in Hello (this allows the Active
Peer 
		to increase the LocORD value if it so chooses, up to a 
		maximum of the LocIRD HelloAck value).
	- HelloAck LocORD <= LocIRD in Hello (this ensures that the
Passive 
		Peer will never overflow the receive RDMA Read 
		Queue at the Active Peer).

Thus from the Active Peer's perspective, 
	- FinalLocalIRD = LocIRD in Hello message (i.e. any value it
wants).
	- FinalLocalORD <= LocIRD in HelloAck message (this value may 
		change from what was sent in the Hello message, 
		based on what was returned in the HelloAck message).

>From the Passive Peer's perspective:
	- FinalLocalIRD = LocIRD sent in HelloAck message 
		(i.e. any value it wants. They may use the value in 
		Hello message for LocORD as input into what they 
		allocate).
	- FinalLocalORD <= LocIRD in Hello message.

Hope this helps.

Jim

> -----Original Message-----
> From: rddp-admin at ietf.org [mailto:rddp-admin at ietf.org] On Behalf Of
Wong,
> Isaac M (U.S.A. EUD, SNSL)
> Sent: Thursday, April 08, 2004 11:15 AM
> To: rddp at ietf.org
> Subject: [rddp] SDP LocIRD and LocORD in Hello & HelloAck msg
> 
> I am looking for some clarification on the two fields, LocIRD and
LocORD
> in SDP Hello and HelloAck message as described in
> draft-pinkerton-iwarp-sdp-00.txt.
> 
> I believe the description of Hello and HelloAck message in section
6.2.1
> and 6.2.2 is from the perspective of the senders of the messages. If
> this is true, then LocIRD in the Hello Message should relate to the
> LocORD in the HelloAck Message. Similarly, the LocORD in the Hello
> Message should relate to the LocIRD in the HelloAck Message.
> 
> I am not clear if these fields are listed as part of setup
negotiation.
> I suspect they are. If this is true, then I believe the owner of each
of
> the read queues should have the final say on the maximum queue length,
> and the senders to these queues can advertize a lower number. So,
LocORD
> in HelloAck <= LocIRD in Hello. LocORD in Hello >= LocIRD in HelloAck.
> Thus, FinalLocIRD at Hello sender = FinalLocORD at HelloAck sender =
min
> (LocIRD in Hello, LocORD in HelloAck);
> FinalLocORD at Hello sender = FinalLocIRD at HelloAck sender = min
> (LocORD in Hello, LocIRD in HelloAck);
> 
> Is this the way they should be interpreted?
> 
> Isaac Wong
> Hewlett Packard
> 
> _______________________________________________
> 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]>
Subject: RE: [rddp] Why IPsec is needed for iSCSI but might not be neededfor RDDP/iWARP
From: "Jim Pinkerton" <[email-masked]>
Date: Tue, 22 Jun 2004 06:14:29 -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: AcRPtnb6+HhSWglrSrKOmYLRAqaD3wIPLRug
Thread-topic: [rddp] Why IPsec is needed for iSCSI but might not be neededfor RDDP/iWARP

I have to agree with Dwight's note as well. Particularly in light of (3)
below. There is significant pile of work which we can leverage if we go
down the IPSec path but have to re-invent if we make it native to the
RDDP protocol (for example, replay attack prevention is non-trivial).

Jim

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf
Of
> Mallikarjun C.
> Sent: Thursday, June 10, 2004 5:06 PM
> To: rddp at ietf.org
> Subject: Re: [rddp] Why IPsec is needed for iSCSI but might not be
> neededfor RDDP/iWARP
> 
> Agree with Dwight's note.  Let me add one additional comment since my
> listing of iSER MUST/SHOULD requirements earlier on a related thread
wrt
> long-lived STags may have led some to believe that long-lived STags
are
> not currently useful.
> 
> iSER assumes/requires the use of a single valid STag across multiple
> RDMA ops during the course of one I/O.  The # of ops (launched by the
> SCSI target) on the STag is unlimited and is a function of the target
> controller memory in most cases.  A similar design principle is
applied
> in the opposite direction as well.  So from iSER's perspective,
> "long-lived" is "valid beyond one I/O", mandatory one-shot STags would
> spell serious trouble for iSER (note that iSER would be accompanied by
a
> mandatory-to-implement IPSec, since it's simply an iSCSI extension).
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm [at] rose.hp.com
> 
> 
> Barron, Dwight wrote:
> 
> > David,
> > Thanks for the effort in trying number 2 below, but several private
> > conversations have convinced me that mandatory IPSEC may not be so
bad
> > after all. There are really three facets to the argument.
> >
> > - The first is the desire to err on the conservative side when it
comes
> > to security. IPSEC clearly does that. The header remedies suggested
in
> > your item 3, along with one-shot Stags, are attempts to deal with
the
> > threats as we identify them, while IPSEC effectively deals with
threats
> > we haven't yet identified.
> > - The second is the more pragmatic thought of the iSCSI scenario
> > repeating itself in the market and implementations manifest without
> > IPSEC enabled.  Well designed ULPs will represent the bulk of the
> > traffic and won't be exposing known holes. This is not an attempt to
> > encourage this behavior, but rather to make sure are not remiss in
> > anticipating it.
> > - Finally, the thought of eliminating long lived Stags defeats one
of
> > the primary benefits of RDDP, which is to publish access to memory
with
> > as little CPU overhead as possible.
> >
> > Regards,
> > Dwight
> >
> >
> >>-----Original Message-----
> >>From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> >>Behalf Of Black_David at emc.com
> >>Sent: Tuesday, June 08, 2004 11:33 PM
> >>To: hufferd at us.ibm.com
> >>Cc: rddp at ietf.org
> >>Subject: RE: [rddp] Why IPsec is needed for iSCSI but might
> >>not be needed for RDDP/iWARP
> >>
> >>
> >>John,
> >>
> >>
> >>>Perhaps you could explain again for me and perhaps some
> >>
> >>other "dense"
> >>
> >>>folks why IPsec would be a MUST implement (but optional to use) for
> >>>iSCSI but we are attempting to not say similar things for
> >>
> >>RDMA/iWARP.
> >>
> >>iSCSI is responsible for its data - there is no ULP further
> >>up the stack that is in a position to handle the security
> >>issues addressed by IPsec. In contrast, I'm prepared to
> >>advocate on behalf of the WG that RDDP is a transport used by
> >>a ULP, and as such the ULP bears the primary responsibility
> >>for specifying and meeting the security requirements of the
> >>ULP's data; we'll have to see how that fares.  I'm not
> >>promising success in getting this distinction accepted, but I
> >>think there's enough technical merit that it would be
> >>irresponsible of me to dismiss this out of hand.  Depending
> >>on the ULP, IPsec could still being required - for example,
> >>iSCSI over RDDP will probably need to require IPsec for iSCSI
> >>reasons.
> >>
> >>
> >>>I am not pushing an agenda here, I know that if we do not
> >>
> >>need IPsec
> >>
> >>>for RDMA/iWARP on clusters and other such reasonably secure
> >>>environments, the requirements of IPsec as a MUST implement in all
> >>>cases will NOT be appropriate.  (And often the RNIC used for such
> >>>clustering environment is on its own Subnet and not part of
> >>
> >>a general
> >>
> >>>communication network.) But I also feel that when RNICs are used on
> >>>less secure environments, that the environment looks
> >>
> >>similar to iSCSI.
> >>
> >>>Perhaps even less secure because of the RNIC holding the placement
> >>>open to a storage location were with HW iSCSI, the direct placement
> >>>and the protocol are closely combined so that Buffers are not left
> >>>open for the intruder (at least not as much).
> >>
> >>IETF RFCs are written for "less secure environments" like the
> >>public Internet.  If an implementer wants to take liberties
> >>with the security requirements of an RFC for use in a
> >>"reasonably secure environment", that implementer does so
> >>without the IETF's approval, and cannot point to the IETF as
> >>justification when that insecure implementation is used in a
> >>less secure environment and is compromised by a foreseeable attack.
> >>
> >>
> >>>So based on the above thoughts, I am not sure why it was
> >>
> >>required for
> >>
> >>>iSCSI to use IPsec (when iSCSI HW is more secure than
> >>
> >>RNICs) and not
> >>
> >>>an issue for RDMA/iWARP.
> >>>
> >>>I get (but do not buy) the arguments that RDMA/iWARP is
> >>
> >>just using the
> >>
> >>>TCP/IP (or SCTP) and as such does not need any other
> >>
> >>protection that
> >>
> >>>is given to that, but then so was iSCSI.
> >>
> >>The key issue is not what's below the protocol, but what's
> >>above it - there's no ULP above iSCSI that can protect
> >>iSCSI's data (for data transfer, the next layer up is SAM-2,
> >>which is not a protocol).  A similar line of reasoning was
> >>successful in avoiding a requirement to add inband
> >>authentication to IPS's FC protocols - that is better done at
> >>the higher FC level (and in fact T11 is working on this).
> >>
> >>
> >>>So your thoughts about why it would be needed in one and
> >>
> >>not the other
> >>
> >>>would be of interest.  Since I do not see that a solution for
> >>>protecting the Buffers (single shot or what ever) changes
> >>
> >>the issue of
> >>
> >>>why iSCSI and not RDMA/iWARP.  If we protect the Buffers, then the
> >>>results will have a similar profile to iSCSI.  So that
> >>
> >>alone can not
> >>
> >>>be a full solution.
> >>
> >>I think there will need to be a resolution of the local
> >>interface requirements from the "single shot" discussion, as
> >>they are the only mechanism available to protect a server
> >>against a malicious client that can successfully authenticate.
> >>
> >>
> >>>If your position is that it is needed for both regardless of the
> >>>buffer protection, and you are suggesting that we might
> >>
> >>come up with
> >>
> >>>something that handles "authentication" at the DDP layer via
> >>>Cryptographic approaches as a possible approach to meeting
> >>
> >>the need,
> >>
> >>>then I can understand the logic as far as it goes.  But you
> >>
> >>have not
> >>
> >>>said anything about the need for Privacy (Encryption).  I
> >>
> >>thought that
> >>
> >>>was also an important consideration.
> >>
> >>Whether it's going to be needed regardless of buffer
> >>protection remains to be seen, as I don't know how strong the
> >>eventual local interface buffer protection requirements are
> >>going to be - that discussion does not appear to have concluded.
> >>
> >>
> >>>But you have not said anything about the need
> >>>for Privacy (Encryption).  I thought that was also an important
> >>
> >>consideration.
> >>
> >>Confidentiality (e.g., via encryption) is important for
> >>RDDP's placed data. It is not clear to me that the RDDP
> >>headers require confidentiality, although we may wind up with
> >>a requirement that STags be randomly generated in some
> >>fashion  (and an optional means of providing "authentication"
> >>of the RDDP headers could meet this requirement).  Again,
> >>this depends in some fashion on the buffer protection
> >>discussion outcome.
> >>
> >>
> >>>Anyway, perhaps you could address the above, and help clarify the
> >>>issues for some of us.
> >>
> >>Here's an attempt to summarize my current view of this:
> >>
> >>(1) Something needs to be done in the area of buffer protection
> >>	requirements, because:
> >>	- Support for long-lived STags makes it too easy to expose
> >>		received data to further modification after delivery
> >>		to the ULP.
> >>	- Unlike cryptographic mechanisms (including IPsec), buffer
> >>		protection can protect against a malicious client that
> >>		can successfully authenticate.
> >>	I don't think strict single-shot (each RDDP operation always
> >>	invalidates the associated STag) is necessary, but the
> >>	strength of what is done here may affect what is necessary
> >>	elsewhere - see (3).
> >>(2) The "RDDP is a transport" approach that makes ULPs responsible
> >>	for specifying security requirements for ULP data appears to
> >>	be worth pursuing.  I can't promise success, but I would be
> >>	remiss in not trying.  If this approach fails, "MUST implement
> >>	IPsec" is the most likely result.
> >>(3) If the "RDDP is a transport" approach is accepted, then RDDP is
> >>	responsible for preventing misuse of the RDDP headers.  There
> >>	are several possibilities here:
> >>	- The buffer protection requirements from (1) could be strong
> >>		enough to reduce any possible misuse to that which can
> >>		be attempted against a transport like SCTP.
> >>This could be
> >>		accompanied by a requirement for randomly generate STag
> >>		values.
> >>	- A "MUST implement" RDDP security header could be defined to
> >>		block replay, connection hijacking, and other
> >>man-in-the-
> >>		middle attacks.
> >>	- "MUST implement IPsec" is sufficient, but probably more
> >>		mechanism than is necessary in this situation.
> >>
> >>At the moment, I think I see WG rough consensus to try (2),
> >>although anyone is welcome to try to convince me otherwise.
> >>OTOH, the WG should consider itself instructed to do
> >>something about (1) [local interface requirements for buffer
> >>protection].  In addition to the above, another reason for
> >>this is in response to something Dwight asked earlier:
> >>
> >>
> >>>Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP,
> >>>MPI) and ad-hoc applications in determining responsibility of
> >>>implementing protocol behaviors that do not leave themselves
> >>>vulnerable? I believe it is quite innoccuous and appropriate to
> >>>require that IETF (or other) ULPs be designed in a matter that does
> >>>not notify ULP consumers of available data while an Stag is still
> >>>mapped to that data.
> >>
> >>The distinction that concerns me is that the defined ULPs are
> >>being specified by very talented RDDP experts.  If it takes
> >>that level of expertise to get STag invalidation right in
> >>order to avoid memory exposure security holes, RDDP will not
> >>be a mechanism that will be generally usable in a safe
> >>fashion.  In essence, I am not convinced of Dwight's
> >>"innocuous and appropriate" statement above, because I worry
> >>that meeting the requirement requires application of an
> >>unusual level of talent/expertise in the absence of doing
> >>something better in the area of "buffer protection", although
> >>I'm sure Dwight has that level of talent/expertise.
> >>
> >>Returning to John's final point:
> >>
> >>
> >>>Also as a second point, does it make since to attempt to define
> >>
> >>environments
> >>
> >>>where RDMA/iWARP would be approprate without the additional
> >>>Cryptographic
> >>
> >>or
> >>
> >>>IPsec implementations (such as within clusters on their own
physical
> >>
> >>subnets,
> >>
> >>>etc.), and then require IPsec in other less secure environments?
> >>
> >>** NO ** !!!  This was tried for one of the IPS protocols at
> >>the London IESG plenary not too long ago and it went down in
> >>flames ...
> >>
> >>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
> >>
> >
> >
> > _______________________________________________
> > 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

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

To: <[email-masked]>
Subject: RE: [rddp] Why IPsec is needed for iSCSI but might not be neededfor RDDP/iWARP
From: Michael Krause <[email-masked]>
Date: Wed, 23 Jun 2004 06:08:13 -0700
In-reply-to: <[email-masked] up.windeploy.ntdev.microsoft.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>
References: <[email-masked]>
Sender: [email-masked]

Concur. Perhaps we can move towards getting consensus on this point so that the security draft can be updated and a final review done prior to the upcoming IETF meeting.

Mike

At 06:14 AM 6/22/2004, Jim Pinkerton wrote:

I have to agree with Dwight's note as well. Particularly in light of (3)
below. There is significant pile of work which we can leverage if we go
down the IPSec path but have to re-invent if we make it native to the
RDDP protocol (for example, replay attack prevention is non-trivial).

Jim

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf
Of
> Mallikarjun C.
> Sent: Thursday, June 10, 2004 5:06 PM
> To: rddp at ietf.org
> Subject: Re: [rddp] Why IPsec is needed for iSCSI but might not be
> neededfor RDDP/iWARP
>
> Agree with Dwight's note.  Let me add one additional comment since my
> listing of iSER MUST/SHOULD requirements earlier on a related thread
wrt
> long-lived STags may have led some to believe that long-lived STags
are
> not currently useful.
>
> iSER assumes/requires the use of a single valid STag across multiple
> RDMA ops during the course of one I/O.  The # of ops (launched by the
> SCSI target) on the STag is unlimited and is a function of the target
> controller memory in most cases.  A similar design principle is
applied
> in the opposite direction as well.  So from iSER's perspective,
> "long-lived" is "valid beyond one I/O", mandatory one-shot STags would
> spell serious trouble for iSER (note that iSER would be accompanied by
a
> mandatory-to-implement IPSec, since it's simply an iSCSI extension).
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm [at] rose.hp.com
>
>
> Barron, Dwight wrote:
>
> > David,
> > Thanks for the effort in trying number 2 below, but several private
> > conversations have convinced me that mandatory IPSEC may not be so
bad
> > after all. There are really three facets to the argument.
> >
> > - The first is the desire to err on the conservative side when it
comes
> > to security. IPSEC clearly does that. The header remedies suggested
in
> > your item 3, along with one-shot Stags, are attempts to deal with
the
> > threats as we identify them, while IPSEC effectively deals with
threats
> > we haven't yet identified.
> > - The second is the more pragmatic thought of the iSCSI scenario
> > repeating itself in the market and implementations manifest without
> > IPSEC enabled.  Well designed ULPs will represent the bulk of the
> > traffic and won't be exposing known holes. This is not an attempt to
> > encourage this behavior, but rather to make sure are not remiss in
> > anticipating it.
> > - Finally, the thought of eliminating long lived Stags defeats one
of
> > the primary benefits of RDDP, which is to publish access to memory
with
> > as little CPU overhead as possible.
> >
> > Regards,
> > Dwight
> >
> >
> >>-----Original Message-----
> >>From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> >>Behalf Of Black_David at emc.com
> >>Sent: Tuesday, June 08, 2004 11:33 PM
> >>To: hufferd at us.ibm.com
> >>Cc: rddp at ietf.org
> >>Subject: RE: [rddp] Why IPsec is needed for iSCSI but might
> >>not be needed for RDDP/iWARP
> >>
> >>
> >>John,
> >>
> >>
> >>>Perhaps you could explain again for me and perhaps some
> >>
> >>other "dense"
> >>
> >>>folks why IPsec would be a MUST implement (but optional to use) for
> >>>iSCSI but we are attempting to not say similar things for
> >>
> >>RDMA/iWARP.
> >>
> >>iSCSI is responsible for its data - there is no ULP further
> >>up the stack that is in a position to handle the security
> >>issues addressed by IPsec. In contrast, I'm prepared to
> >>advocate on behalf of the WG that RDDP is a transport used by
> >>a ULP, and as such the ULP bears the primary responsibility
> >>for specifying and meeting the security requirements of the
> >>ULP's data; we'll have to see how that fares.  I'm not
> >>promising success in getting this distinction accepted, but I
> >>think there's enough technical merit that it would be
> >>irresponsible of me to dismiss this out of hand.  Depending
> >>on the ULP, IPsec could still being required - for example,
> >>iSCSI over RDDP will probably need to require IPsec for iSCSI
> >>reasons.
> >>
> >>
> >>>I am not pushing an agenda here, I know that if we do not
> >>
> >>need IPsec
> >>
> >>>for RDMA/iWARP on clusters and other such reasonably secure
> >>>environments, the requirements of IPsec as a MUST implement in all
> >>>cases will NOT be appropriate.  (And often the RNIC used for such
> >>>clustering environment is on its own Subnet and not part of
> >>
> >>a general
> >>
> >>>communication network.) But I also feel that when RNICs are used on
> >>>less secure environments, that the environment looks
> >>
> >>similar to iSCSI.
> >>
> >>>Perhaps even less secure because of the RNIC holding the placement
> >>>open to a storage location were with HW iSCSI, the direct placement
> >>>and the protocol are closely combined so that Buffers are not left
> >>>open for the intruder (at least not as much).
> >>
> >>IETF RFCs are written for "less secure environments" like the
> >>public Internet.  If an implementer wants to take liberties
> >>with the security requirements of an RFC for use in a
> >>"reasonably secure environment", that implementer does so
> >>without the IETF's approval, and cannot point to the IETF as
> >>justification when that insecure implementation is used in a
> >>less secure environment and is compromised by a foreseeable attack.
> >>
> >>
> >>>So based on the above thoughts, I am not sure why it was
> >>
> >>required for
> >>
> >>>iSCSI to use IPsec (when iSCSI HW is more secure than
> >>
> >>RNICs) and not
> >>
> >>>an issue for RDMA/iWARP.
> >>>
> >>>I get (but do not buy) the arguments that RDMA/iWARP is
> >>
> >>just using the
> >>
> >>>TCP/IP (or SCTP) and as such does not need any other
> >>
> >>protection that
> >>
> >>>is given to that, but then so was iSCSI.
> >>
> >>The key issue is not what's below the protocol, but what's
> >>above it - there's no ULP above iSCSI that can protect
> >>iSCSI's data (for data transfer, the next layer up is SAM-2,
> >>which is not a protocol).  A similar line of reasoning was
> >>successful in avoiding a requirement to add inband
> >>authentication to IPS's FC protocols - that is better done at
> >>the higher FC level (and in fact T11 is working on this).
> >>
> >>
> >>>So your thoughts about why it would be needed in one and
> >>
> >>not the other
> >>
> >>>would be of interest.  Since I do not see that a solution for
> >>>protecting the Buffers (single shot or what ever) changes
> >>
> >>the issue of
> >>
> >>>why iSCSI and not RDMA/iWARP.  If we protect the Buffers, then the
> >>>results will have a similar profile to iSCSI.  So that
> >>
> >>alone can not
> >>
> >>>be a full solution.
> >>
> >>I think there will need to be a resolution of the local
> >>interface requirements from the "single shot" discussion, as
> >>they are the only mechanism available to protect a server
> >>against a malicious client that can successfully authenticate.
> >>
> >>
> >>>If your position is that it is needed for both regardless of the
> >>>buffer protection, and you are suggesting that we might
> >>
> >>come up with
> >>
> >>>something that handles "authentication" at the DDP layer via
> >>>Cryptographic approaches as a possible approach to meeting
> >>
> >>the need,
> >>
> >>>then I can understand the logic as far as it goes.  But you
> >>
> >>have not
> >>
> >>>said anything about the need for Privacy (Encryption).  I
> >>
> >>thought that
> >>
> >>>was also an important consideration.
> >>
> >>Whether it's going to be needed regardless of buffer
> >>protection remains to be seen, as I don't know how strong the
> >>eventual local interface buffer protection requirements are
> >>going to be - that discussion does not appear to have concluded.
> >>
> >>
> >>>But you have not said anything about the need
> >>>for Privacy (Encryption).  I thought that was also an important
> >>
> >>consideration.
> >>
> >>Confidentiality (e.g., via encryption) is important for
> >>RDDP's placed data. It is not clear to me that the RDDP
> >>headers require confidentiality, although we may wind up with
> >>a requirement that STags be randomly generated in some
> >>fashion  (and an optional means of providing "authentication"
> >>of the RDDP headers could meet this requirement).  Again,
> >>this depends in some fashion on the buffer protection
> >>discussion outcome.
> >>
> >>
> >>>Anyway, perhaps you could address the above, and help clarify the
> >>>issues for some of us.
> >>
> >>Here's an attempt to summarize my current view of this:
> >>
> >>(1) Something needs to be done in the area of buffer protection
> >>    requirements, because:
> >>    - Support for long-lived STags makes it too easy to expose
> >>            received data to further modification after delivery
> >>            to the ULP.
> >>    - Unlike cryptographic mechanisms (including IPsec), buffer
> >>            protection can protect against a malicious client that
> >>            can successfully authenticate.
> >>    I don't think strict single-shot (each RDDP operation always
> >>    invalidates the associated STag) is necessary, but the
> >>    strength of what is done here may affect what is necessary
> >>    elsewhere - see (3).
> >>(2) The "RDDP is a transport" approach that makes ULPs responsible
> >>    for specifying security requirements for ULP data appears to
> >>    be worth pursuing.  I can't promise success, but I would be
> >>    remiss in not trying.  If this approach fails, "MUST implement
> >>    IPsec" is the most likely result.
> >>(3) If the "RDDP is a transport" approach is accepted, then RDDP is
> >>    responsible for preventing misuse of the RDDP headers.  There
> >>    are several possibilities here:
> >>    - The buffer protection requirements from (1) could be strong
> >>            enough to reduce any possible misuse to that which can
> >>            be attempted against a transport like SCTP.
> >>This could be
> >>            accompanied by a requirement for randomly generate STag
> >>            values.
> >>    - A "MUST implement" RDDP security header could be defined to
> >>            block replay, connection hijacking, and other
> >>man-in-the-
> >>            middle attacks.
> >>    - "MUST implement IPsec" is sufficient, but probably more
> >>            mechanism than is necessary in this situation.
> >>
> >>At the moment, I think I see WG rough consensus to try (2),
> >>although anyone is welcome to try to convince me otherwise.
> >>OTOH, the WG should consider itself instructed to do
> >>something about (1) [local interface requirements for buffer
> >>protection].  In addition to the above, another reason for
> >>this is in response to something Dwight asked earlier:
> >>
> >>
> >>>Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP,
> >>>MPI) and ad-hoc applications in determining responsibility of
> >>>implementing protocol behaviors that do not leave themselves
> >>>vulnerable? I believe it is quite innoccuous and appropriate to
> >>>require that IETF (or other) ULPs be designed in a matter that does
> >>>not notify ULP consumers of available data while an Stag is still
> >>>mapped to that data.
> >>
> >>The distinction that concerns me is that the defined ULPs are
> >>being specified by very talented RDDP experts.  If it takes
> >>that level of expertise to get STag invalidation right in
> >>order to avoid memory exposure security holes, RDDP will not
> >>be a mechanism that will be generally usable in a safe
> >>fashion.  In essence, I am not convinced of Dwight's
> >>"innocuous and appropriate" statement above, because I worry
> >>that meeting the requirement requires application of an
> >>unusual level of talent/expertise in the absence of doing
> >>something better in the area of "buffer protection", although
> >>I'm sure Dwight has that level of talent/expertise.
> >>
> >>Returning to John's final point:
> >>
> >>
> >>>Also as a second point, does it make since to attempt to define
> >>
> >>environments
> >>
> >>>where RDMA/iWARP would be approprate without the additional
> >>>Cryptographic
> >>
> >>or
> >>
> >>>IPsec implementations (such as within clusters on their own
physical
> >>
> >>subnets,
> >>
> >>>etc.), and then require IPsec in other less secure environments?
> >>
> >>** NO ** !!!  This was tried for one of the IPS protocols at
> >>the London IESG plenary not too long ago and it went down in
> >>flames ...
> >>
> >>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
> >>
> >
> >
> > _______________________________________________
> > 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

_______________________________________________
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: "Michael Krause" <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] Why IPsec is needed for iSCSI but might not beneededfor RDDP/iWARP
From: "Jim Pinkerton" <[email-masked]>
Date: Thu, 24 Jun 2004 11:53:33 -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: AcRaFfWgh0VjqvlAQq2drglSLFjGbgABpbH2
Thread-topic: [rddp] Why IPsec is needed for iSCSI but might not beneededfor RDDP/iWARP

Title: RE: [rddp] Why IPsec is needed for iSCSI but might not beneededfor RDDP/iWARP
 
I think that would be great. I'm on vacation most of the time between now and July 15th, when the draft is due. So the earlier the consensus can be reached the quicker I can get something out.
 
I'm also in the middle of going through all the email threads to understand what other changes need to be made to the draft. Any comments on the draft that folks have been holding back would be appreciated now rather than later...

jim

 

From: [email-masked] on behalf of Michael Krause
Sent: Wed 6/23/2004 6:08 AM
To: [email-masked]
Subject: RE: [rddp] Why IPsec is needed for iSCSI but might not beneededfor RDDP/iWARP

Concur.  Perhaps we can move towards getting consensus on this point so
that the security draft can be updated and a final review done prior to the
upcoming IETF meeting.

Mike

At 06:14 AM 6/22/2004, Jim Pinkerton wrote:

>I have to agree with Dwight's note as well. Particularly in light of (3)
>below. There is significant pile of work which we can leverage if we go
>down the IPSec path but have to re-invent if we make it native to the
>RDDP protocol (for example, replay attack prevention is non-trivial).
>
>
>Jim
>
>
>
>
> > -----Original Message-----
> > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf
>Of
> > Mallikarjun C.
> > Sent: Thursday, June 10, 2004 5:06 PM
> > To: rddp at ietf.org
> > Subject: Re: [rddp] Why IPsec is needed for iSCSI but might not be
> > neededfor RDDP/iWARP
> >
> > Agree with Dwight's note.  Let me add one additional comment since my
> > listing of iSER MUST/SHOULD requirements earlier on a related thread
>wrt
> > long-lived STags may have led some to believe that long-lived STags
>are
> > not currently useful.
> >
> > iSER assumes/requires the use of a single valid STag across multiple
> > RDMA ops during the course of one I/O.  The # of ops (launched by the
> > SCSI target) on the STag is unlimited and is a function of the target
> > controller memory in most cases.  A similar design principle is
>applied
> > in the opposite direction as well.  So from iSER's perspective,
> > "long-lived" is "valid beyond one I/O", mandatory one-shot STags would
> > spell serious trouble for iSER (note that iSER would be accompanied by
>a
> > mandatory-to-implement IPSec, since it's simply an iSCSI extension).
> > --
> > Mallikarjun
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions
> > Hewlett-Packard MS 5668
> > Roseville CA 95747
> > cbm [at] rose.hp.com
> >
> >
> > Barron, Dwight wrote:
> >
> > > David,
> > > Thanks for the effort in trying number 2 below, but several private
> > > conversations have convinced me that mandatory IPSEC may not be so
>bad
> > > after all. There are really three facets to the argument.
> > >
> > > - The first is the desire to err on the conservative side when it
>comes
> > > to security. IPSEC clearly does that. The header remedies suggested
>in
> > > your item 3, along with one-shot Stags, are attempts to deal with
>the
> > > threats as we identify them, while IPSEC effectively deals with
>threats
> > > we haven't yet identified.
> > > - The second is the more pragmatic thought of the iSCSI scenario
> > > repeating itself in the market and implementations manifest without
> > > IPSEC enabled.  Well designed ULPs will represent the bulk of the
> > > traffic and won't be exposing known holes. This is not an attempt to
> > > encourage this behavior, but rather to make sure are not remiss in
> > > anticipating it.
> > > - Finally, the thought of eliminating long lived Stags defeats one
>of
> > > the primary benefits of RDDP, which is to publish access to memory
>with
> > > as little CPU overhead as possible.
> > >
> > > Regards,
> > > Dwight
> > >
> > >
> > >>-----Original Message-----
> > >>From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> > >>Behalf Of Black_David at emc.com
> > >>Sent: Tuesday, June 08, 2004 11:33 PM
> > >>To: hufferd at us.ibm.com
> > >>Cc: rddp at ietf.org
> > >>Subject: RE: [rddp] Why IPsec is needed for iSCSI but might
> > >>not be needed for RDDP/iWARP
> > >>
> > >>
> > >>John,
> > >>
> > >>
> > >>>Perhaps you could explain again for me and perhaps some
> > >>
> > >>other "dense"
> > >>
> > >>>folks why IPsec would be a MUST implement (but optional to use) for
> > >>>iSCSI but we are attempting to not say similar things for
> > >>
> > >>RDMA/iWARP.
> > >>
> > >>iSCSI is responsible for its data - there is no ULP further
> > >>up the stack that is in a position to handle the security
> > >>issues addressed by IPsec. In contrast, I'm prepared to
> > >>advocate on behalf of the WG that RDDP is a transport used by
> > >>a ULP, and as such the ULP bears the primary responsibility
> > >>for specifying and meeting the security requirements of the
> > >>ULP's data; we'll have to see how that fares.  I'm not
> > >>promising success in getting this distinction accepted, but I
> > >>think there's enough technical merit that it would be
> > >>irresponsible of me to dismiss this out of hand.  Depending
> > >>on the ULP, IPsec could still being required - for example,
> > >>iSCSI over RDDP will probably need to require IPsec for iSCSI
> > >>reasons.
> > >>
> > >>
> > >>>I am not pushing an agenda here, I know that if we do not
> > >>
> > >>need IPsec
> > >>
> > >>>for RDMA/iWARP on clusters and other such reasonably secure
> > >>>environments, the requirements of IPsec as a MUST implement in all
> > >>>cases will NOT be appropriate.  (And often the RNIC used for such
> > >>>clustering environment is on its own Subnet and not part of
> > >>
> > >>a general
> > >>
> > >>>communication network.) But I also feel that when RNICs are used on
> > >>>less secure environments, that the environment looks
> > >>
> > >>similar to iSCSI.
> > >>
> > >>>Perhaps even less secure because of the RNIC holding the placement
> > >>>open to a storage location were with HW iSCSI, the direct placement
> > >>>and the protocol are closely combined so that Buffers are not left
> > >>>open for the intruder (at least not as much).
> > >>
> > >>IETF RFCs are written for "less secure environments" like the
> > >>public Internet.  If an implementer wants to take liberties
> > >>with the security requirements of an RFC for use in a
> > >>"reasonably secure environment", that implementer does so
> > >>without the IETF's approval, and cannot point to the IETF as
> > >>justification when that insecure implementation is used in a
> > >>less secure environment and is compromised by a foreseeable attack.
> > >>
> > >>
> > >>>So based on the above thoughts, I am not sure why it was
> > >>
> > >>required for
> > >>
> > >>>iSCSI to use IPsec (when iSCSI HW is more secure than
> > >>
> > >>RNICs) and not
> > >>
> > >>>an issue for RDMA/iWARP.
> > >>>
> > >>>I get (but do not buy) the arguments that RDMA/iWARP is
> > >>
> > >>just using the
> > >>
> > >>>TCP/IP (or SCTP) and as such does not need any other
> > >>
> > >>protection that
> > >>
> > >>>is given to that, but then so was iSCSI.
> > >>
> > >>The key issue is not what's below the protocol, but what's
> > >>above it - there's no ULP above iSCSI that can protect
> > >>iSCSI's data (for data transfer, the next layer up is SAM-2,
> > >>which is not a protocol).  A similar line of reasoning was
> > >>successful in avoiding a requirement to add inband
> > >>authentication to IPS's FC protocols - that is better done at
> > >>the higher FC level (and in fact T11 is working on this).
> > >>
> > >>
> > >>>So your thoughts about why it would be needed in one and
> > >>
> > >>not the other
> > >>
> > >>>would be of interest.  Since I do not see that a solution for
> > >>>protecting the Buffers (single shot or what ever) changes
> > >>
> > >>the issue of
> > >>
> > >>>why iSCSI and not RDMA/iWARP.  If we protect the Buffers, then the
> > >>>results will have a similar profile to iSCSI.  So that
> > >>
> > >>alone can not
> > >>
> > >>>be a full solution.
> > >>
> > >>I think there will need to be a resolution of the local
> > >>interface requirements from the "single shot" discussion, as
> > >>they are the only mechanism available to protect a server
> > >>against a malicious client that can successfully authenticate.
> > >>
> > >>
> > >>>If your position is that it is needed for both regardless of the
> > >>>buffer protection, and you are suggesting that we might
> > >>
> > >>come up with
> > >>
> > >>>something that handles "authentication" at the DDP layer via
> > >>>Cryptographic approaches as a possible approach to meeting
> > >>
> > >>the need,
> > >>
> > >>>then I can understand the logic as far as it goes.  But you
> > >>
> > >>have not
> > >>
> > >>>said anything about the need for Privacy (Encryption).  I
> > >>
> > >>thought that
> > >>
> > >>>was also an important consideration.
> > >>
> > >>Whether it's going to be needed regardless of buffer
> > >>protection remains to be seen, as I don't know how strong the
> > >>eventual local interface buffer protection requirements are
> > >>going to be - that discussion does not appear to have concluded.
> > >>
> > >>
> > >>>But you have not said anything about the need
> > >>>for Privacy (Encryption).  I thought that was also an important
> > >>
> > >>consideration.
> > >>
> > >>Confidentiality (e.g., via encryption) is important for
> > >>RDDP's placed data. It is not clear to me that the RDDP
> > >>headers require confidentiality, although we may wind up with
> > >>a requirement that STags be randomly generated in some
> > >>fashion  (and an optional means of providing "authentication"
> > >>of the RDDP headers could meet this requirement).  Again,
> > >>this depends in some fashion on the buffer protection
> > >>discussion outcome.
> > >>
> > >>
> > >>>Anyway, perhaps you could address the above, and help clarify the
> > >>>issues for some of us.
> > >>
> > >>Here's an attempt to summarize my current view of this:
> > >>
> > >>(1) Something needs to be done in the area of buffer protection
> > >>    requirements, because:
> > >>    - Support for long-lived STags makes it too easy to expose
> > >>            received data to further modification after delivery
> > >>            to the ULP.
> > >>    - Unlike cryptographic mechanisms (including IPsec), buffer
> > >>            protection can protect against a malicious client that
> > >>            can successfully authenticate.
> > >>    I don't think strict single-shot (each RDDP operation always
> > >>    invalidates the associated STag) is necessary, but the
> > >>    strength of what is done here may affect what is necessary
> > >>    elsewhere - see (3).
> > >>(2) The "RDDP is a transport" approach that makes ULPs responsible
> > >>    for specifying security requirements for ULP data appears to
> > >>    be worth pursuing.  I can't promise success, but I would be
> > >>    remiss in not trying.  If this approach fails, "MUST implement
> > >>    IPsec" is the most likely result.
> > >>(3) If the "RDDP is a transport" approach is accepted, then RDDP is
> > >>    responsible for preventing misuse of the RDDP headers.  There
> > >>    are several possibilities here:
> > >>    - The buffer protection requirements from (1) could be strong
> > >>            enough to reduce any possible misuse to that which can
> > >>            be attempted against a transport like SCTP.
> > >>This could be
> > >>            accompanied by a requirement for randomly generate STag
> > >>            values.
> > >>    - A "MUST implement" RDDP security header could be defined to
> > >>            block replay, connection hijacking, and other
> > >>man-in-the-
> > >>            middle attacks.
> > >>    - "MUST implement IPsec" is sufficient, but probably more
> > >>            mechanism than is necessary in this situation.
> > >>
> > >>At the moment, I think I see WG rough consensus to try (2),
> > >>although anyone is welcome to try to convince me otherwise.
> > >>OTOH, the WG should consider itself instructed to do
> > >>something about (1) [local interface requirements for buffer
> > >>protection].  In addition to the above, another reason for
> > >>this is in response to something Dwight asked earlier:
> > >>
> > >>
> > >>>Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP,
> > >>>MPI) and ad-hoc applications in determining responsibility of
> > >>>implementing protocol behaviors that do not leave themselves
> > >>>vulnerable? I believe it is quite innoccuous and appropriate to
> > >>>require that IETF (or other) ULPs be designed in a matter that does
> > >>>not notify ULP consumers of available data while an Stag is still
> > >>>mapped to that data.
> > >>
> > >>The distinction that concerns me is that the defined ULPs are
> > >>being specified by very talented RDDP experts.  If it takes
> > >>that level of expertise to get STag invalidation right in
> > >>order to avoid memory exposure security holes, RDDP will not
> > >>be a mechanism that will be generally usable in a safe
> > >>fashion.  In essence, I am not convinced of Dwight's
> > >>"innocuous and appropriate" statement above, because I worry
> > >>that meeting the requirement requires application of an
> > >>unusual level of talent/expertise in the absence of doing
> > >>something better in the area of "buffer protection", although
> > >>I'm sure Dwight has that level of talent/expertise.
> > >>
> > >>Returning to John's final point:
> > >>
> > >>
> > >>>Also as a second point, does it make since to attempt to define
> > >>
> > >>environments
> > >>
> > >>>where RDMA/iWARP would be approprate without the additional
> > >>>Cryptographic
> > >>
> > >>or
> > >>
> > >>>IPsec implementations (such as within clusters on their own
>physical
> > >>
> > >>subnets,
> > >>
> > >>>etc.), and then require IPsec in other less secure environments?
> > >>
> > >>** NO ** !!!  This was tried for one of the IPS protocols at
> > >>the London IESG plenary not too long ago and it went down in
> > >>flames ...
> > >>
> > >>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
> > >>
> > >
> > >
> > > _______________________________________________
> > > 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
>
>_______________________________________________
>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

_______________________________________________
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, 28 Jun 2004 11:14:46 -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]

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
----------------------------------------------------
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: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Pinkerton
Sent: Thursday, June 24, 2004 2:54 PM
To: Michael Krause; [email-masked]
Subject: RE: [rddp] Why IPsec is needed for iSCSI but might not beneededfor
RDDP/iWARP

I think that would be great. I'm on vacation most of the time between now
and July 15th, when the draft is due. So the earlier the consensus can be
reached the quicker I can get something out.

I'm also in the middle of going through all the email threads to understand
what other changes need to be made to the draft. Any comments on the draft
that folks have been holding back would be appreciated now rather than
later...

jim

From: [email-masked] on behalf of Michael Krause
Sent: Wed 6/23/2004 6:08 AM
To: [email-masked]
Subject: RE: [rddp] Why IPsec is needed for iSCSI but might not beneededfor
RDDP/iWARP

Concur.  Perhaps we can move towards getting consensus on this point so
that the security draft can be updated and a final review done prior to the
upcoming IETF meeting.

Mike

At 06:14 AM 6/22/2004, Jim Pinkerton wrote:

>I have to agree with Dwight's note as well. Particularly in light of (3)
>below. There is significant pile of work which we can leverage if we go
>down the IPSec path but have to re-invent if we make it native to the
>RDDP protocol (for example, replay attack prevention is non-trivial).
>
>
>Jim
>
>
>
>
> > -----Original Message-----
> > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf
>Of
> > Mallikarjun C.
> > Sent: Thursday, June 10, 2004 5:06 PM
> > To: rddp at ietf.org
> > Subject: Re: [rddp] Why IPsec is needed for iSCSI but might not be
> > neededfor RDDP/iWARP
> >
> > Agree with Dwight's note.  Let me add one additional comment since my
> > listing of iSER MUST/SHOULD requirements earlier on a related thread
>wrt
> > long-lived STags may have led some to believe that long-lived STags
>are
> > not currently useful.
> >
> > iSER assumes/requires the use of a single valid STag across multiple
> > RDMA ops during the course of one I/O.  The # of ops (launched by the
> > SCSI target) on the STag is unlimited and is a function of the target
> > controller memory in most cases.  A similar design principle is
>applied
> > in the opposite direction as well.  So from iSER's perspective,
> > "long-lived" is "valid beyond one I/O", mandatory one-shot STags would
> > spell serious trouble for iSER (note that iSER would be accompanied by
>a
> > mandatory-to-implement IPSec, since it's simply an iSCSI extension).
> > --
> > Mallikarjun
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions
> > Hewlett-Packard MS 5668
> > Roseville CA 95747
> > cbm [at] rose.hp.com
> >
> >
> > Barron, Dwight wrote:
> >
> > > David,
> > > Thanks for the effort in trying number 2 below, but several private
> > > conversations have convinced me that mandatory IPSEC may not be so
>bad
> > > after all. There are really three facets to the argument.
> > >
> > > - The first is the desire to err on the conservative side when it
>comes
> > > to security. IPSEC clearly does that. The header remedies suggested
>in
> > > your item 3, along with one-shot Stags, are attempts to deal with
>the
> > > threats as we identify them, while IPSEC effectively deals with
>threats
> > > we haven't yet identified.
> > > - The second is the more pragmatic thought of the iSCSI scenario
> > > repeating itself in the market and implementations manifest without
> > > IPSEC enabled.  Well designed ULPs will represent the bulk of the
> > > traffic and won't be exposing known holes. This is not an attempt to
> > > encourage this behavior, but rather to make sure are not remiss in
> > > anticipating it.
> > > - Finally, the thought of eliminating long lived Stags defeats one
>of
> > > the primary benefits of RDDP, which is to publish access to memory
>with
> > > as little CPU overhead as possible.
> > >
> > > Regards,
> > > Dwight
> > >
> > >
> > >>-----Original Message-----
> > >>From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> > >>Behalf Of Black_David at emc.com
> > >>Sent: Tuesday, June 08, 2004 11:33 PM
> > >>To: hufferd at us.ibm.com
> > >>Cc: rddp at ietf.org
> > >>Subject: RE: [rddp] Why IPsec is needed for iSCSI but might
> > >>not be needed for RDDP/iWARP
> > >>
> > >>
> > >>John,
> > >>
> > >>
> > >>>Perhaps you could explain again for me and perhaps some
> > >>
> > >>other "dense"
> > >>
> > >>>folks why IPsec would be a MUST implement (but optional to use) for
> > >>>iSCSI but we are attempting to not say similar things for
> > >>
> > >>RDMA/iWARP.
> > >>
> > >>iSCSI is responsible for its data - there is no ULP further
> > >>up the stack that is in a position to handle the security
> > >>issues addressed by IPsec. In contrast, I'm prepared to
> > >>advocate on behalf of the WG that RDDP is a transport used by
> > >>a ULP, and as such the ULP bears the primary responsibility
> > >>for specifying and meeting the security requirements of the
> > >>ULP's data; we'll have to see how that fares.  I'm not
> > >>promising success in getting this distinction accepted, but I
> > >>think there's enough technical merit that it would be
> > >>irresponsible of me to dismiss this out of hand.  Depending
> > >>on the ULP, IPsec could still being required - for example,
> > >>iSCSI over RDDP will probably need to require IPsec for iSCSI
> > >>reasons.
> > >>
> > >>
> > >>>I am not pushing an agenda here, I know that if we do not
> > >>
> > >>need IPsec
> > >>
> > >>>for RDMA/iWARP on clusters and other such reasonably secure
> > >>>environments, the requirements of IPsec as a MUST implement in all
> > >>>cases will NOT be appropriate.  (And often the RNIC used for such
> > >>>clustering environment is on its own Subnet and not part of
> > >>
> > >>a general
> > >>
> > >>>communication network.) But I also feel that when RNICs are used on
> > >>>less secure environments, that the environment looks
> > >>
> > >>similar to iSCSI.
> > >>
> > >>>Perhaps even less secure because of the RNIC holding the placement
> > >>>open to a storage location were with HW iSCSI, the direct placement
> > >>>and the protocol are closely combined so that Buffers are not left
> > >>>open for the intruder (at least not as much).
> > >>
> > >>IETF RFCs are written for "less secure environments" like the
> > >>public Internet.  If an implementer wants to take liberties
> > >>with the security requirements of an RFC for use in a
> > >>"reasonably secure environment", that implementer does so
> > >>without the IETF's approval, and cannot point to the IETF as
> > >>justification when that insecure implementation is used in a
> > >>less secure environment and is compromised by a foreseeable attack.
> > >>
> > >>
> > >>>So based on the above thoughts, I am not sure why it was
> > >>
> > >>required for
> > >>
> > >>>iSCSI to use IPsec (when iSCSI HW is more secure than
> > >>
> > >>RNICs) and not
> > >>
> > >>>an issue for RDMA/iWARP.
> > >>>
> > >>>I get (but do not buy) the arguments that RDMA/iWARP is
> > >>
> > >>just using the
> > >>
> > >>>TCP/IP (or SCTP) and as such does not need any other
> > >>
> > >>protection that
> > >>
> > >>>is given to that, but then so was iSCSI.
> > >>
> > >>The key issue is not what's below the protocol, but what's
> > >>above it - there's no ULP above iSCSI that can protect
> > >>iSCSI's data (for data transfer, the next layer up is SAM-2,
> > >>which is not a protocol).  A similar line of reasoning was
> > >>successful in avoiding a requirement to add inband
> > >>authentication to IPS's FC protocols - that is better done at
> > >>the higher FC level (and in fact T11 is working on this).
> > >>
> > >>
> > >>>So your thoughts about why it would be needed in one and
> > >>
> > >>not the other
> > >>
> > >>>would be of interest.  Since I do not see that a solution for
> > >>>protecting the Buffers (single shot or what ever) changes
> > >>
> > >>the issue of
> > >>
> > >>>why iSCSI and not RDMA/iWARP.  If we protect the Buffers, then the
> > >>>results will have a similar profile to iSCSI.  So that
> > >>
> > >>alone can not
> > >>
> > >>>be a full solution.
> > >>
> > >>I think there will need to be a resolution of the local
> > >>interface requirements from the "single shot" discussion, as
> > >>they are the only mechanism available to protect a server
> > >>against a malicious client that can successfully authenticate.
> > >>
> > >>
> > >>>If your position is that it is needed for both regardless of the
> > >>>buffer protection, and you are suggesting that we might
> > >>
> > >>come up with
> > >>
> > >>>something that handles "authentication" at the DDP layer via
> > >>>Cryptographic approaches as a possible approach to meeting
> > >>
> > >>the need,
> > >>
> > >>>then I can understand the logic as far as it goes.  But you
> > >>
> > >>have not
> > >>
> > >>>said anything about the need for Privacy (Encryption).  I
> > >>
> > >>thought that
> > >>
> > >>>was also an important consideration.
> > >>
> > >>Whether it's going to be needed regardless of buffer
> > >>protection remains to be seen, as I don't know how strong the
> > >>eventual local interface buffer protection requirements are
> > >>going to be - that discussion does not appear to have concluded.
> > >>
> > >>
> > >>>But you have not said anything about the need
> > >>>for Privacy (Encryption).  I thought that was also an important
> > >>
> > >>consideration.
> > >>
> > >>Confidentiality (e.g., via encryption) is important for
> > >>RDDP's placed data. It is not clear to me that the RDDP
> > >>headers require confidentiality, although we may wind up with
> > >>a requirement that STags be randomly generated in some
> > >>fashion  (and an optional means of providing "authentication"
> > >>of the RDDP headers could meet this requirement).  Again,
> > >>this depends in some fashion on the buffer protection
> > >>discussion outcome.
> > >>
> > >>
> > >>>Anyway, perhaps you could address the above, and help clarify the
> > >>>issues for some of us.
> > >>
> > >>Here's an attempt to summarize my current view of this:
> > >>
> > >>(1) Something needs to be done in the area of buffer protection
> > >>    requirements, because:
> > >>    - Support for long-lived STags makes it too easy to expose
> > >>            received data to further modification after delivery
> > >>            to the ULP.
> > >>    - Unlike cryptographic mechanisms (including IPsec), buffer
> > >>            protection can protect against a malicious client that
> > >>            can successfully authenticate.
> > >>    I don't think strict single-shot (each RDDP operation always
> > >>    invalidates the associated STag) is necessary, but the
> > >>    strength of what is done here may affect what is necessary
> > >>    elsewhere - see (3).
> > >>(2) The "RDDP is a transport" approach that makes ULPs responsible
> > >>    for specifying security requirements for ULP data appears to
> > >>    be worth pursuing.  I can't promise success, but I would be
> > >>    remiss in not trying.  If this approach fails, "MUST implement
> > >>    IPsec" is the most likely result.
> > >>(3) If the "RDDP is a transport" approach is accepted, then RDDP is
> > >>    responsible for preventing misuse of the RDDP headers.  There
> > >>    are several possibilities here:
> > >>    - The buffer protection requirements from (1) could be strong
> > >>            enough to reduce any possible misuse to that which can
> > >>            be attempted against a transport like SCTP.
> > >>This could be
> > >>            accompanied by a requirement for randomly generate STag
> > >>            values.
> > >>    - A "MUST implement" RDDP security header could be defined to
> > >>            block replay, connection hijacking, and other
> > >>man-in-the-
> > >>            middle attacks.
> > >>    - "MUST implement IPsec" is sufficient, but probably more
> > >>            mechanism than is necessary in this situation.
> > >>
> > >>At the moment, I think I see WG rough consensus to try (2),
> > >>although anyone is welcome to try to convince me otherwise.
> > >>OTOH, the WG should consider itself instructed to do
> > >>something about (1) [local interface requirements for buffer
> > >>protection].  In addition to the above, another reason for
> > >>this is in response to something Dwight asked earlier:
> > >>
> > >>
> > >>>Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP,
> > >>>MPI) and ad-hoc applications in determining responsibility of
> > >>>implementing protocol behaviors that do not leave themselves
> > >>>vulnerable? I believe it is quite innoccuous and appropriate to
> > >>>require that IETF (or other) ULPs be designed in a matter that does
> > >>>not notify ULP consumers of available data while an Stag is still
> > >>>mapped to that data.
> > >>
> > >>The distinction that concerns me is that the defined ULPs are
> > >>being specified by very talented RDDP experts.  If it takes
> > >>that level of expertise to get STag invalidation right in
> > >>order to avoid memory exposure security holes, RDDP will not
> > >>be a mechanism that will be generally usable in a safe
> > >>fashion.  In essence, I am not convinced of Dwight's
> > >>"innocuous and appropriate" statement above, because I worry
> > >>that meeting the requirement requires application of an
> > >>unusual level of talent/expertise in the absence of doing
> > >>something better in the area of "buffer protection", although
> > >>I'm sure Dwight has that level of talent/expertise.
> > >>
> > >>Returning to John's final point:
> > >>
> > >>
> > >>>Also as a second point, does it make since to attempt to define
> > >>
> > >>environments
> > >>
> > >>>where RDMA/iWARP would be approprate without the additional
> > >>>Cryptographic
> > >>
> > >>or
> > >>
> > >>>IPsec implementations (such as within clusters on their own
>physical
> > >>
> > >>subnets,
> > >>
> > >>>etc.), and then require IPsec in other less secure environments?
> > >>
> > >>** NO ** !!!  This was tried for one of the IPS protocols at
> > >>the London IESG plenary not too long ago and it went down in
> > >>flames ...
> > >>
> > >>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
> > >>
> > >
> > >
> > > _______________________________________________
> > > 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
>
>_______________________________________________
>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

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

To: RDDP <[email-masked]>
Subject: Re: [rddp] Why IPsec is needed for iSCSI but might not beneededfo r RDDP/iWARP
From: Caitlin Bestler <[email-masked]>
Date: Mon, 28 Jun 2004 10:49:24 -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 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] Why IPsec is needed for iSCSI but might not beneededfo r RDDP/iWARP
From: Michael Krause <[email-masked]>
Date: Wed, 30 Jun 2004 14:58:01 -0700
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]> <[email-masked]>
Sender: [email-masked]

At 08:49 AM 6/28/2004, Caitlin Bestler wrote:

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.

Agreed.

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.

Agreed.

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.

Signaled events which are also local interface issues is another avenue. In general, I agree that the methods can vary and trying to restrict them is not necessarily wise.

   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.

This would necessitate changes to the verbs document and referencing it for developers to understand their local interface requirements and how to deal with any security issues for this class of problems at the verbs level.

Mike

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