RE: [rddp] Security draft issue (4) - IPsec

"Caitlin Bestler" <cait@asomi.com> Mon, 10 May 2004 05:47 UTC

Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11112 for <rddp-archive@odin.ietf.org>; Mon, 10 May 2004 01:47:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3aH-0008Ml-HJ for rddp-archive@odin.ietf.org; Mon, 10 May 2004 01:44:13 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4A5iDrh032157 for rddp-archive@odin.ietf.org; Mon, 10 May 2004 01:44:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3Xj-00089J-0z for rddp-web-archive@optimus.ietf.org; Mon, 10 May 2004 01:41:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10914 for <rddp-web-archive@ietf.org>; Mon, 10 May 2004 01:41:32 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN3Xf-0004mP-Sv for rddp-web-archive@ietf.org; Mon, 10 May 2004 01:41:31 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN3X0-0004UV-00 for rddp-web-archive@ietf.org; Mon, 10 May 2004 01:40:51 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN3WK-0004Bv-00 for rddp-web-archive@ietf.org; Mon, 10 May 2004 01:40:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3VH-0007rM-GN; Mon, 10 May 2004 01:39:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3Sm-0007D7-7q for rddp@optimus.ietf.org; Mon, 10 May 2004 01:36:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10616 for <rddp@ietf.org>; Mon, 10 May 2004 01:36:25 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN3Sj-0003E6-1R for rddp@ietf.org; Mon, 10 May 2004 01:36:25 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN3Rl-0002v8-00 for rddp@ietf.org; Mon, 10 May 2004 01:35:26 -0400
Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BN3Qq-0002dI-00 for rddp@ietf.org; Mon, 10 May 2004 01:34:28 -0400
Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 843CC11E213; Mon, 10 May 2004 01:34:27 -0400 (EDT)
Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08272-07; Mon, 10 May 2004 01:34:26 -0400 (EDT)
Received: by host52a.simplicato.com (Postfix, from userid 15001) id CB84911E251; Mon, 10 May 2004 01:34:26 -0400 (EDT)
Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 73B2F11E236; Mon, 10 May 2004 01:34:26 -0400 (EDT)
Received: from 82.166.251.29 (proxying for 82.166.251.29) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Mon, 10 May 2004 00:34:26 -0500 (CDT)
Message-ID: <33623.82.166.251.29.1084167266.squirrel@mail52a.simplicato.com>
In-Reply-To: <B459CE1AFFC52D4688B2A5B842CA35EA7A5996@corpmx14.corp.emc.com>
References: <B459CE1AFFC52D4688B2A5B842CA35EA7A5996@corpmx14.corp.emc.com>
Date: Mon, 10 May 2004 00:34:26 -0500
Subject: RE: [rddp] Security draft issue (4) - IPsec
From: Caitlin Bestler <cait@asomi.com>
To: Black_David@emc.com
Cc: cait@asomi.com, rddp@ietf.org
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
Importance: Normal
X-Virus-Scanned: by amavisd-new at simplicato.com
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Black_David@emc.com said:
> Caitlin,
>
>> I do not see any RDDP specific vulnerabilities that are relevant
>> to the use of IPsec.
>>
>> A non-RDDP application enables reception of peer messages into
>> application buffers. Given the nature of non-RDDP LLPs, use
>> of intermediate system buffering is likely.
>>
>> Once received, the Application judges the applicability of
>> transport layer security to its needs. It may determine that
>> the transport has provided sufficient authentication of the
>> remote peer to allow acting upon the received messages without
>> further validation, or it may decide to apply its own validation.
>>
>> So what changes with RDDP?
>>
>> Nothing, except that the intermediate system buffering is
>> far less likely. That *improves* security, not worsens it.
>>
>> Whether or not IPsec is in use, the Application already
>> has full control of which of its buffers are exposed,
>> to what extent, and for how long. Procedures to precisely
>> control that exposure are already documented in the security
>> draft and are not dependent on the use of IPsec or other
>> transport layer security.
>
> I think this misses the point by focusing on data instead of
> control.  The thing that has changed is that RDDP exposes
> a new functional interface for use over the network, providing
> more opportunities for abuse by a rogue peer who misuses the
> interface or an attacker who modifies the headers in transit
> - the security exposure here involves the headers and the
> additional functionality they enable.  In contrast to other
> new functionality, the application has no possibility to
> perform "its own validation" on use of the RDDP placement
> interface because the application never sees the RDDP headers.
>

What has not changed is that no matter what is in the network
packet, the exposure of application buffers to those packets
is under control of the application -- not of the network
packet.

How precisely the application control the exposure of its
buffer space, relative to its security requirements, is the
real issue. The vulnerability of network packets is not
an RDDP specific issue.

If the application has tailored its exposure, the attacker
can modify the headers endlessly. They will still only be
able to deposit the payload in the buffers the Data Sink
ULP intended them to be deposited into.

Again, the only change from non-RDDP applications is that
the use of intermediate system buffering has been eliminated.
This represents *improved* security, not heightened risk.


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

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