headers
Black_David | 1 Jun 2004 03:38

RE: IPsec and RDDP as a transport

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

Permalink | Reply | 1 comment |
headers
Caitlin Bestler | 1 Jun 2004 08:00

RE: IPsec and RDDP as a transport


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

Permalink | Reply | 0 comments |
headers
Black_David | 1 Jun 2004 15:05

RE: IPsec and RDDP as a transport

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

Permalink | Reply | 1 comment |
headers
Michael Krause | 1 Jun 2004 15:14
Picon

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

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

Permalink | Reply | 1 comment |
headers
Leonid Grossman | 1 Jun 2004 19:30

RE: IPsec and RDDP as a transport


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

Permalink | Reply | 0 comments |
headers
Black_David | 2 Jun 2004 01:11

RE: IPsec and RDDP as a transport

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

Permalink | Reply | 0 comments |
headers
Caitlin Bestler | 2 Jun 2004 10:48

RE: IPsec and RDDP as a transport

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

Permalink | Reply | 0 comments |
headers
Black_David | 2 Jun 2004 16:31

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

Permalink | Reply | 0 comments |
headers
Black_David | 2 Jun 2004 22:49

Administrative Items

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

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 3 Jun 2004 21:58
Picon
Favicon

I-D ACTION:draft-ietf-rddp-rdma-concerns-01.txt

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

Permalink | Reply | 0 comments |

Gmane