[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
- [cicm] Moving Packets Novikov, Lev