[cicm] Moving Packets

"Novikov, Lev" <lnovikov@mitre.org> Fri, 17 June 2011 18:58 UTC

Return-Path: <lnovikov@mitre.org>
X-Original-To: cicm@ietfa.amsl.com
Delivered-To: cicm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A019E802D for <cicm@ietfa.amsl.com>; Fri, 17 Jun 2011 11:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY0lmYiKMuHH for <cicm@ietfa.amsl.com>; Fri, 17 Jun 2011 11:57:59 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AAE6C9E8026 for <cicm@ietf.org>; Fri, 17 Jun 2011 11:57:59 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3821221B1D66 for <cicm@ietf.org>; Fri, 17 Jun 2011 14:57:59 -0400 (EDT)
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 33D0821B0C17 for <cicm@ietf.org>; Fri, 17 Jun 2011 14:57:59 -0400 (EDT)
Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 17 Jun 2011 14:57:59 -0400
From: "Novikov, Lev" <lnovikov@mitre.org>
To: CICM Discussion List <cicm@ietf.org>
Date: Fri, 17 Jun 2011 14:56:05 -0400
Thread-Topic: Moving Packets
Thread-Index: AcwtIDWpAazCH2KDS+aIA2rCngrpdQ==
Message-ID: <F9AB58FA72BAE7449E7723791F6993ED062C94CA99@IMCMBX3.MITRE.ORG>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [cicm] Moving Packets
X-BeenThere: cicm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: CICM Discussion List <cicm@ietf.org>
List-Id: CICM Discussion List <cicm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cicm>, <mailto:cicm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cicm>
List-Post: <mailto:cicm@ietf.org>
List-Help: <mailto:cicm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cicm>, <mailto:cicm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jun 2011 18:58:00 -0000

I've had a chance to reflect some more on the question that Girish had
asked  (as well as those asked by others previously).

On 2011-05-27 15:47, Lev Novikov wrote:
> In fact, CICM does not define functions for simply moving data into
> the crypto. Therefore, you are free to use whatever transport
> mechanism works for you (e.g., POSIX socket).

On 2011-05-27 18:35, Girish Nanjundiah wrote:
> [...] while we can define the actual mechanism to reflect back the 
> packets outside of the driver, the driver still needs to call the
> function/mechanism that we define within its decrypt() function before
> it can expect the packet to appear. [...]

Two points:
1. The specification for decrypt() says:

   > Read plaintext data off of decrypt channel stream.  The method 
   > blocks until data becomes available.
   See http://tools.ietf.org/html/draft-lanz-cicm-cm-00#section-10.2.2

   Therefore, decrypt() should be called *before* there is data and only
   returns when there is data (or an error occurs).
   
2. My initial response to your question was based on a misunderstanding;
   I thought you were asking "What function--on the unprotected side--
   pushes the data into the module?" Our current design does not have 
   anything like that, but perhaps it should. I will address the 
   relevant issues in a separate email.
   
Lev