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

"Caitlin Bestler" <cait@asomi.com> Sun, 09 May 2004 08:22 UTC

Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23133 for <rddp-archive@odin.ietf.org>; Sun, 9 May 2004 04:22:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjWz-0001Ve-1i for rddp-archive@odin.ietf.org; Sun, 09 May 2004 04:19:29 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i498JSVX005802 for rddp-archive@odin.ietf.org; Sun, 9 May 2004 04:19:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjTA-0001Dl-Ab for rddp-web-archive@optimus.ietf.org; Sun, 09 May 2004 04:15:32 -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 EAA22903 for <rddp-web-archive@ietf.org>; Sun, 9 May 2004 04:15:30 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMjT7-0006kU-Ig for rddp-web-archive@ietf.org; Sun, 09 May 2004 04:15:29 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMjS7-0006MR-00 for rddp-web-archive@ietf.org; Sun, 09 May 2004 04:14:28 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMjR0-0005fs-00 for rddp-web-archive@ietf.org; Sun, 09 May 2004 04:13:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjPm-0000pd-3R; Sun, 09 May 2004 04:12:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjON-0000ey-39 for rddp@optimus.ietf.org; Sun, 09 May 2004 04:10: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 EAA22660 for <rddp@ietf.org>; Sun, 9 May 2004 04:10:33 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMjOK-0004rj-H6 for rddp@ietf.org; Sun, 09 May 2004 04:10:32 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMjNL-0004S1-00 for rddp@ietf.org; Sun, 09 May 2004 04:09:32 -0400
Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BMjMD-0003oc-00 for rddp@ietf.org; Sun, 09 May 2004 04:08:21 -0400
Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id AE20711E5B3; Sun, 9 May 2004 04:08:21 -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 87945-05; Sun, 9 May 2004 04:08:20 -0400 (EDT)
Received: by host52a.simplicato.com (Postfix, from userid 15001) id 0E61711ED05; Sun, 9 May 2004 04:08:19 -0400 (EDT)
Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 5739111ECF1; Sun, 9 May 2004 04:08:19 -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; Sun, 9 May 2004 03:08:19 -0500 (CDT)
Message-ID: <61710.82.166.251.29.1084090099.squirrel@mail52a.simplicato.com>
In-Reply-To: <B459CE1AFFC52D4688B2A5B842CA35EA7A595F@corpmx14.corp.emc.com>
References: <B459CE1AFFC52D4688B2A5B842CA35EA7A595F@corpmx14.corp.emc.com>
Date: Sun, 09 May 2004 03:08:19 -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.7 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,
>
>> Until IPsec is mandatory-to-implement for IP hosts I see no
>> justification for making it mandatory for RDDP endpoints. And
>> of course if it were mandatory-to-implement for IP Hosts, RDDP
>> would not have to implement it.
>
> IPsec is mandatory-to-implement for IPv6 hosts, FWIW.  The IESG
> will not approve standards-track RFCs that lack mandatory-to-
> implement security measures, although it's possible to reference
> measures that already exist elsewhere in the environment.
>
> If RDDP introduced no new risks above and beyond TCP or SCTP
> over IPv4, then falling back to the security requirements of
> those underlying protocols might be acceptable - I don't
> believe this to be the case, though (i.e., there are new
> RDDP-specific security risks).
>
> Thanks,
> --David

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.


There are also several problems with mandating IPsec
implemenetation.

First, what is the meaning of the mandate when the RDDP
implementation is cleanly layered over the LLP (or
even when it is integrated with the LLP, but they
are cleanly layered over IP)?

Surely we are not going to require that an RDDP implementation
refuse to use a valid TCP or IP stack because it lacks
IPsec support.

Secondly, we need to recognize that authentication and
privacy can be fully achieved in many IP networks without
any support for IPsec in the host through physical security,
managed switches and in-network IPsec devices. In fact there
are strong arguments why network implemented security is
superior to host implemented security.

Further, many RDDP deployments will be in precisely these
sort of controlled environments.

Lastly, requiring RDDP vendors to implement IPsec will
in merely force mediocre implementations to be integrated
and pre-empt the use of superior IPsec implemetnations that
are not integrated.

For all of these reasons, I strongly believe that RDDP should
remain oblivious to LLP provided security, and merely use
whatever is there.



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

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