From anonsec-bounces@postel.org Mon Apr 7 11:16:32 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED0F28C1B1 for ; Mon, 7 Apr 2008 11:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITjLRz-KO4KD for ; Mon, 7 Apr 2008 11:16:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 395FC28C111 for ; Mon, 7 Apr 2008 11:16:31 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m37I1J6d021177; Mon, 7 Apr 2008 11:01:19 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m37I05tl020643 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 7 Apr 2008 11:00:06 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m37I057m022262 for ; Mon, 7 Apr 2008 18:00:05 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m37I04sb007327 for ; Mon, 7 Apr 2008 12:00:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m37I041F005011; Mon, 7 Apr 2008 13:00:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m37I049c005010; Mon, 7 Apr 2008 13:00:04 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 7 Apr 2008 13:00:04 -0500 From: Nicolas Williams To: Daniel Migault Message-ID: <20080407180003.GB16998@Sun.COM> Mail-Followup-To: Daniel Migault , anonsec@postel.org References: <20080225093002.01ABB3A6CB2@core3.amsl.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org On Fri, Mar 14, 2008 at 06:53:24AM +0100, Daniel Migault wrote: > Hi, > > Here are my comments on the draft. I tried to sum up the exchange I had with > Nico. Thanks. My comments follow as well. > < Although it adds almost nothing to the introduction and it is mainly a > re-writing of the introduction, it might bring some clarification to the > paper and to the connection latching concept: Your proposed new intro text seems to do three things: summarize the IPsec architecture (RFC4301), restate part of the intro that's already there and, importantly, restates a constraint that is not clearly stated in the intro (though it is stated elsewhere). That constraint is this: that under no circumstance does connection latching cause persistent changes to IPsec policy databases. I don't think it's safe to try to summarize the IPsec architecture here, so I will not take that text, but I think it's crucial that sa So I will add text like this: > < The changes are requested from applications and not from the network > administrator, which means that the ULP must not systematically overwrite > the IPsec policies established by the network administrator. For example > policy requests must not survive to crash, must not establish lower security > as defined by the network administrator. One way not to survive to crash is > to disable any modification in the user land. > < > < This lead us to consider a new object that will define security rules with > specific characteristics : the Connection Latching Objects. > < > < This document defines : > < - What is a connection latching object (Section 2 Introduction). > < - The behavior of a latching object (that is to say its state machine > section 2.1). > < - The interface of the Latching object with key managers and ULP > (section 2.2). > < - Interaction between LD and traditional IPsec databases (section 4). to the intro. I will also add a sentence to the abstract (I'll also delete a redundant sentence from the abstract) to the same efffect: Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. Additionally I'll add text to the security considerations section about this. Something like: Connection latching adds a new, non-persisting database to IPsec and new functionality to the IPsec key manager. Stripped of all optional features, connection latching is really about protecting established packet flows from SPD and SAD changes that are not consistent with what the application and/or ULP would like. This protection is achieved by tracking latched connections and synchronizing changes to the SPD and SAD with alerts to the ULPs that are responsible for affected latched connections. Excluding all optional features connection latching is simply a passive feature bolted to the side of the IPsec key manager. When a connection latch cannot be guaranteed the only action to be taken is to synchronously inform the affected ULPs and applications. Including all optional features connection latching also involves dynamic modifications to the "logical SPD," which do not persist across reboots nor past the lifetime of latched packet flows, and it also optionally involves IKEv2 CHILD SA narrowing. That connection latching state never persists beyond the lifetime of associated packet flows, nor across events which necessarily terminate such state (including reboots), derives from the fact that the very state of those packet flows is also non-persistent. We believe that this construction of connection latching achieves the desired goal -- protecting applications from dynamic IPsec policy or too permissive an IPsec policy -- without doing violence to the IPsec architecture. > < The considered model can be thus represented by the figure below: I like your ASCII art, but I'm going to modify it somewhat. Following our conversation I think we need to clearly delineate "kernel" and "user" mode execution, even though it's mostly irrelevant in a document like this one, because it'd relevant to most implementors; your figure almost does this. Also I think the ULP needs to be a box, as should be the key manager. And rather than refer to decorrelated and non-decorrelated SPD I'd rather speak of SPD and "logical SPD," where the latter is in the kernel. This last change is important because we want to demonstrate that connection latching, even with all OPTIONAL features, never modifies persistent IPsec policy. > < The ULP interfaces to the IPsec LD database are as follows: > --- > > The ULP interfaces to the IPsec PAD database are as follows: Good catch. I'll make it "The ULP interfaces to the key manager ..." > 648,659d584 > < The IPsec to ULP interfaces is as follows: > < > < o POP_MESSAGE(5-tuple, message) -> latch handle > < > < Pop up a message (code) to the ULP. Yes, I'd described the IPsec->ULP interface rather informally. I think we want something like: o INFORM(5-tuple, BREAK | SUSPEND) There's no return value for this function. > < The State diagram with functions can be represented by the figure below: > < [I removed mine] Er, could you send it again? I'll review your "Interaction between LD and other IPsec Databases" section next. Thanks! Nico -- _______________________________________________ From anonsec-bounces@postel.org Mon Apr 7 12:53:43 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2F63A6D2C for ; Mon, 7 Apr 2008 12:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[AWL=-2.266, BAYES_00=-2.599, SARE_GIF_ATTACH=1.42, SB_GIF_AND_NO_URIS=2.728] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v0bqkUt7013 for ; Mon, 7 Apr 2008 12:53:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id E884C3A6C03 for ; Mon, 7 Apr 2008 12:53:42 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m37Jfgaa001363; Mon, 7 Apr 2008 12:41:42 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m37JcCit029413 for ; Mon, 7 Apr 2008 12:38:13 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m37JcCXg019305 for ; Mon, 7 Apr 2008 19:38:12 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m37JcBFs039982 for ; Mon, 7 Apr 2008 13:38:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m37JcB6O005119; Mon, 7 Apr 2008 14:38:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m37JcB9v005118; Mon, 7 Apr 2008 14:38:11 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 7 Apr 2008 14:38:11 -0500 From: Nicolas Williams To: Daniel Migault , anonsec@postel.org Message-ID: <20080407193811.GK16998@Sun.COM> Mail-Followup-To: Daniel Migault , anonsec@postel.org References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VkVuOCYP9O7H3CXI" Content-Disposition: inline In-Reply-To: <20080407180003.GB16998@Sun.COM> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org --VkVuOCYP9O7H3CXI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 07, 2008 at 01:00:04PM -0500, Nicolas Williams wrote: > On Fri, Mar 14, 2008 at 06:53:24AM +0100, Daniel Migault wrote: > > < The considered model can be thus represented by the figure below: > > I like your ASCII art, but I'm going to modify it somewhat. How about this (GIF version attached): +--------------------------------------------+ | +--------------+ | | |Administrator | | | |apps | | | +--------------+ | | ^ | | | | user mode | v | | +--------------+ +---------------+ | | |App | |IKEv2 | | | | | | +---+ +----+ | | | | | | |PAD| |SPD | | | | | | | +---+ +--^-+ | | | +--------------+ +-----------|---+ | | ^ | | +---|-------------------------------|--------+ user/kernel mode +---|-------------------------------|--------+ interface | v | | |+-------+ +----------------------|-------+| ||ULP | | IPsec key manager | || |+-------+ | +------v------+|| | ^ ^ | | Logical SPD ||| | | | | +-----------^-+|| | | | | +----------+ +-----+ | || kernel mode | | +-------->| Latch DB |<-->| SAD | | || | | | +----------+ +--^--+ | || | | +--------------------|------|--+| +-|-------------------------------v------v---+ | | IPsec Layer (ESP/AH) | | | | +-v------------------------------------------+ | IP Layer | +--------------------------------------------+ --VkVuOCYP9O7H3CXI Content-Type: image/gif Content-Disposition: attachment; filename="conn-latching-arch.gif" Content-Transfer-Encoding: base64 R0lGODlhIAOEA/AAAP///wAAACH+K0NyZWF0ZWQgdXNpbmcgSmF2RSA1LjAgLSBodHRwOi8v d3d3LmphdmUuZGUALAAAAAAgA4QDAAL+hI+py+0Po5y02ouz3rz7D4biSJbmiabqyrbuC8fy TNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qt9yu9wsOi8fksvmMTqvX7Lb7DY/L 5/S6/Y7P6/f8vv8PGCg4SFhoeIiYqLjI2Oj4CBkpOUlZaXmJmam5ydnp+QkaKjpKWmp6ipqq usra6voKGys7S1tre4ubq7vL2+v7CxwsPExcbHyMnKy8zNzs/AwdLT1NXW19jZ2tvc3d7f0N Hi4+Tl5ufo6err7O3u7+Dh8vP09fb3+Pn6+/z9/v/w8woMCBBAsaPIgwocKFDBs6fAgxosSJ FCtavIgxo8b+jRw7evwIMqTIkSRLmjyJMqXKlSxbunwJM6bMmTRr2ryJM6fOnTx7+vwJNCiJ AESLGj2KNKnSpUybOn0KNarUqVSrWr2KNavWrVy7ev0qVeiIAGINkS0L4ixaQWrXcmjr1g/c uBjm0tVj9y6FvHrt8O0L4S9gOYIHMyhs2A3ixAgWM1bj+HHkx2cmJ7ZMmQzmwZszh+ncF7Rn L6Lvlh695XRc1aixsF77unWV2GVpy5ZiW2ju2092A/UdDazw4cS3/gDuE/kz5XSYZ3CuE/oy 6XCoV7BuE/sx7Wy4R/AuE/ww8WjINzDvEv0v9ZqP81bAvld8MfMP1Ed5P1d+0u7+3zeet18X +QVIEoG1GKjFgP79J49zmCHYgYILGgChLHkVNtmDAvY3YYWx2EWWYPHFJp2EHQK4QIgPjBhC iRwu6CEsIAIAIlE02ndjjvYVlcBZPDb2I5BB0pgUjkTauCOSFBaZJHxLKvndi/7F+MpcasF1 ZZZE6sggjlem2GOYXYb5JYVjctklljpGZiKMKIrJpZpm5jgjkGfOaeR5hyEmJ5x4blmXlO9R 6YqVeaJZpo9gnlmnnYc9GuWdiEo6QZtTvpmkUYeuOWejf6L5aZN+UvoklKBOuul1gvJGaCt9 4tmnoqe+OuuKo6Z6KK2ftgWapYNiuuumiYaKKq4i3kr+bLHEvtrrqre1ygqvi645bK2MThss pRc6iiunpEbaA7QZiauKtE42Wa2nyqZ6VIqaJnukrJnyauqplTorG7mp6OuEr6wCW4m/zwJM icD5EjyJwa3xewrDTCiMmsOlSKwExKNRPArGSFjsmcaheGwEx5mB/AnJRIhMmcmd1AhliKa6 bOW7iuG7MMHmAhpnmdm2gbJkCKcJZ6x19MyYypwcuzOzRm9A9GUIt5v0rUN2R3PENgONdbf2 Vlb1xQALnTW8S1vQtGFjZ6L0jrnqvC5kXXds84+KTg0zfDLz/PbIP2OLLB5lc7b3uXzjlXfK gfe9tV+F+9wg2osXfbgjfwP+djYmlYf7uNONW5652ZE3MnlonzMSul6XW3L6DqWbNvoiq9OV esGO+xB7QLVLcvsNr68GYHG+/w68Up0DPmEauftzfPGJW60818Un/7zy0J8YffNmTK8P9pdW b3173HdPn/Tge099dpBojw/6zqhfAvv1uK+MipKLbz78LdJfk/yg4z8T24rYvzma+C8RAIxH AYmhq0Mc8B0LFEYCzcK/8X2hge2goObKJ8EJRjCDXLDgOjxIPAxysIMbHGEWQJgOFAJDhar6 Xv4ewUJzxFA+MNQgQWbICxyCi4Q3zIkOA2PDgfxQPzWUgNKmdqRz3e1R8hJVj2yEpXrdY4i4 oKL+nowYND/5T38YclmchKW2PFkxD2M8UBF36C2+0auF8gKbGBEXQPPND4tjkiKzyNYpMEbt Wwb04RmBeKchMQleV2xjFtOElH2UkRaLhOOo+DJAPi7KkGFLI/L8OMcdShFWDrCMrLaox+XZ o5EW+qOtzATKXElSiX9KJc6+mD1M7q9SSKIXEpfoyTwKyV36KxU/SPkhU/4KJ8AkJPNuUkxR wo2YwvwXMzPpJhNuyIXSdE0Jqzmba2JzCsm0RjdRoS4FanMl4YQgNV/ywEJ8kxrrbJgj2TJO lkRSnOdEp9bUGU95KhOe9bRnMtspDYCC83z53Ga/CmrQhyE0oRVbKEP+N+bQh4YsohI9GUUr KgSBQkOj/bsoRoHA0fV9FDceHSnm+mnSI4S0GSuFSUunc4HgyXSmxUkCTW+KU9/V4KXxi+ns VJqxnV50pVTi6eBeYFRkaIhzEBWFeJK6HZ8yFahOFSpKr3iJogaVBlA1xlKzatOtzqCrxfgq 6sJaVa4O9acTTetY1zrVtn7MqiKkI1ibOle1XhVSgpslVeelpFgNspNIXMNT4UqmZmaUr6q8 J1b3GT691hWNqFRsELZ1SMfalWqSjWYLE/sfuiWRcHiVWqgw2zf1HXavg2NbYLllQa221lp9 7ZZq6erZvQjuZpxcJWf/KrULJXJn7ySfDMj+ikCphs2NxpxZaQNJ29qW022d3d5nSxUk5kKW usCFLqj+Ekn4rXaygAyldiko29paMnEDtN94c3uva+1Rs3h7LrvqaCtDzeG91tWtsZa0NvrW t7v3raST0vnb4yLWWnUL7Sb3i1bAthe7on0i1AasYNaq97HFJUyEQcHfYV73lEf124dLhtv+ xpeyAo5DekGcYhH7964EXlmMnTli2dnXxtWV8YrPuuOj3XhgeIxrEZC73fYtOGAn9kSIcTxj INdYyD2G8o+ZHORNPJnIOU5Yk3n8Vg132HVfpnKYyUtiKcsVxlXmcpSxPOUVzbRFOR1ul12A ZAcqV81H3vMJSDT+5DTHIM/BMCuc13xlEwC6zYKGAaFX6Gcdx7mTK1j0md/s6CVLGtGb/fP9 GE1pUB8T017OcqhTYOkM37kFj15PpEs9aQ4r+tOXTjRSNQ1rTrN4KLRWNanxjGvclbnRSk5L oE/taxV3etN9LjKqez3oVwNbzL4ls6llXewPbJnY00Yzsg/d7BxfOJBLrPay42XLlpV719xm dbAj8eJE8/ZGdyzxc6TbWFj+ut0saLUvDM1sizo7lPR+pL0D9S05Ifjg2O42fM8t7Gszlri9 /O6GNYBghV984hB3N7Vb/L9hf7tYrlVvqsUmJv12fOS3/nhz/arr8ubbkioHOYvtaGD+Nknb 495uOLxFLutx09zk0OYWdr27cp/3+90ElfhseSmzmr98363kuM4HHm2XJxkR8V42anuLdA9g yLYbZzjHW97zs0c81lafuCvNze43qnHVLHe4suNuWZBGupxN/HqEDE52m2998CLwNw2xHvAh AJzvR1f7vS38sj0VVua2truPkw7NcFO96Ew7ttIrzfS8d85BnLc83lVg+BzuvOlsN7u2S8/z zaM+9JkXON1hj/BaY/7ZWicq0B1feNyDHvFof/jpYa75yo9F+LMnvundrHzWx5zfzL+99YH/ +ean3fWk+z33/27s168++7zfftlFT7vxh1/8fwf48VGQ+l3+uH/t06/78tf/lsHPP/Z3p3zi F+t898d++bd/9rd0vcdWybd7Yld94JJLAXiA5jdmIed054d/4Jd/Uwd3GjhrCGhktrcXc5YW UYFuqRQWEDh8EriB9NR63MWBj6d7VraA1taC4JZpHkhj9ZeAN6iCgseCOviBxdd/1Fd7iidW yXZ570eDQJiDWdeDL8h13sdnPGh8/pdrCghmSCiDSkiBNZhgniZqXoOCRQiAZJSCWgh9M9iF TOhc5YeGBzOGyAeCd0B6YbhM19d9FYhhYBiDaciFBCSFe9iBfQiHeLiEWNgcZ+iEVUiEcmiE pOWGiziEBoh+J2WG2veGNUM2dcb+iZ3oFDbliaEoPHZWRzplh3ozQksTf7qwiuMxTU9YiAlS UmKYGrN4h7KodZpYi7k4aidki6i4i7Coi7gojL1oTbxoiC/EQ8WYjAL0ioxobK2oCar4i1Ei jTt4BddoC8pRccnxjJPIgFDoUt+YhLSmjVOYjdX4bef4f9mEjGjEjld4jMx4i774jsBIjNCo jo9Ij/hoj/1oOMuoj/eIiLEoQdRIkGrYUQIJjhfojQxZjgL4G+QoV081edlWSpj4Ewj5Yejh IoykiA8ZjKXlkfwnIyHZExyJcVpUbrfkS/gmLPXiI3LzJHYDSffSRDVpk4jyYKRQh0GhkjAI dlUXLOH+lVlDWXB5VHLJ4hhQ1Euu1DI+iI28phsUiXXzpCw9aXHrskZ2U0nTNUlICZUTqGUo yRNBmXutpC7zNltSx5bztSzxRUlyR5fiaDnGQYprI4p7yZd96ZcyVYLY8pfCgYGnpW7jhjQW ZpN343dZInQa+EnmFTR5KVJVqTikgpXLUycZ53b01ZS6RHJHWQ3x2I5t+EqiCUeo9ZaBV5fk p0tjaWDTQJry6GJeQnC8BV6MhZvaokWS8pl08pVhRJTBIRYNRJPzspiIc5OlGHlzJyR+F2o5 WVg8EkVamQyzSX9mVpzb6WRugZ0/l1JfKJLhaTzcSZ7laZmXyEHfKX10uFP+F9kS7FmJgEAb 8olP6bmG4fhMQOk3FSZIg+WS8SJhz5mciqkR9umIiRhaBBecbzdzu2mXBoGgeaieAMagFJeb JLacUlkQE3qIl8mga8lHY4dyK+gNXBGYfTWYK8qiLeqiTZGiLPmiWQFttMIyjMltFwZJlPlB ZrkTaNl58vVfn+cpWOmh6aeR4/mP+klc0XV+bqk1R2qJ8Gee+ViYXKmbI6qiEDqc7vCTEwmR QXqhiFlh2PYu6Vag8PClG2mVBjmIYDqSDTmAbBqmfkiV/FmnboqRdBqnEdk8QGqn1gOoeto9 gzqMB9mmh8p5UnqffbqFcxqh5JSoxlijeOqogcr+pIQXn5NKi9nGqOZ0qYS6fp/aqFbqp69H qqW6pHJKgFW6qqcKqUo6jwMJkHMIq7XKj7Sqq72xjxdkqo8qqJxaj+NjqJRaqMLqj8SKrAG5 nsvKOM2ap4oKPsXaqYgarcYarNdarc85oySIet0KruFKozyabuLKo5FqOq5ZkMGHDhKzoYzo rj4KDvGKfdvKoUgaieRAr9/3rBbohWIqQ9ykrv1KlmVIpe0qsPU6rPc6pXwYsCSlsMnKsDyw pvqasPwKORG7rg24DfvqrxKLrhQrr9/gsQXrORprq3tqsRCLsb4KeLHZeJnIsQC6bkmKjgqF shnrnDCrb1TosOe2mgf+O40X+7HMCpM8u3A/+6ZAa7IZOLQsW7QEK6StObXPJ5FMi0i3ZEfw 2Zu7NKSUlpMCaiRaK5NQZKAMUrM2i7Mte7I7S7UXGoFCa2sah18UZ1duBJZqY7b5xkV1Cys3 oyaZKbe8mrMuW7Xr5bc+u7Q3h7SoSUc2CrestDVaEqWSWYq6Q7RNSzkcpnI7yrX5qrJWKHQ4 x7P5dbRJC5yTG7nr9XYlCbWaKzqd6bgh65ChS2wicphRVxdli5gCFpncGqK6m7U4irmva6Kb K7uNW7yge7t3O7Bom5q+C5r6Vm9ieU+uGwXvOoS6YqQ4ULGi67yFO5TH8ptzab1wibjHe7X+ ByW+IUR0Mwe77Mq8LNeYiRu0XdulSRkp5vtaywW4XKqp69sE2huRNwp52eW9I8utUSl5vBsz 1nmb0+lffXecR0TBFYdLCWy8Ews7z2uwSgsGBOIhJau+6dq+w6N+r6rBASyzWZaqbhW1uQrC qQHBY1XDqpO5Jcw6J4yvg7uy2evBbRvDH7y440DCHMw7PNywRRweQey+8SuyahsTBAysR3yn csS2T6zDOCzF46jEO5zFKByH15C30/fCeRXGPTzD3FDGBXnGbJbGS2y73YC6KUu7SRzHUTy/ bAzFOUDFgWquUKHAWfWXMZpG4upzb4xihIBkFSK4clyiuOqCi9z+Z11XuQlpWEdohJYcybsK onC8sfjyx6LKB41sWaMsrXKhyfmJmb2KnmhMoRunyN3JyKsMiI43y1kYCKZMhqqLyZNMy4RI BaOcy9qpkFY4wLbsxMi8iTccs+gGvAGIyti6zF+sx6DMzH78ZkvZsx03zfYKtqiaw7rciJ6X cClHlsQcUd14b1ZcltE3nXv7kpCXpmOWoWMbter8cewcKO78tN5sXuEEwG3cytA7gfqsgo/s gBtszDkqmiKKtbQkmAUG0NaMxwvttA7DyxB3Xm7bvJt4wGHHzN+8sMmbliysAxu9ax19tA1M 0Fn6dBWdxx3caaJRxzIczCv90B6Nv+r+O09S124kDbJ9oNLIzNIv29L3+tPpnMiuXB7KjMsB HdM099JZCdP7JtRGu8tQDXX/yTJOOs8vCdSEVaYhLc3VbMKDUNQ+HESy7NTOA8t3ejsI7clD w9Xa5szpGNW//MrYzMqXDIsnx75x/dedzKp9vMUpfde1vNeBzbF2/M4mtnNZLbV/mM2BWJrV cdIF7di1u7Z+DWH7R9k6K3vNSMTkHNqTjdZgXNqtHcpNmIiivdo0bdrl/No3q9lQSNeHndhI rM0wrKBbt9u3OsS2DdnTGMjAE6MK5632VsyR7drHfFkXcdMjTXu1rXf7WdxabNnGjdMLOdMX HX0pzIaSatH+3kne462HKjHahtvdlLjeKdHeQqze2C3GIzHf3H3ZY3zb5h3e6M3f0p3d4wJ7 z/3P0f3e991Dno3StI3g+/2vCiHYSGyRee20P/zg3n3aFDHhd4y9XUzH6S3gCi5EBZ6pwizA 8yriCa7GFtHhDd7NAXqmOum13yc/D8xLPGngK37Hvr3CGPHiqgGbtqmUfKuxTkm9k1m67MTj Gj7dB2ri4Ae5wml0DgqZoHnU1c1STQ7fEZ4QQc6AUMqa52vPWL7TTYoNBcjlo5fcNPWeLTrI WC12DixIyTtYLfa7oTm8n0ucAc7ikOzk/HGKksjEQonY0ll32nXkZh6cPa5Ua37+3j9e38ZF 6L+9x6qNgfdbvy9XvmSu6CHu5xBe3r1tBdtmA9+7khY90LxpvzY+vVAJwNmg5qH+5PatrZc+ 6Bd+pYltwan1SJPX6Tqe49W547X94g1F64KO4rkOsLvu42gx67YO6F1O6Ypr6Wyd6v8NG5Cu 7cub4crewsseq9m+3cgr7eXe4n/+q1Z76nGufMUO2+qO2Nc+6WNg6uY87oZO6tDO7egOxLkt 7uF+4s2+77XR7/P+2aKu60aES2lL7Wvs0ibn8LM94o1d144O48lc70w9cLEu7wu/jguauBV/ 7sp53d8+zk6cIX5m5YE+s6Z7uC6f7E2NgwPP0AdN1uX+6tXmwudbqeUkutmuHs4iLfMlz9kX n/EYHy6JyW7z9nVfotD6db/AZ+Fe+fC+3M3bher6/uwGP/ORDlKUvRgJtKOrJPUTr3ZVfx6j TbpZf3W4vmrwjttX//F2/PaCBpaoK/UbWNV39iDMNdYUX/eGTdwIX4JtToIySXWj69zFtfdw F0UUhpeB74B2RvndTvfWXfOSnc+PRfacS1mITmq5AZ0TjJp3D/GY3tn9ObCb/rVJbeccb/Vz Xs2i3zZFj/IWz9tdnyBMb9RGZy+A6/itTndqD/xFS7foLHhbH/RK76okH8JcOEgzHs1hrfcN 3/Pv1CwKD81x2f1GP/hYj/T+Q+Q+987s5O7szo+fG2/XAC/wlX7F6Z/0/P71b1D++P7+II/+ Bf/84f/U7k8A8DF1uaNhlBM9eh2ednH9wVAcydI80VRdNe9y2Vhm4G2+8SqX6p3qWcAQUOgz HpFJ5XJZpDGhGGcnWuVVp8ysafvLWMFh8Zgs6x7OZVwawFabsSk3ZP6pU59v/Z7fj7Lv/EgA BZviUAIVEr3kvgofISMlr+wmfQgtcxYHEdtUNik78zJJS03FME+DQEBVdf46W1vpPh1db3Fz Gyt1T1J7OWF9PXc1a0eBk5WXX1uYRX6fpQ5LOEBnbbmypbm7LaO9I8DDt5MWrYvXjvHI2931 xt/+m6UC6u3v8fP19/n7/f8BBsSHRWCbgQZcWBDo79I6RfIgRqQ2TeLDihETQpJV7mJHj6Kc fSQmkuSejchKplQZiuJHbCthQnOY4GVMm8riYby5U8lJdjyBumRFsmZQo2hmzju69F1OiEWZ AvVpMWrVcE7lQbVqcyrNrV+lYW0KlmzLYSjLplUl1p1WtTvcxuiq9G3db0NFxrULJ9JcpHsB S2LbTm/gpH78IjS8WNBgcoUZa+t7WHFky2ocX73cB3I6yT83hxYWUqjoN51BngVtmvWRzN5Q t7Yx2TNd2bdnvO4WGzdHPolH9ha+ilfp4aMfAed9nLFubguhR5c+nXr+devXFxq89xN7d+32 uGP3zZw8abPlWS8PZgx9e7zm3YdWP0Lv/Phpnd8na39IQ/3/xwsQwLr4e0+dARH8C74EASuw uAMZHDC/CI9ycEG+KPxvwgylEsw/Du/bEMSbLDwvtxFDNBDFskp84cMVyxMRxhnZo5E5GW3M cYUWdewIxx6BXC9I2X4c0kgTj9ysyCSfW42MGrTikUnCVJwyJSh/c5IyKw1bkstlMuLMKwi/ jMzLMoEJM0vbdkTTsuwU/K67Oems08478cxTzznl9AAdhPYsKJ9mrNnTTTOrPNTHONcM7kRF u0wU0ooekJKW+iYN7MxMXalUI0cf5ZRASUX+zcrDF0tlkdRUIbWU1bVWfdVNV2UtZdNaR6QV 17se3FVRXX2l7cJgvwSW2EJuPTZBY5UVs1c6BkVju55IqUfaaAEF71praaELhkJFZbZZk2J1 0k9qeWV0TAXPRclTb9dtddwKy6VKKdTEtbcyLfft915Hv9V31nmN0g1LQqetgFuatJ2NhoYP ztaihOkTWN1/BX5X3YAnzZfgJ+uNl1GF4v0zziyIeCVikxVjuT+LL/Y34n3btc1jTT/u8FmW To4ZYJ/FYeRnmRU+TB+GuVuN5X34tfLmnMEwuAOKDQLNZRcdVlNNUKtpWlqGGxZ5pJovfnov s6FGDmskiwj7aH/+157a7ZOx5VpIoEsOGuyEORa7TLTT1iJkm4VOmVSyl+62NrtHaVvfq2ce OPCYpIaZKsN3HhqprS2XqfPLFccY1MjRBHxycwYv2915EBe65Iz6Dg6b2EUmO2M8aGecS9NP d23wt+He9tuws90C+Gk539bvrvfmm2rMCR/98yl57x1V1zWbSC7iOrZepWQbC2PhNj+p/i3z vb8BfJPGT/8Z9N3fPvP4QYSf/i1Dvx9F+/VXDcn+KcQ/AN4NewMMoAF1Mj8EAkiAC1SggBzo ngZGMG4VpCADL/iY1GVQOBPkYP4K+EEJirBJDyThcDx4wuXpTYUjbCFONvhC+cgwGev+o+FW UihDG96wKjl84Q55yBQfthCIQaSXEW9RRCTqbImnUGITSQRFJ8ZQiqOqYrWoeEX8aDETQ+Ri L7x4wjB+ERdjFKEZyQirNH5qjS5sY/gcxqY3bnGOiAkhGusIBTxm0HgrzCNY9njBPsrxj18J JAWzY7JALZKRjXTkIyEZSUlOkjqFJNfaDmlJ32kSM87IJCevB0ornEFjotyPKceQhk+iUn2s FJ8rTbNKBMoSltqrJbpu+aZc6nGXuuwlLn+Js2AigZbDNEIxAQgV4MnJgsYUljNr1Ep7oQya XawmXLD5uDheMzncJFOoRAdChS1sZsQjBtW8Oax0+g+cI9v+JuuCp0ivXG2dIaznZ6SZt3c2 bl1ba989TQjQgOJTeM1kh9b0KdCXKZSdGCLkeA5Cs3FSDJneq6j+4kK6ffarZrbzI0PFCdIs 7iwenCul7i7au5TSL6NeQwtHYTfNh4rUpTTl2Y7qBghsIW95z7Pp/35qzzIGVX5EHSgWjUq+ pALVFOZcKvOeKtSoemSl8avqVD+K1eBpdVFcDalXJXLV9ImVq2S1nlmxitbTqTWqbA2cW5cK V6jJ1ah0/Zhdg4rXeVGSr331618BG1jBDlavYDXsYRGbWMUulrGNdexjIRtZyU6WspW17GUx m1nNbpaznfXsZ0EbWtGOlrSlNe3+aVGbWtWulrWtde1rYRtb2c6WtrW17W1xm1vd7pa3vfXt b4EbXOEOl7jFNe5xkZtc5S6Xuc117nOhG13pTpe61bXudbGbXe1ul7vd9e53wRte8Y6XvOU1 73nRm171rpe97XXve+EbX/nOl771te998Ztf/e6Xv/31738BHGABD5jABTbwgRGcYAUvmMEN dvCDIRxhCU+YwhW28IUxnGENb5jDHfbwh0EcYhGPmMQlNvGJUZxiFa+YxS128YthHGMZz5jG NbbxjXGcYx3vmMc99vGPgRxkIQ+ZyEU28pGRnGQlL5nJTXbyk6EcZSlPmcpVtvKVsZxlLW+Z y1328pftwRxmMY+ZzGU285nRnGY1r5nNbXbzm+EcZznPmc51tvOd8ZxnPe+Zz332858BHWhB D5rQhTb0oRGdaEUvmtGNdvSjIR1pSU+a0pW29KUxnWlNb5rTnfb0p0EdalGPmtSlNvWpUZ1q Va+a1a129athHWtZz5rWtbb1rXGda13vmte99vWvgR1sYQ+b2MU29rGRnWxlL5vZzXb2s6Ed bWlPm9rVtva1sZ1tbW+b29329rfBHW5xj5vc5Tb3udGdbnWvm93tdve74R1vec+b3vW2973x nW9975vf/fb3vwEecIEPnOAFN/jBEZ5wARcAADs= --VkVuOCYP9O7H3CXI Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --VkVuOCYP9O7H3CXI-- From anonsec-bounces@postel.org Tue Apr 8 10:53:12 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E91828C1B9 for ; Tue, 8 Apr 2008 10:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5amGLdvuIdU for ; Tue, 8 Apr 2008 10:53:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 7F30E3A6912 for ; Tue, 8 Apr 2008 10:53:11 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m38HWKnO028858; Tue, 8 Apr 2008 10:32:20 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m38HUgKZ028055 for ; Tue, 8 Apr 2008 10:30:43 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m38HUgRb002433 for ; Tue, 8 Apr 2008 17:30:42 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m38HUflx018241 for ; Tue, 8 Apr 2008 11:30:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m38HUfZ8005900; Tue, 8 Apr 2008 12:30:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m38HUaMa005899; Tue, 8 Apr 2008 12:30:36 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 8 Apr 2008 12:30:36 -0500 From: Nicolas Williams To: Daniel Migault , anonsec@postel.org Message-ID: <20080408173036.GS16998@Sun.COM> Mail-Followup-To: Daniel Migault , anonsec@postel.org References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080407180003.GB16998@Sun.COM> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org On Mon, Apr 07, 2008 at 01:00:04PM -0500, Nicolas Williams wrote: > > < The State diagram with functions can be represented by the figure below: > > < [I removed mine] > > Er, could you send it again? Never mind. I've written one: | CREATE_LISTENER_LATCH() | | v +--------+ / |LISTENER|-------+ +--------+ | / | / | + | | v v +-----------+ +------|ESTABLISHED|<-------+ | +-----------+ | | | v | | +------+ | | +---------+ |BROKEN| | +----->|SUSPENDED| +------+ | +---------+ | | | | | v | +------+ | +-------->|CLOSED|<-------------+ +------+ > I'll review your "Interaction between LD and other IPsec Databases" > section next. I think your sections 4. and 4.1 mostly restate what a lot of the draft already says, but section 4.2 inspires me to add an example section. I think we need a section with a very simple sample PAD and SPD configuration as follows: - The PAD shall have one entry specifying a PKI trust anchor that peers' certificates must validate to. - The SPD will have a single PROTECT entry with address and port ranges for traffic selectors, and a single BYPASS entry for another set of addresses and ports. The protocol will be TCP in both cases. Events in the example will include: - Creation of a TCP listener - receipt of a TCP SYN for that listener and completion of the TCP handshake - An attempt to do establish a TCP connection for a different application - sending a TCP SYN - completion of the TCP handshake - Connection closing - Network events that result in conflicting SAD updates - Local conflicting SPD updates Nico -- _______________________________________________ From anonsec-bounces@postel.org Tue Apr 8 17:07:41 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38A83A6A69 for ; Tue, 8 Apr 2008 17:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YewBGAbKbNCR for ; Tue, 8 Apr 2008 17:07:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 221633A69D5 for ; Tue, 8 Apr 2008 17:07:40 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39007LN026563; Tue, 8 Apr 2008 17:00:07 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m38NxVv0026479 for ; Tue, 8 Apr 2008 16:59:32 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m38NxUTV016396 for ; Tue, 8 Apr 2008 23:59:31 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m38NxUIW035593 for ; Tue, 8 Apr 2008 17:59:30 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m38NxQF4006363; Tue, 8 Apr 2008 18:59:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m38NxPGf006362; Tue, 8 Apr 2008 18:59:25 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 8 Apr 2008 18:59:25 -0500 From: Nicolas Williams To: anonsec@postel.org Message-ID: <20080408235925.GW16998@Sun.COM> Mail-Followup-To: anonsec@postel.org, julien.ietf@laposte.net, lha@stacken.kth.se, Hannes Tschofenig Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: lha@stacken.kth.se, Hannes Tschofenig , julien.ietf@laposte.net Subject: [anonsec] [FWD: tsv-dir review of draft-ietf-btns-connection-latching-06] X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org Hannes sent this review and graciously allowed me to post it to the list. My responses will follow. Nico ----- Forwarded message from Hannes Tschofenig ----- Date: Tue, 08 Apr 2008 14:18:33 +0200 From: Hannes Tschofenig Subject: tsv-dir review of draft-ietf-btns-connection-latching-06 To: tsv-dir@ietf.org Cc: Nicolas.Williams@Sun.COM, julien.ietf@laposte.net, lha@stacken.kth.se I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. I had to review draft-ietf-btns-connection-latching-06 and I have to admit that I did not follow the work in the BTNS group. Hence, I had to read through all the drafts to understand what you are doing. In some sense I am thankful to Magnus that he assigned me this task since I would not have looked at this work otherwise. Sorry that my review arrives so late. I couldn't see specific issues from a transport area directorate point of view related to this document. With this respect the document is essentially fine. Many aspects in the draft would, however, best be verified by an implementation. I hope that someone has done that. Is there code available? Still, I would like to share some my thoughts with you when I read through your specs. Initially, I thought I knew what I could expect under the title of "Better-Than-Nothing security". I was looking for a "leap of faith" type of solution. As it turns out that this is only one aspect (and probably the least important one) and the overall security at the end (with the application layer authentication and channel bindings) in some other deployment modes provides good and deployable security. The next trap was obviously the term "channel binding" since I knew it from EAP already and it may have a different meaning, at least RFC 5056 "On the Use of Channel Bindings to Secure Channels" claims that it is different even though I did not really understood the argument. There are some assumptions these channel bindings in this work are somewhat difficult to understand, at least for me. For example, here is the definition from RFC 5056: " o Channel binding: the process of establishing that no man-in-the- middle exists between two end-points that have been authenticated at one network layer but are using a secure channel at a lower network layer. This term is used as a noun. " In some other places I got the impression that the authentication may happen at the application layer. I was wondering whether the ISO-OSI layer model is the important part of the story in order to capture the assumptions and applicability well (when the mechanism claims to be generic). The benefit of the work is also difficult to capture: * RFC 5056 indicates the benefit of the approach mainly related to performance. Example: " The main goal of channel binding is to be able to delegate cryptographic session protection to network layers below the application in hopes of being able to better leverage hardware implementations of cryptographic protocols. " * There is also the security aspect of providing security protection at the lower layer while authentication happens at the higher layers, such as transport protection from packet spoofing. This is described in draft-ietf-btns-prob-and-applic-06.txt (by potentially anticipating solutions in the BGP space). * draft-ietf-btns-prob-and-applic-06.txt points generally to benefits for different applications, such as the transport of voice-over-IP (VoIP), IMAP server communication, protecting transport connections for commercial web servers, transport for streaming media, file system protocols (such as iSCSI and NFS). * Finally, there are general discussions on the advantages providing security at lower layers and to avoid multiple authentication steps at different layers (see for example Section 2.2.3 of draft-ietf-btns-prob-and-applic-06.txt). The statements in Section 2.1.2 of draft-ietf-btns-prob-and-applic-06.txt ("Authentication Methods") appear wrong to me when considering EAP usage in IKEv2. The text says: "CA-signed certificates and pre-shared secrets are the only methods of authentications accepted by current IPsec and IKE specifications. " Reading through the documents I could imagine that some folks, who are supposed to be using some of these concepts, could get confused. Consider that you are also targeting application layer guys. They might not even come up with the idea to use IPsec and the documents have a heavy IPsec/IKE touch even though the concepts are more generally applicable (I believe). For example, when I look at http://tools.ietf.org/id/draft-johansson-http-tls-cb-02.txt that seems to fit into the entire stream of work. Maybe you went a bit too far with the abstraction and hence your work is not so easy to understand anymore. For example, the channel binding definition from RFC 5056 shown above does not fit nicely to something described in draft-johansson-http-tls-cb-02.txt; it more naturally fits into IPsec. I mentioned some of the benefits you see for your work. I would like to focus on one aspect only, namely VoIP security, since I worked in this space for a while now. As part of that work I never came across BTNS. On the other hand, nobody from the BTNS working group approached us either, particularly since you seem to assume that "we" are potential customers of your technology. I provide you a bit more details about what we do and maybe the stuff just sounds like "channel bindings" but in fact isn't. I don't know. In any case, it might show you that * you have not done a lot of marketing for your work (I hope you do not believe that everyone follows everything else going on in the IETF anyway and your work ends with writing a draft.) * every application case may be a bit different and there may not be so many usages for your stuff as you might think. For example, security vulnerabilities with TCP might not be a convincing argument for many people in the application area. They often have more severe attacks to worry about. In SIP we are working on a VoIP media security solution and after a long time we decided to go for DTLS-SRTP. The details don't matter but consider the following high-level framework http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-01.txt: +-----------+ +-----------+ |SIP | SIP/SDP |SIP | +------>|Proxy |----------->|Proxy |-------+ | |Server X | (+finger- |Server Y | | | +-----------+ print, +-----------+ | | +auth.id.) | | SIP/SDP SIP/SDP | | (+fingerprint) (+fingerprint,| | +auth.id.) | | | | v +-----------+ Datagram TLS +-----------+ |SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP | |User Agent | Media |User Agent | |Alice@X | <=================================> |Bob@Y | +-----------+ +-----------+ Legend: ------>: Signaling Traffic <-+-+->: Key Management Traffic <=====>: Data Traffic Figure 1: DTLS Usage in the SIP Trapezoid The entire exchange starts with a SIP traveling along the SIP proxy and carrying a fingerprint that identifies the certificate). The fingerprint story is essentially taken from http://www.ietf.org/rfc/rfc4572.txt. There are several ways one can do the authentication at the SIP layer; a more complicated story. Hence, just assume that Alice would be authenticated to Bob at the application layer (here SIP). The DTLS exchange between the end points is essentially not authenticated in many cases. To create a relationship between the SIP signaling session and the DTLS exchange (and the subsequent media) the fingerprint conveyed in the SIP exchange would refer to the certificate that will be presented for the TLS session. This might similar to your channel bindings idea even though we don't say anything about channel binding here at all (and I wouldn't even know why we should). We wouldn't make use of anything from draft-ietf-btns-connection-latching-06.txt or draft-ietf-btns-core-06.txt since we don't use IPsec. There are good reasons for not using IPsec in this space: SRTP is specifically designed for voice with a low overhead and the industry had already bought into it. The stuff is available in the respective devices in hardware. When we initially proposed RTP over DTLS (see http://tools.ietf.org/html/draft-tschofenig-avt-rtp-dtls-00) and we got beaten up for using the TLS record layer instead of SRTP. Consequence: We quickly changed to http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-00). There is, however, another document that could make use of some of your stuff, namely http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-host-identities-06.txt. It uses IPsec (as HIP currently uses IPsec) but I have to admit that it belongs more to the academic track rather than something that is pending deployment. Also related to to this work there is an old 3GPP specification that uses IPsec between the SIP User Agent and it's outbound SIP proxy. It does not use IKE but uses the authentication and key exchange defined in SIP (digest authentication) and SIP security agreement to essentially accomplish the same functionality as IKE. There, I believe, your IPsec API concept could have been useful. Unfortunately, that was many years before you did your work and hence they already did their own stuff. I am also not sure about the widespread deployment. Ciao Hannes PS: A minor comment regarding the following statement: " o Implementations that provide such programming interfaces SHOULD make available to applications any available NAT-related information about the peer: whether it is behind a NAT and, if it is, the inner and outer tunnel addresses of the peer. " I don't see how IKE would be able to obtain this information in a reliable fashion. I suggest to delete this paragraph. If you want to learn more about the complexity of NAT traversal I suggest to read through STUN, TURN, ICE and other BEHAVE documents. ----- End forwarded message ----- _______________________________________________ From anonsec-bounces@postel.org Tue Apr 8 18:20:31 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB65D3A69CB for ; Tue, 8 Apr 2008 18:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.485 X-Spam-Level: X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoGp2hD9ZquM for ; Tue, 8 Apr 2008 18:20:30 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id BA4EA28C0E2 for ; Tue, 8 Apr 2008 18:20:08 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3916cOd013667; Tue, 8 Apr 2008 18:06:38 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3915usP013562 for ; Tue, 8 Apr 2008 18:06:01 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3915ush006575 for ; Wed, 9 Apr 2008 01:05:56 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m3915s6v037797 for ; Tue, 8 Apr 2008 19:05:55 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m3915sGa006401; Tue, 8 Apr 2008 20:05:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m3915sX6006400; Tue, 8 Apr 2008 20:05:54 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 8 Apr 2008 20:05:54 -0500 From: Nicolas Williams To: Hannes Tschofenig Message-ID: <20080409010554.GN16999@Sun.COM> Mail-Followup-To: Hannes Tschofenig , tsv-dir@ietf.org, anonsec@postel.org, julien.ietf@laposte.net, lha@stacken.kth.se Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080408121833.249870@gmx.net> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: lha@stacken.kth.se, julien.ietf@laposte.net, anonsec@postel.org, tsv-dir@ietf.org Subject: Re: [anonsec] [FWD: tsv-dir review of draft-ietf-btns-connection-latching-06] X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org On Tue, Apr 08, 2008 at 14:18:33 +0200, Hannes Tschofenig wrote: > I've reviewed this document as part of the transport area > directorate's ongoing effort to review key IETF documents. These > comments were written primarily for the transport area directors, but > are copied to the document's authors for their information and to > allow them to address any issues raised. The authors should consider > this review together with any other last-call comments they > receive. Please always CC tsv-dir@ietf.org if you reply to or forward > this review. Thank you! > I had to review draft-ietf-btns-connection-latching-06 and I have to > admit that I did not follow the work in the BTNS group. Hence, I had > to read through all the drafts to understand what you are doing. In > some sense I am thankful to Magnus that he assigned me this task since > I would not have looked at this work otherwise. Sorry that my review > arrives so late. Thank you, that is a lot of reading. > I couldn't see specific issues from a transport area directorate point > of view related to this document. With this respect the document is > essentially fine. Thanks. I'm in the process of preparing -07, which will have some new material relevant to a tsv-dir review, namely listing the events for TCP, UDP and SCTP that cause creation/release of connection latches. These details are entirely obvious from -06, but I thought calling them out specifically would be useful, particularly for SCTP, whose multi-homing features might otherwise seem at odds with connection latching (it isn't). > Many aspects in the draft would, however, best be > verified by an implementation. I hope that someone has done that. Is > there code available? There exist two implementations, one in OpenSolaris and the other, IIRC, in OpenSwan. The OpenSolaris implementation is based on the informative model of connection latching in section 2.3 of -06, and it's not entirely complete, but it has been such as it is for years (since Solaris 9 was released). The source code is available at opensolaris.org and you can search it for ipsec_latch_t to get started. > Still, I would like to share some my thoughts with you when I read > through your specs. > > Initially, I thought I knew what I could expect under the title of > "Better-Than-Nothing security". I was looking for a "leap of faith" > type of solution. As it turns out that this is only one aspect (and > probably the least important one) and the overall security at the end > (with the application layer authentication and channel bindings) in > some other deployment modes provides good and deployable security. > > The next trap was obviously the term "channel binding" since I knew it > from EAP already and it may have a different meaning, at least RFC > 5056 "On the Use of Channel Bindings to Secure Channels" claims that > it is different even though I did not really understood the argument. > There are some assumptions these channel bindings in this work are > somewhat difficult to understand, at least for me. For example, here > is the definition from RFC 5056: > > " > o Channel binding: the process of establishing that no man-in-the- > middle exists between two end-points that have been authenticated > at one network layer but are using a secure channel at a lower > network layer. This term is used as a noun. > " > > In some other places I got the impression that the authentication may > happen at the application layer. I was wondering whether the ISO-OSI > layer model is the important part of the story in order to capture the > assumptions and applicability well (when the mechanism claims to be > generic). Authentication, indeed, is intended to happen at the application layer, but to keep things generic I opted to write of "network layers" (after all, the application layer is layer 7 in the OSI model, but authentication might happen at the presentation layer, as in RPCSEC_GSS, for example). > The benefit of the work is also difficult to capture: > > * RFC 5056 indicates the benefit of the approach mainly related to performance. Example: > " > The main goal of channel binding is to be able to delegate > cryptographic session protection to network layers below the > application in hopes of being able to better leverage hardware > implementations of cryptographic protocols. > " > > * There is also the security aspect of providing security protection > at the lower layer while authentication happens at the higher > layers, such as transport protection from packet spoofing. This is > described in draft-ietf-btns-prob-and-applic-06.txt (by potentially > anticipating solutions in the BGP space). That's one of several security benefits of channel binding. > * draft-ietf-btns-prob-and-applic-06.txt points generally to > benefits for different applications, such as the transport of > voice-over-IP (VoIP), IMAP server communication, protecting > transport connections for commercial web servers, transport for > streaming media, file system protocols (such as iSCSI and NFS). Indeed. I've not done any work towards applying BTNS, connection latching or channel binding to any of those areas. Except recently I've begun collaborating with others on channel binding to TLS for applications such as IMAP -- but that will not be using any BTNS WG technologies. > * Finally, there are general discussions on the advantages providing > security at lower layers and to avoid multiple authentication steps > at different layers (see for example Section 2.2.3 of > draft-ietf-btns-prob-and-applic-06.txt). > > The statements in Section 2.1.2 of > draft-ietf-btns-prob-and-applic-06.txt ("Authentication Methods") > appear wrong to me when considering EAP usage in IKEv2. The text > says: > > "CA-signed certificates and pre-shared secrets > are the only methods of authentications accepted by current IPsec and > IKE specifications. > " I think in the end-to-end IPsec case this is generally true, and in the SG use cases of IPsec it's generally false. The text could perhaps use some clarification on this point. > Reading through the documents I could imagine that some folks, who are > supposed to be using some of these concepts, could get confused. > Consider that you are also targeting application layer guys. They > might not even come up with the idea to use IPsec and the documents > have a heavy IPsec/IKE touch even though the concepts are more > generally applicable (I believe). For example, when I look at > http://tools.ietf.org/id/draft-johansson-http-tls-cb-02.txt that seems > to fit into the entire stream of work. Maybe you went a bit too far > with the abstraction and hence your work is not so easy to understand > anymore. For example, the channel binding definition from RFC 5056 > shown above does not fit nicely to something described in > draft-johansson-http-tls-cb-02.txt; it more naturally fits into IPsec. I think you must be referring to the trusted proxy termination of channels in draft-johansson-http-tls-cb-02. Although this notion is not described in RFC5056, it is a straightforward extension of the channel binding concept described in RFC5056. Leif, myself and others did consider whether to include that extension in RFC5056, but for want of finishing RFC5056 sooner, rather than later, we did not. > I mentioned some of the benefits you see for your work. I would like > to focus on one aspect only, namely VoIP security, since I worked in > this space for a while now. As part of that work I never came across > BTNS. On the other hand, nobody from the BTNS working group approached > us either, particularly since you seem to assume that "we" are > potential customers of your technology. I provide you a bit more > details about what we do and maybe the stuff just sounds like "channel > bindings" but in fact isn't. I don't know. In any case, it might show > you that * you have not done a lot of marketing for your work (I hope > you do not believe that everyone follows everything else going on in > the IETF anyway and your work ends with writing a draft.) Channel binding in general is, in fact gaining traction, and I think we'll soon see specifications for specific app protocols progressed and implementations deployed. > * every application case may be a bit different and there may not be > so many usages for your stuff as you might think. I agree. Channel binding has to be fit separately into each application that could benefit from it; it's not simply a matter of using existing channel binding "slots" in existing APIs -- even where they exist, as in the case of the GSS-API, there may be application-specific considerations that have to be taken into account. > For example, security vulnerabilities with TCP might not be a > convincing argument for many people in the application area. They > often have more severe attacks to worry about. I agree! > In SIP we are working on a VoIP media security solution and after a > long time we decided to go for DTLS-SRTP. The details don't matter but > consider the following high-level framework > http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-01.txt: > > +-----------+ +-----------+ > |SIP | SIP/SDP |SIP | > +------>|Proxy |----------->|Proxy |-------+ > | |Server X | (+finger- |Server Y | | > | +-----------+ print, +-----------+ | > | +auth.id.) | > | SIP/SDP SIP/SDP | > | (+fingerprint) (+fingerprint,| > | +auth.id.) | > | | > | v > +-----------+ Datagram TLS +-----------+ > |SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP | > |User Agent | Media |User Agent | > |Alice@X | <=================================> |Bob@Y | > +-----------+ +-----------+ > > Legend: > ------>: Signaling Traffic > <-+-+->: Key Management Traffic > <=====>: Data Traffic > > Figure 1: DTLS Usage in the SIP Trapezoid > > > The entire exchange starts with a SIP traveling along the SIP proxy > and carrying a fingerprint that identifies the certificate). The > fingerprint story is essentially taken from > http://www.ietf.org/rfc/rfc4572.txt. There are several ways one can do > the authentication at the SIP layer; a more complicated story. > > Hence, just assume that Alice would be authenticated to Bob at the > application layer (here SIP). The DTLS exchange between the end points > is essentially not authenticated in many cases. To create a > relationship between the SIP signaling session and the DTLS exchange > (and the subsequent media) the fingerprint conveyed in the SIP > exchange would refer to the certificate that will be presented for the > TLS session. > > This might similar to your channel bindings idea even though we don't > say anything about channel binding here at all (and I wouldn't even > know why we should). This is, in fact, channel binding, in the RFC5056 sense. You don't have to state it for it to be so. > We wouldn't make use of anything from > draft-ietf-btns-connection-latching-06.txt or > draft-ietf-btns-core-06.txt since we don't use IPsec. Indeed, you wouldn't. The BTNS problem and applicability statement does claim that BTNS and connection latching and channel binding would be useful for such applications, and, indeed, use BTNS WG technology for SIP. BUT, DTLS was there, and it was available sooner than these other things (which, in fact, aren't yet available). So, yes, you wouldn't use IPsec for SIP. In my opinion this is a failing of IPsec: you can't even conceive of using IPsec for an application like SIP with Internet-scale deployment without first adding connection latching and IPsec APIs. > There are good > reasons for not using IPsec in this space: SRTP is specifically > designed for voice with a low overhead and the industry had already > bought into it. The stuff is available in the respective devices in > hardware. When we initially proposed RTP over DTLS (see > http://tools.ietf.org/html/draft-tschofenig-avt-rtp-dtls-00) and we > got beaten up for using the TLS record layer instead of SRTP. > Consequence: We quickly changed to > http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-00). I was aware of this, and I agree. > There is, however, another document that could make use of some of > your stuff, namely > http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-host-identities-06.txt. > It uses IPsec (as HIP currently uses IPsec) but I have to admit that > it belongs more to the academic track rather than something that is > pending deployment. HIP effectively uses channel binding. > PS: A minor comment regarding the following statement: > > " > o Implementations that provide such programming interfaces SHOULD > make available to applications any available NAT-related > information about the peer: whether it is behind a NAT and, if it > is, the inner and outer tunnel addresses of the peer. > " > > I don't see how IKE would be able to obtain this information in a > reliable fashion. I suggest to delete this paragraph. IKEv2 has a NAT traversal feature. I use it all the time. It works. Nico -- _______________________________________________ From anonsec-bounces@postel.org Wed Apr 9 06:54:48 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B8528C244 for ; Wed, 9 Apr 2008 06:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tt9FaJDQhKDa for ; Wed, 9 Apr 2008 06:54:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id A80A13A68FB for ; Wed, 9 Apr 2008 06:54:46 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39Dbnbg005073; Wed, 9 Apr 2008 06:37:49 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39Daokm004837 for ; Wed, 9 Apr 2008 06:36:51 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id m28so2095801wag.13 for ; Wed, 09 Apr 2008 06:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:cc:content-type:message-id:sender; bh=uPYj7fuTN3Z4jMoxLVdFVxDKp+n5CYnY07cgO0Az1XA=; b=KUFNrN7Ug8o+5WaeAOKOzTPEF63GMU5iKFAOVTfBMCgz0vDx9rGhIkxRgsQT81OpYpFCL6i+knuNFNzRmUamkill8EbiBvfbO+BBvQufJ/kfgROtEGVJksQM9x942U5ali6esqRRzdTysJkKlC99DYnQjU881E55OUruYkUe87s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:cc:content-type:message-id:sender; b=gWp9cnouFYU1RDggzH7FXZkMgaE8sNIlRqfmBpuQTsUohTo0snaz3HxEFLV6hx5R3qhw4ZJrZEj34LRuZ5M4fF6lksxNVNik0lyIkN2/ovp4ScbcfB9VVF5B8nl8OHA6lS8kYgWMqXmymy1yHIjjXZzsQ6XJopVYx7iZsWaYYVE= Received: by 10.114.95.1 with SMTP id s1mr113621wab.162.1207748210006; Wed, 09 Apr 2008 06:36:50 -0700 (PDT) Received: from ?59.8.107.34? ( [59.8.107.34]) by mx.google.com with ESMTPS id q20sm440347pog.0.2008.04.09.06.36.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Apr 2008 06:36:49 -0700 (PDT) From: Julien Laganier To: anonsec@postel.org Date: Wed, 9 Apr 2008 15:36:50 +0200 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_yZM/HNE56vh7U/g" Message-Id: <200804091536.50852.julien.IETF@laposte.net> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: julien.laganier@gmail.com Cc: Love =?iso-8859-1?q?H=F6rnquist_=C5strand?= , "Vijay K. Gurbani" Subject: [anonsec] Fwd: Review of draft-ietf-btns-abstract-api-01 X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org --Boundary-00=_yZM/HNE56vh7U/g Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Folks, Vijay Gurbani has reviewed the BTNS abstract API and kindly agreed to let me forward it to the mailing list, please see it below. Many thanks to Vijay! --julien --Boundary-00=_yZM/HNE56vh7U/g Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: "Vijay K. Gurbani" : Review of draft-ietf-btns-abstract-api-01 Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on klee X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.7-deb Received: from mwinf8306.laposte.net (mwinf8306.laposte.net) by mwinb8204 (SMTP Server) with LMTP; Mon, 07 Apr 2008 21:45:50 +0200 X-Sieve: Server Sieve 2.2 Received: from meplus.info (localhost [127.0.0.1]) by mwinf8306.laposte.net (SMTP Server) with ESMTP id 469962400093 for ; Mon, 7 Apr 2008 21:45:50 +0200 (CEST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by mwinf8306.laposte.net (SMTP Server) with ESMTP id 0CB8C240008A for ; Mon, 7 Apr 2008 21:45:49 +0200 (CEST) X-ME-UUID: 20080407194550521.0CB8C240008A@mwinf8306.laposte.net Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m37JjIca019728; Mon, 7 Apr 2008 14:45:18 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m37JjFA28441; Mon, 7 Apr 2008 14:45:16 -0500 (CDT) Message-ID: <47FA79CB.7080905@alcatel-lucent.com> Date: Mon, 07 Apr 2008 14:45:15 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mcr@sandelman.ottawa.on.ca Cc: lha@stacken.kth.se, julien.ietf@laposte.net, tim.polk@nist.gov, Chris Newman , Lisa Dusseault , APPS-REVIEW@ietf.org, Eric Burger Subject: Review of draft-ietf-btns-abstract-api-01 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-me-spamlevel: not-spam X-me-spamrating: 34.957104 X-UID: 59350 X-Length: 10648 Dr. Richardson: I was asked by the Applications area to review draft-ietf-btns-abstract-api-01 and draft-ietf-btns-c-api. Here is a review of draft-ietf-btns-abstract-api-01; I will send out a review of draft-ietf-btns-c-api by the end of this week or early next week. draft-ietf-btns-abstract-api-01 ------------------------------- This is a valuable document to have for the exact reasons that the author mentions in S2. Having dispensed with why such a document is important, here are more focused comments on the contents of the draft. Designing a good and intuitive API is actually very hard (if you are interested, I can dig up some published literature on how to do a good enough job in designing one.) - S3, opening paragraph: s/major kinds of objects/major objects - S3, opening paragraph: objects are not "abstracted into unique opaque tokens" as much as they are *represented* by such constructs. I would suggest a rewrite as follows: OLD: Here we use the term "opaque token" to mean much what "object" means in a typical object-oriented programming language, but with no public fields (only methods or generic functions). NEW: The objects are represented by opaque tokens that can be used through the public accessor and mutator methods associated with the object. - S3: It is written that, "The API provides a mechanism to query the value of attributes of the token." Do you also provide a mechanism to change (or mutate) the state of the object? Or are all operations on the object read-only? I ask this because the Abstract promises that an application may "specify that IPsec should be used." If that is the case, then the application may have to use mutators to set the state of the object appropriately. And if that is the case, you may want to list the mutators in a separate section much as you intend to list accessors in a separate section (S9, which is currently empty). - S3.1: Is the pToken per socket? In other words, within a process, there may be many different sockets. Does each socket has a unique pToken? It seems from S3.1 that the answer is no; the pToken is per process. However, S5 says in its first paragraph that, "[an application] needs to get a protection token that is associated with the socket." Thus, it seems that each socket has a unique pToken. You may want to elaborate on this some more to set up the model correctly. - S3.1 says that "It SHOULD always be possible to obtain a current protection token for an established connection (whether for a connection-oriented transport protocol or for a "connected" UDP socket). that is equivalent to any previous protection token that was obtained." A few comments on this. First, note the spurious "." after the closing brace; please remove. Second, and this goes back to establishing the model of a pToken, is the pToken a singleton? That is, when an application gets the current pToken object, does that pToken object correspond to the one-and-only pToken object established in that process's space? Or is that pToken object a *clone* of the one-and-only pToken object (i.e., contents of the objects are the same, but they are distinct objects. Deleting one has no bearing on the other.) In software engineering terms, there is the concept of a singleton pattern that states that objects with this property are created only once within the system. Whenever an application wants to access a singleton object, the system passes a handle to the existing one-and-only singleton object to the caller. ISTM that a pToken is a singleton object, but then S5 confuses me because that seems to lend credence to the fact that there can be many pToken objects in a process, each corresponding to a socket created by the application. - S3.3 says that "It is permitted for one protection token to be replaced with another (equivalent) protection token due to a node moving, suspending and resuming, ..." This is perplexing, and points to the pToken NOT being a singleton object. If a node moves, why would the pToken be replaced? Some characteristics -- like the attachment point and network identifiers -- may change, but the pToken should remain the same object, right? Likewise, if the node is suspended, then presumably the state of the process is saved. The pToken, as any other variable in the system, will be saved and subsequently resurrected when the system resumes. So why is this a special case? I do not understand. - S4: "All symbols (functions, macros, etc.) defined by this API are prefixed with "ipsec_". " The draft does not specify any APIs as such. So this is probably a place-holder for the future. If so, okay. - S4: "Specific rules for capitalizations should be driven by the specific language binding." I don't think any modern languages mandates capitalization in naming objects, or methods; it is purely a syntactic sugar. You probably want to say instead: Specific rules for capitalizations for the identifiers following the prefix "ipsec_" should follow the local programming conventions. This draft does not mandate the convention to name objects or methods in any way beyond requiring the "ipsec_" prefix. - S5 says that: As the pToken will not change during the connection. (see notes about rekeying). A simple function is provided to return a pToken from a file descriptor. Many implementions are likely to implement this using getsockopt(2), but an interface in those terms is not specified in order to keep it more abstract, and therefore more portable. Some comments on this. First, note the gratuitous periods in the first 3 sentences. Second, and of more importance, is how do we design such an API? One way is to use the getsockopt(2) API that is mentioned and its disadvantages. If a decision is made not to go through this route, then something like pToken *ipsec_get_ptoken(const int sock); could be considered. The advantage is that this is close enough to the Unix system call int fileno(FILE *stream); that transforms a FILE * object into a file descriptor that the legions of *nix programmers would be happy. For non-*nix programmers ... well, they should move to *nix ;-) Just kidding. But seriously, the fileno() function has been in existence for so long that it is not tied to *nix platform only. - S5, fourth paragraph: s/received may be received may arrive/received may arrive - S5, fourth and fifth paragraphs: I am not sure I understand what is going on here. Is it the case that when a peer gets a datagram, it also gets some additional data -- the sending peer's pToken -- as ancillary data? If so, why would a peer send its pToken, which is presumably something to keep secret, to another peer? I am sure you had some reason to put this text in, it is just not apparent to the casual reader. - S6: s/do-not-care values./defaulted accordingly. - S7: Are these the properties of pToken objects or a pToken object template? The discussion involves default values, which leads me to think that they are template values. - S7, tunnelMode discussion. Since you have tunnelMode, do you also need transportMode? - S8: Are these the properties of iToken objects or a iToken object template? The discussion involves default values, which leads me to think that they are template values. - S8: s/LEAFOFFAITH/LEAPOFFAITH or better yet, LEAP_OF_FAITH; much more readable that way. - S9, 10, and 11 appear to be place-holders. - S11: Some things you may want to mention here is what do applications do when the IPSec characteristics set by one application are not acceptable to others? Unlike TLS, each application cannot choose the specific properties it wants applied to the channel. Also, if one application sets the IPSec characteristics, is it a problem if another one queries them and sends them to someone else? For instance, if the IPSec instance is using a group pre-shared key, what happens if one application surreptitiously sends the key to a malicious party? ISTM on a cursory reading that certain characteristics of the IPSec connection should not be made available to applications even on a read-only basis. Hope that helps! - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs --Boundary-00=_yZM/HNE56vh7U/g Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --Boundary-00=_yZM/HNE56vh7U/g-- From anonsec-bounces@postel.org Wed Apr 9 09:04:17 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7763B3A6D01 for ; Wed, 9 Apr 2008 09:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy7OSjdEMFtj for ; Wed, 9 Apr 2008 09:04:16 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 77EEA3A6B5A for ; Wed, 9 Apr 2008 09:04:16 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39Feu8n014641; Wed, 9 Apr 2008 08:40:56 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39FeZMt014518 for ; Wed, 9 Apr 2008 08:40:36 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m39FeZgC021845 for ; Wed, 9 Apr 2008 15:40:35 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m39FeYFZ054571 for ; Wed, 9 Apr 2008 09:40:35 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m39FeYKZ006732; Wed, 9 Apr 2008 10:40:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m39FeYMQ006731; Wed, 9 Apr 2008 10:40:34 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 9 Apr 2008 10:40:34 -0500 From: Nicolas Williams To: Daniel Migault Message-ID: <20080409154034.GA16998@Sun.COM> Mail-Followup-To: Daniel Migault , Daniel Migault , anonsec@postel.org References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <47FCD8DE.6020806@orange-ftgroup.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <47FCD8DE.6020806@orange-ftgroup.com> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org On Wed, Apr 09, 2008 at 04:55:26PM +0200, Daniel Migault wrote: > >I think we want something like: > > > > o INFORM(5-tuple, BREAK | SUSPEND) > > > >There's no return value for this function. > > > If it means messages will be only "BREAK" or "SUSPEND", I don't see now > other kind of messages for now, but I am not absolutely certain there > will not be other kind of messages (informative, log messages for > example....) There's a third message: "restored" (for transitions from SUSPENDED to ESTABLISHED). _______________________________________________ From anonsec-bounces@postel.org Wed Apr 9 09:13:09 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACCE23A6DAD for ; Wed, 9 Apr 2008 09:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNueNizDSWEV for ; Wed, 9 Apr 2008 09:13:08 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id DC4593A6D18 for ; Wed, 9 Apr 2008 09:13:08 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39FpmhI017793; Wed, 9 Apr 2008 08:51:48 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39Fpef8017749 for ; Wed, 9 Apr 2008 08:51:41 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m39Fpeva015326 for ; Wed, 9 Apr 2008 15:51:40 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m39Fpdog062387 for ; Wed, 9 Apr 2008 09:51:39 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m39Fpd30006748; Wed, 9 Apr 2008 10:51:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m39Fpdnv006747; Wed, 9 Apr 2008 10:51:39 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 9 Apr 2008 10:51:39 -0500 From: Nicolas Williams To: Daniel Migault Message-ID: <20080409155138.GC16998@Sun.COM> Mail-Followup-To: Daniel Migault , Daniel Migault , anonsec@postel.org References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <47FCD94F.6040108@orange-ftgroup.com> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org On Wed, Apr 09, 2008 at 04:57:19PM +0200, Daniel Migault wrote: > >Never mind. I've written one: > > > Here are my comments they might result from mis-interpretation of the > draft, but that how I understood it. > > On the figure there is a transition from LISTEN to ESTABLISH state. I > might be wrong but I understood LISTEN state as an established state for > Listener connection Latch. So I would not expect transition from > LISTEN to ESTABLISHED state. The only transition would be from LISTEN to > CLOSE state. I didn't know how to draw this, but yes, LISTEN *spawns* ESTABLISHED latches. I thinkI'll just add text to the diagram, or use a different style of line. _______________________________________________ From anonsec-bounces@postel.org Wed Apr 9 09:16:42 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9501F28C4D0 for ; Wed, 9 Apr 2008 09:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwrebiG3PShM for ; Wed, 9 Apr 2008 09:16:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 6852C3A6DB8 for ; Wed, 9 Apr 2008 09:16:17 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39FoTKG017478; Wed, 9 Apr 2008 08:50:29 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39Fo69Q017364 for ; Wed, 9 Apr 2008 08:50:07 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m39Fo5Fa014859 for ; Wed, 9 Apr 2008 15:50:06 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m39Fo5Rp060979 for ; Wed, 9 Apr 2008 09:50:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m39Fo5BZ006739; Wed, 9 Apr 2008 10:50:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m39Fo58p006738; Wed, 9 Apr 2008 10:50:05 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 9 Apr 2008 10:50:05 -0500 From: Nicolas Williams To: Daniel Migault Message-ID: <20080409155004.GB16998@Sun.COM> Mail-Followup-To: Daniel Migault , Daniel Migault , anonsec@postel.org References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080407193811.GK16998@Sun.COM> <47FCD90D.1000007@orange-ftgroup.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <47FCD90D.1000007@orange-ftgroup.com> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org On Wed, Apr 09, 2008 at 04:56:13PM +0200, Daniel Migault wrote: > Your figure is probably clearer than mine, and it is better to separate > the esp/ah layer from the key management layer. > The logical SPD is the combination of decorrelated SPD and ULP-driven > SPD. The figure mentions interaction between IKEv2 and the Logical SPD, > but I don't see interaction between UPL and the logical SPD. Maybe one > could add one arrow between ULP and the logical SPD. Yes, I need to fix that. It needs to be more like this: +--------------------------------------------+ | +--------------+ | | |Administrator | | | |apps | | | +--------------+ | | ^ ^ | | | | | user mode | v v | | +--------------+ +-------++--------+ | | |App | |IKEv2 || | | | | | | +---+ || +----+ | | | | | | |PAD| || |SPD | | | | | | | +---+ || +--^-+ | | | +--------------+ +-+-----++----+---+ | | ^ | | | +---|---------------------|-----------|------+ user/kernel mode | |syscalls | PF_KEY | | interface +---|---------------------|-----------|------+ | v | | | |+-------+ +------------|-----------|-----+| ||ULP | | IPsec key|manager | || |+-------+ | | +--------v----+|| | ^ ^ | | | Logical SPD ||| | | | | | +-----------^-+|| | | | | +-------+ | || kernel mode | | | | | | || | | | | +----------+ +--v--+ | || | | +-------->| Latch DB |<-->| SAD | | || | | | +----------+ +--^--+ | || | | +--------------------|------|--+| +-|-------------------------------v------v---+ | | IPsec Layer (ESP/AH) | | | | +-v------------------------------------------+ | IP Layer | +--------------------------------------------+ _______________________________________________ From anonsec-bounces@postel.org Wed Apr 9 10:21:28 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0FA3A68EF for ; Wed, 9 Apr 2008 10:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaPELrefRJGj for ; Wed, 9 Apr 2008 10:21:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 2AE5D3A68C7 for ; Wed, 9 Apr 2008 10:21:28 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39H19qO013294; Wed, 9 Apr 2008 10:01:09 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39H0R89012914 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 9 Apr 2008 10:00:28 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m39H0QjZ011077 for ; Wed, 9 Apr 2008 17:00:26 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m39H0Pf8046764 for ; Wed, 9 Apr 2008 11:00:26 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m39H0MEG006778; Wed, 9 Apr 2008 12:00:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m39H0M2x006777; Wed, 9 Apr 2008 12:00:22 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 9 Apr 2008 12:00:22 -0500 From: Nicolas Williams To: Daniel Migault , Daniel Migault , anonsec@postel.org Message-ID: <20080409170021.GE16998@Sun.COM> Mail-Followup-To: Daniel Migault , Daniel Migault , anonsec@postel.org References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080409155138.GC16998@Sun.COM> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org On Wed, Apr 09, 2008 at 10:51:39AM -0500, Nicolas Williams wrote: > On Wed, Apr 09, 2008 at 04:57:19PM +0200, Daniel Migault wrote: > > >Never mind. I've written one: > > > > > Here are my comments they might result from mis-interpretation of the > > draft, but that how I understood it. > > > > On the figure there is a transition from LISTEN to ESTABLISH state. I > > might be wrong but I understood LISTEN state as an established state for > > Listener connection Latch. So I would not expect transition from > > LISTEN to ESTABLISHED state. The only transition would be from LISTEN to > > CLOSE state. > > I didn't know how to draw this, but yes, LISTEN *spawns* ESTABLISHED > latches. I thinkI'll just add text to the diagram, or use a different > style of line. OK, how about this: | | v +--------+ / +----..|LISTENER|........ | : +--------+ : / | / | (e.g., TCP SYN receipt, + | : connect() call) : | | : v v | : +-----------+ | : +------|ESTABLISHED| | : | +--+-----^--+ | : | | | : | | | v | | : | +------------+-------+ | :........|.>|SUSPENDED (OPTIONAL)| | : | +---------+----------+ | : v | | : +------+ | | :.....>|BROKEN| | | +-+----+ +----------------------+ | | | |Legend: | | | | dotted lines denote | | | v | latch creation | | +------+ | solid lines denote | +-------------+--------> |CLOSED| | state transition | +------+ +----------------------+ PS: ASCII art drawing is fun! _______________________________________________ From anonsec-bounces@postel.org Wed Apr 9 10:45:58 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B544A3A67FF for ; Wed, 9 Apr 2008 10:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVkK8v8MFdd4 for ; Wed, 9 Apr 2008 10:45:57 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id A8CDD3A6F01 for ; Wed, 9 Apr 2008 10:45:23 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39Hau8h029370; Wed, 9 Apr 2008 10:36:56 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39Hae29029320 for ; Wed, 9 Apr 2008 10:36:41 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m39HaZdc026743 for ; Wed, 9 Apr 2008 17:36:40 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m39HaYJc007045 for ; Wed, 9 Apr 2008 11:36:35 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m39HaYFO006794; Wed, 9 Apr 2008 12:36:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m39HaXT3006793; Wed, 9 Apr 2008 12:36:33 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 9 Apr 2008 12:36:33 -0500 From: Nicolas Williams To: Daniel Migault Message-ID: <20080409173633.GF16998@Sun.COM> Mail-Followup-To: Daniel Migault , Daniel Migault , anonsec@postel.org References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <47FCFFEA.7020004@orange-ftgroup.com> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: anonsec@postel.org Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org On Wed, Apr 09, 2008 at 07:42:02PM +0200, Daniel Migault wrote: > It sounds good for me, maybe we should also add dot lines with the > CREATE_CONNECTION_LATCH function. Consider it done. > Can the LISTEN state be considered as something like a "larval state"? Yes. > Should we introduce in the same manner a CONNECTION state so that > listeners and connections object have similar state architecture? I guess I could. I'll play with it. This diagram is fairly busy though and I want to keep it simple. It needn't capture every subtlety :) Nico -- _______________________________________________ From anonsec-bounces@postel.org Wed Apr 9 11:22:06 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02943A68EF for ; Wed, 9 Apr 2008 11:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdaE8izfa73l for ; Wed, 9 Apr 2008 11:22:05 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id C9B7B28C221 for ; Wed, 9 Apr 2008 11:22:05 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39ID7cs012651; Wed, 9 Apr 2008 11:13:08 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39ICeML012536 for ; Wed, 9 Apr 2008 11:12:41 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m39ICeNi028629 for ; Wed, 9 Apr 2008 18:12:40 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m39ICdfs044733 for ; Wed, 9 Apr 2008 12:12:39 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m39ICd7p006810; Wed, 9 Apr 2008 13:12:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m39ICd70006809; Wed, 9 Apr 2008 13:12:39 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 9 Apr 2008 13:12:39 -0500 From: Nicolas Williams To: Daniel Migault , Daniel Migault , anonsec@postel.org Message-ID: <20080409181238.GG16998@Sun.COM> Mail-Followup-To: Daniel Migault , Daniel Migault , anonsec@postel.org References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> <20080409173633.GF16998@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080409173633.GF16998@Sun.COM> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org On Wed, Apr 09, 2008 at 12:36:33PM -0500, Nicolas Williams wrote: > On Wed, Apr 09, 2008 at 07:42:02PM +0200, Daniel Migault wrote: > > It sounds good for me, maybe we should also add dot lines with the > > CREATE_CONNECTION_LATCH function. > > Consider it done. > > > Can the LISTEN state be considered as something like a "larval state"? > > Yes. > > > Should we introduce in the same manner a CONNECTION state so that > > listeners and connections object have similar state architecture? > > I guess I could. I'll play with it. This diagram is fairly busy though > and I want to keep it simple. It needn't capture every subtlety :) OK, here it is. I think this is as busy as I want the state machine diagram to be. : : : v +--------+ : +------|LISTENER|........ : +----------------------+ | : +--------+ : : |Legend: | | : | dotted lines denote | | (e.g., TCP SYN receipt, : | latch creation | | : connect() call) : : | | | : v v | solid lines denote | | : +-----------+ | state transition | | : +------|ESTABLISHED| +----------------------+ | : | +-----------+ | : | | ^ | : | | | : | | | v | | : | +--------------------+ | :........|...>|SUSPENDED (OPTIONAL)| | : | +--------------------+ | : v | | : +------+ | | :.....>|BROKEN| | | +-+----+ | | | | | | | v | +---------------------------------+ | | |CLOSED (common to LISTENER and | +-------------+--------->| CONNECTION latches both) | +---------------------------------+ _______________________________________________ From anonsec-bounces@postel.org Wed Apr 9 21:33:24 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C873A6E85 for ; Wed, 9 Apr 2008 21:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrWIh-QboFZO for ; Wed, 9 Apr 2008 21:33:23 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 80C763A6E75 for ; Wed, 9 Apr 2008 21:33:23 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3A4QwS1011717; Wed, 9 Apr 2008 21:26:59 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3A4Q0LL011242 for ; Wed, 9 Apr 2008 21:26:01 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3A4Q0aE023320 for ; Thu, 10 Apr 2008 04:26:00 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m3A4Pxh9028500 for ; Wed, 9 Apr 2008 22:26:00 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m3A4Pupk008473; Wed, 9 Apr 2008 23:25:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m3A4Puwl008472; Wed, 9 Apr 2008 23:25:56 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 9 Apr 2008 23:25:56 -0500 From: Nicolas Williams To: Daniel Migault , Daniel Migault , anonsec@postel.org Message-ID: <20080410042555.GF8027@Sun.COM> Mail-Followup-To: Daniel Migault , Daniel Migault , anonsec@postel.org References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> <20080409173633.GF16998@Sun.COM> <20080409181238.GG16998@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080409181238.GG16998@Sun.COM> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org Thinking it over, the SUSPENDED and BROKEN states differ only in whether an implementation supports transitioning from SUSPENDED to ESTABLISHED. That difference is too small to warrant two states. So I'm going to merge those two states. That will make the state diagram simpler. Nico -- _______________________________________________ From anonsec-bounces@postel.org Thu Apr 10 07:43:43 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0E228C4FA for ; Thu, 10 Apr 2008 07:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pfwK4dJhgwP for ; Thu, 10 Apr 2008 07:43:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id B2B203A6B2A for ; Thu, 10 Apr 2008 07:43:39 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3AENS5P018947; Thu, 10 Apr 2008 07:23:29 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3AEM6nx018262 for ; Thu, 10 Apr 2008 07:22:07 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id a77so9752pyh.35 for ; Thu, 10 Apr 2008 07:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=pfnEqWMnzNm0eA7NePofBmGJYi2KRw+4rXVbUXj1+Yo=; b=jw4HdOup2Q+3EorGoeovfOvguc47NeZjBKaFPzoIj64zbPz1+Bgx+OOS6cKJM7lfGDVQ9IQJh9So8VPFkNy0UP2doQUdI5jf3C6nkYV62mdOOfsUAC5Bk7gnz9PBISwGkingDuArDMU6BeTY5Mw0W/+96/7C0ZZQ+OnI+Gk5vWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=OpyWz4okW+toF5GdokufSpglMq5QEHnlTEJFWv6iGP1sNxzHKpU7XG6hvZ+hrc4QDylrr3o9KKulCf6hoNkN69/l7WRl7Wk7DcyVKs5t8C3C1bENvS4BXIUWmkwe0XFu8qpQQNI4AOfJi3tpaLhXuazLT94EfFR81NGW7Es0KD4= Received: by 10.141.172.6 with SMTP id z6mr771799rvo.136.1207837322338; Thu, 10 Apr 2008 07:22:02 -0700 (PDT) Received: by 10.141.78.19 with HTTP; Thu, 10 Apr 2008 07:22:02 -0700 (PDT) Message-ID: Date: Thu, 10 Apr 2008 16:22:02 +0200 From: "Daniel Migault" To: "Daniel Migault" , "Daniel Migault" , anonsec@postel.org In-Reply-To: <20080410042555.GF8027@Sun.COM> MIME-Version: 1.0 References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> <20080409173633.GF16998@Sun.COM> <20080409181238.GG16998@Sun.COM> <20080410042555.GF8027@Sun.COM> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mglt.biz@gmail.com Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1872064858==" Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org --===============1872064858== Content-Type: multipart/alternative; boundary="----=_Part_9540_22145372.1207837322329" ------=_Part_9540_22145372.1207837322329 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, Apr 10, 2008 at 6:25 AM, Nicolas Williams wrote: > Thinking it over, the SUSPENDED and BROKEN states differ only in whether > an implementation supports transitioning from SUSPENDED to ESTABLISHED. > I personally like the idea of the SUSPEND state which is the state where problems have to be solved, as opposed to the ESTABLISHED state where Latched objects are running properly. Maybe there is a solution to drop the SUSPEND state and merge it with the BROKEN state by considering different transition condition from ESTABLISHED to BROKEN. I don't think we have too many states, and I eventually would add CONECTION larval state for LC objects. On the other hand, if I really had to drop one state I would rather drop larval state like the LISTEN state. > > That difference is too small to warrant two states. > > So I'm going to merge those two states. That will make the state > diagram simpler. > > Nico > -- Daniel -- Daniel Migault Orange Labs / Security Lab +33 (0) 1 45 29 60 52 +33 (0) 6 70 72 69 58 ------=_Part_9540_22145372.1207837322329 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Thu, Apr 10, 2008 at 6:25 AM, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
Thinking it over, the SUSPENDED and BROKEN states differ only in whether
an implementation supports transitioning from SUSPENDED to ESTABLISHED.

I personally like the idea of the SUSPEND state which is the state where problems have to be solved, as opposed to the ESTABLISHED state where Latched objects are running properly. 
Maybe there is a solution to drop the  SUSPEND state and merge it with the BROKEN state by  considering different transition condition from ESTABLISHED to BROKEN.

I don't think we have too many states, and I eventually would add  CONECTION larval state for LC objects. On the other hand, if I really had to drop one state I would rather drop larval state like the LISTEN state.
 

That difference is too small to warrant two states.

So I'm going to merge those two states.  That will make the state
diagram simpler. 

Nico
--

Daniel



--
Daniel Migault
Orange Labs / Security Lab
+33 (0) 1 45 29 60 52
+33 (0) 6 70 72 69 58 ------=_Part_9540_22145372.1207837322329-- --===============1872064858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --===============1872064858==-- From anonsec-bounces@postel.org Thu Apr 10 08:36:27 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52E03A68F7 for ; Thu, 10 Apr 2008 08:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKkQa2tN7kwE for ; Thu, 10 Apr 2008 08:36:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 5A38C3A698C for ; Thu, 10 Apr 2008 08:36:26 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3AFKGEh008243; Thu, 10 Apr 2008 08:20:17 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3AFJm6H008130 for ; Thu, 10 Apr 2008 08:19:49 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3AFJlWI026633 for ; Thu, 10 Apr 2008 15:19:47 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m3AFJk1D029901 for ; Thu, 10 Apr 2008 09:19:47 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m3AFJllT008660; Thu, 10 Apr 2008 10:19:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m3AFJgNk008659; Thu, 10 Apr 2008 10:19:42 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 10 Apr 2008 10:19:42 -0500 From: Nicolas Williams To: Daniel Migault Message-ID: <20080410151942.GH8027@Sun.COM> Mail-Followup-To: Daniel Migault , Daniel Migault , anonsec@postel.org References: <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> <20080409173633.GF16998@Sun.COM> <20080409181238.GG16998@Sun.COM> <20080410042555.GF8027@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Cc: Daniel Migault , anonsec@postel.org Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org On Thu, Apr 10, 2008 at 04:22:02PM +0200, Daniel Migault wrote: > Maybe there is a solution to drop the SUSPEND state and merge it with the > BROKEN state by considering different transition condition from ESTABLISHED > to BROKEN. That's exactly what I did: : v /--------\ : : +------|LISTENER|...... : : | \--------/ : : : +--------------------+ | : : : : |Legend: | | : : : : | dotted lines denote| | : : | latch creation | | (e.g., TCP SYN : : : | | | received, : : : | solid lines denote | | connect() : : : | state transition| | called, ...) v v : | | | : /-----------\ : | semi-solid lines | | : |ESTABLISHED| : | denote async | | \-----------/ : | notification | | : ^ | : +--------------------+ | : | | : | : | : (OPTIONAL) | : | : | v v | : /----------------\ | :.....>| BROKEN |.-.-.-.-.-> | \----------------/ | | | | | v | /------\ +------------------->|CLOSED| \------/ > I don't think we have too many states, and I eventually would add CONECTION > larval state for LC objects. On the other hand, if I really had to drop one > state I would rather drop larval state like the LISTEN state. Check out the above diagram. I think it's simple enough now. Nico -- _______________________________________________ From anonsec-bounces@postel.org Thu Apr 10 09:31:39 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509D33A6C6A for ; Thu, 10 Apr 2008 09:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPXUtHY3zDoq for ; Thu, 10 Apr 2008 09:31:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 107513A6780 for ; Thu, 10 Apr 2008 09:31:38 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3AGBtUk026652; Thu, 10 Apr 2008 09:11:55 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3AGAxpl026345 for ; Thu, 10 Apr 2008 09:11:00 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id t8so52637wxc.30 for ; Thu, 10 Apr 2008 09:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=q/3EwApfphzwnj6DdRQKWWUlY9h/jUPhcAmtEpt55uo=; b=jJtoZlajbkNAWmk/lxRU7vpB6YXqToruwq10CLGjkBHN+MW1P96ZFZB6JxikLFxfjeEvrby/i+2EjM15yoebsRb5msti40+tPTa9jfG4yX2nnLxWFg6vcXMR838xWJfNQMYLPj51UNlMzec1yEv8T3ret6xw2xByY4Ius6ZYLX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=oqhMpPZACw776SKdDU0DWEQO71cT7tIaNAk712YJp1obEzvzauqmvDwIlFLDlWcyS9mKVlI2hHDP6p8z4kF9Te25FxxNbo0pfQ5sLSYxGnlNyfHb9scg2ckInks2cPZVvJ7q+kvF/dIiuffHNe3ua9Errz1P5IV1RS+ignQBq2s= Received: by 10.141.175.5 with SMTP id c5mr851940rvp.281.1207843857984; Thu, 10 Apr 2008 09:10:57 -0700 (PDT) Received: by 10.141.78.19 with HTTP; Thu, 10 Apr 2008 09:10:57 -0700 (PDT) Message-ID: Date: Thu, 10 Apr 2008 18:10:57 +0200 From: "Daniel Migault" To: "Daniel Migault" , "Daniel Migault" , anonsec@postel.org In-Reply-To: <20080410151942.GH8027@Sun.COM> MIME-Version: 1.0 References: <20080407180003.GB16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> <20080409173633.GF16998@Sun.COM> <20080409181238.GG16998@Sun.COM> <20080410042555.GF8027@Sun.COM> <20080410151942.GH8027@Sun.COM> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: mglt.biz@gmail.com Subject: Re: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0794336024==" Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org --===============0794336024== Content-Type: multipart/alternative; boundary="----=_Part_9969_6315751.1207843857958" ------=_Part_9969_6315751.1207843857958 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This one is really great! Distinction of creation, state transition and notification with different lines really helps to clarify it! Daniel On Thu, Apr 10, 2008 at 5:19 PM, Nicolas Williams wrote: > On Thu, Apr 10, 2008 at 04:22:02PM +0200, Daniel Migault wrote: > > Maybe there is a solution to drop the SUSPEND state and merge it with > the > > BROKEN state by considering different transition condition from > ESTABLISHED > > to BROKEN. > > That's exactly what I did: > > > : > v > /--------\ : : > +------|LISTENER|...... : : > | \--------/ : : : +--------------------+ > | : : : : |Legend: | > | : : : : | dotted lines denote| > | : : | latch creation | > | (e.g., TCP SYN : : : | | > | received, : : : | solid lines denote | > | connect() : : : | state transition| > | called, ...) v v : | | > | : /-----------\ : | semi-solid lines | > | : |ESTABLISHED| : | denote async | > | \-----------/ : | notification | > | : ^ | : +--------------------+ > | : | > | : | : cleared> | : > | : (OPTIONAL) | : > | : | v v > | : /----------------\ > | :.....>| BROKEN |.-.-.-.-.-> > | \----------------/ > | | > > | | > | v > | /------\ > +------------------->|CLOSED| > \------/ > > > I don't think we have too many states, and I eventually would add > CONECTION > > larval state for LC objects. On the other hand, if I really had to drop > one > > state I would rather drop larval state like the LISTEN state. > > Check out the above diagram. I think it's simple enough now. > > Nico > -- > -- Daniel Migault Orange Labs / Security Lab +33 (0) 1 45 29 60 52 +33 (0) 6 70 72 69 58 ------=_Part_9969_6315751.1207843857958 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This one is really great! Distinction of creation, state transition and notification with different lines really helps to clarify it!
Daniel


On Thu, Apr 10, 2008 at 5:19 PM, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
On Thu, Apr 10, 2008 at 04:22:02PM +0200, Daniel Migault wrote:
> Maybe there is a solution to drop the  SUSPEND state and merge it with the
> BROKEN state by  considering different transition condition from ESTABLISHED
> to BROKEN.

That's exactly what I did:

  <CREATE_LISTENER_LATCH(3-tuple, ...)>
                 :
                 v    <CREATE_CONNECTION_LATCH(5-tuple, ...)>
            /--------\           :   :
     +------|LISTENER|......     :   :
     |      \--------/     :     :   :   +--------------------+
     |        :            :     :   :   |Legend:             |
     |        :            :     :   :   | dotted lines denote|
     |  <conn. trigger event>    :   :   |    latch creation  |
     |      (e.g., TCP SYN :     :   :   |                    |
     |       received,     :     :   :   | solid lines denote |
     |       connect()     :     :   :   |    state transition|
     |       called, ...)  v     v   :   |                    |
     |        :        /-----------\ :   | semi-solid lines   |
     |        :        |ESTABLISHED| :   |    denote async    |
     |    <conflict>   \-----------/ :   |    notification    |
     |        :         ^       |    :   +--------------------+
     |        :         |      <conflict>
     |        :    <conflict    |    :
     |        :     cleared>    |    :
     |        :    (OPTIONAL)   |    :
     |        :         |       v    v
     |        :      /----------------\
     |        :.....>|     BROKEN     |.-.-.-.-.-> <ALERT()>
     |               \----------------/
     |                       |
  <RELEASE_LATCH()>   <RELEASE_LATCH()>
     |                       |
     |                       v
     |                    /------\
     +------------------->|CLOSED|
                          \------/

> I don't think we have too many states, and I eventually would add  CONECTION
> larval state for LC objects. On the other hand, if I really had to drop one
> state I would rather drop larval state like the LISTEN state.

Check out the above diagram.  I think it's simple enough now.

Nico
--



--
Daniel Migault
Orange Labs / Security Lab
+33 (0) 1 45 29 60 52
+33 (0) 6 70 72 69 58 ------=_Part_9969_6315751.1207843857958-- --===============0794336024== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --===============0794336024==-- From anonsec-bounces@postel.org Mon Apr 14 00:47:50 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43EF03A69D3 for ; Mon, 14 Apr 2008 00:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcAh2wdD29z2 for ; Mon, 14 Apr 2008 00:47:49 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id ECBA73A67B2 for ; Mon, 14 Apr 2008 00:47:48 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3E7cAt6024459; Mon, 14 Apr 2008 00:38:11 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3E7Yq27023635 for ; Mon, 14 Apr 2008 00:34:53 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id e2so378207ugf.21 for ; Mon, 14 Apr 2008 00:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:user-agent:mime-version:cc:date:content-type:message-id:sender; bh=UBe8Bmv2Ys5W+qElh00ts3nWur+udWxR4GPk8pj0VC4=; b=lWZ/J0AkQ9KVmyEPd7VIo1GXsqZaPtioI6NYHRJ5TijbFtpaWBNQBC279Hf4/Njc7bbj6By/9Og3pJODMbByehWYQ/XrlQeYTtxe4br75whd95rjGbFLDUEJYKnW1/eI/CB/fvYIG0C7h+Yi2R8STQvGurY9m+2ASUMKh3ka4Qk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:user-agent:mime-version:cc:date:content-type:message-id:sender; b=QZEe2DqXt5hNKjN/EqsxPvHrEyOYAtvtq+6b9Y8g1rSfLkBOjOHiAY36jFzgC6W3CfXbEYPFopaMabyF0NJGKbywZOghRgpFR+voFP0lLHtAKS5S6fGyMtopfRcPPehtzBorYhRbnMmSaCyfxT4Df4vTcOndyIK9piVyFqWqdO0= Received: by 10.67.26.7 with SMTP id d7mr3542102ugj.23.1208158491427; Mon, 14 Apr 2008 00:34:51 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e34sm5298588ugd.17.2008.04.14.00.34.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Apr 2008 00:34:50 -0700 (PDT) From: Julien Laganier To: anonsec@postel.org User-Agent: KMail/1.9.6 MIME-Version: 1.0 Date: Mon, 14 Apr 2008 09:34:45 +0200 Content-Type: Multipart/Mixed; boundary="Boundary-00=_WkwAIK0umxmPpwQ" Message-Id: <200804140934.46272.julien.IETF@laposte.net> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: julien.laganier@gmail.com Cc: Love =?iso-8859-1?q?H=F6rnquist_=C5strand?= , "Vijay K. Gurbani" Subject: [anonsec] Fwd: Review of draft-ietf-btns-c-api-03 X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org --Boundary-00=_WkwAIK0umxmPpwQ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Folks, Vijay Gurbani has reviewed the BTNS C API and kindly agreed to let me forward it to the mailing list, please see it below. Many thanks to Vijay! --julien --Boundary-00=_WkwAIK0umxmPpwQ Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: "Vijay K. Gurbani" : Review of draft-ietf-btns-c-api-03 Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on ubik X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,UNPARSEABLE_RELAY autolearn=disabled version=3.2.3 Received: from mwinf8313.laposte.net (mwinf8313.laposte.net) by mwinb8204 (SMTP Server) with LMTP; Sun, 13 Apr 2008 00:37:24 +0200 X-Sieve: Server Sieve 2.2 Received: from meplus.info (localhost [127.0.0.1]) by mwinf8313.laposte.net (SMTP Server) with ESMTP id 8E5E22400081 for ; Sun, 13 Apr 2008 00:37:24 +0200 (CEST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by mwinf8313.laposte.net (SMTP Server) with ESMTP id 515DF2400085 for ; Sun, 13 Apr 2008 00:37:24 +0200 (CEST) X-ME-UUID: 20080412223724333.515DF2400085@mwinf8313.laposte.net Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m3CMaUfT022411; Sat, 12 Apr 2008 17:36:30 -0500 (CDT) Received: from [135.244.33.107] (vkg.lra.lucent.com [135.244.33.107]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m3CMaPA00225; Sat, 12 Apr 2008 17:36:27 -0500 (CDT) Message-ID: <48013960.4060105@lucent.com> Date: Sat, 12 Apr 2008 17:36:16 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mcr@sandelman.ottawa.on.ca, Nicolas.Williams@sun.com, miika@iki.fi, sasu.tarkoma@hiit.fi Cc: lha@stacken.kth.se, julien.ietf@laposte.net, Tim Polk , chris.newman@sun.com, lisa@osafoundation.org, Eric Burger , APPS-REVIEW@ietf.org Subject: Review of draft-ietf-btns-c-api-03 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-me-spamlevel: not-spam X-me-spamrating: 28.343602 X-UID: 60074 X-Length: 7892 Dr. Richardson et al.: I was asked by the Applications area to review draft-ietf-btns-c-api-03. Here is a review of it, following a similar one I did last week for draft-ietf-btns-abstract-api-01. draft-ietf-btns-c-api-03 ------------------------------- As a follow-up draft to draft-ietf-btns-abstract-api, the reasons why this document is important are much the same as why the latter one was important. I do note that this document appears to be more fleshed out than its abstract-api counterpart, whereas I would have expected the opposite. For instance, the Security Considerations section of the abstract-api I-D was empty, and the one for c-api is filled out. Ostensibly, the Security Considerations section for the abstract-api should be the one that could be filled out and "inherited", if you will, by a language-specific binding document that fulfills the abstract-api one. Furthermore, and I think this is important, the c-api document should do more to align itself with the abstract-api document since the latter document asserts the shape of the information in the c-api document. For instance, S2.3.2 of c-api contains the attributes of a pToken. Clearly, these are related to S7 of abstract-api (Properties of pToken objects). Likewise, S2.2.2 of c-api is similarly related to S8 of abstract-api. Currently, there is a lack of such close cross referencing between these documents. I suspect that the c-api is the first language binding document; thus, any time spent now in such cross-referencing will pay for itself later when c-api is used as a template for a Java-api or c++-api document. Here are more focused comments: - S1, end of first paragraph: (1) may be a good idea to provide a reference for HIP (also expand the acronym). SIP (RFC3261) may be another protocol that could use this API; S26.3.1 of rfc3261 does state that "Proxy servers, redirect servers, registrars, and UAs MAY also implement IPSec or other lower- layer security protocols." So conceivably, a user agent can create a connection to its proxy and use the IPSec APIs to figure out whether that connection is integrity and confidentiality protected. In certain networks (like IMS), IPSec is used fairly heavily between the UA and the proxy. - S1, third paragraph: (1) s/we defined APIs/we define APIs/ (2) s/document fulfisl/document fulfills/ (3) s/requirements presented in/requirements in/ (4) s/and present C-bindings/and presents C-bindings/ - S1, paragraph under Figure 1: s/'The third/The third - IMHO, it would be good to move S2.1 to *after* the attributes for pToken and iToken are defined. That way, the reader can make more sense of these APIs. As the draft currently stands, the reader does not know anything about the attributes when he or she reaches S2.1, so the discussion there appears out of place, without a good context. - S2.1, second paragraph: s/using malloc/from heap. - S2.1, second paragraph, last sentence: "When attr_val is NULL ... of the attr_val." I do not understand the need for this. If attr_val is NULL, why would it have a non-zero attr_len? Maybe I am missing somethng? - S2.1, last paragraph: You may want to mention that attr_val must not be NULL, and neither should attr_len. - S2.2.1, text under Figure 3: what does the size have to do with a c'tor and d'tor? I would suggest a re-write as follows: Operating environments that support the IPSec API will provide appropriate constructor and destructor for the iToken objects. Because applications will often not be aware of the byte-representation of the iToken object, nor will it know which attributes to initialize upon construction, applications MUST only use the provided constructor to create an iToken object, and when no longer needed, use the provided destructor to destroy it. Figure 4 shows the APIs: - S2.2.2, Figure 5: s/LEAFOFFAITH/LEAPOFFAITH Also, you may want to tie these attributes to S8 in abstract-api document. - S2.2.2, text under Figure 5: consider organizing the text in this paragraph to have hanging indents and such. It will make it much more readable. - S2.2.2, I do not understand the contents of the paragraph "The attributes for the second ... should be used." - S2.3.1, Figure 7: s/ipsec_create_pToken()/ipsec_create_pToken(void)/ The reason is that a func() is different than a func(void) under ANSI C. - S2.3.1, last paragraph of the section: what would cause ipsec_free_pToken() to return non-zero? About the only thing I can think of is if the parameter passed in is null. I believe we can in fact get by with having ipsec_free_pToken() return a void, but I will leave it to your good judgement. - S2.3.2: same comments as S2.3.1 about tying the attributes of pToken to abstract-api draft, and having hanging indents for readability. - S2.3.4, the text in first paragraph: I am curious why the decision to only support the IPSec APIs on sendmsg() and recvmsg()? I am sure you had a technical reason, but I cannot think of any. It may be a good idea to list the reason as a note in the draft. - S2.3.5: the text under Figure 11 mentions "ipsec_cmp_policy()". Did you mean "ipsec_cmp_pToken()" instead? - S2.3.5: in the text under Figure 11, you may want to mention that ipsec_cmp_pToken() returns non-zero if p1 != p2. - S2.3.6, Figure 12: should the type of "p" not be ipsec_pToken only? "p" is the source of the copy, and as such only a pointer to it is required, not a **. Plus, qualifying it with a const will probably not hurt. Hope that helps! Thank you. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs --Boundary-00=_WkwAIK0umxmPpwQ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --Boundary-00=_WkwAIK0umxmPpwQ-- From anonsec-bounces@postel.org Mon Apr 14 20:32:52 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3BF03A6DEE for ; Mon, 14 Apr 2008 20:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro60jADP5+iL for ; Mon, 14 Apr 2008 20:32:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id D2B0D3A6EB5 for ; Mon, 14 Apr 2008 20:32:38 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3F3GaPK013505; Mon, 14 Apr 2008 20:16:36 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3F3FwaN013326 for ; Mon, 14 Apr 2008 20:15:59 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id 02ED83A6DE2; Mon, 14 Apr 2008 20:15:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080415031502.02ED83A6DE2@core3.amsl.com> Date: Mon, 14 Apr 2008 20:15:01 -0700 (PDT) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: root@core3.amsl.com Cc: anonsec@postel.org Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-07.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Better-Than-Nothing Security Working Group of the IETF. Title : IPsec Channels: Connection Latching Author(s) : N. Williams Filename : draft-ietf-btns-connection-latching-07.txt Pages : 28 Date : 2008-04-14 This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS), thus connection latching can add a significant measure of protection to BTNS IPsec nodes. Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-btns-connection-latching-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14200917.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --NextPart-- From anonsec-bounces@postel.org Tue Apr 15 07:56:03 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B6A3A6EF7 for ; Tue, 15 Apr 2008 07:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRUy2U3ujXYq for ; Tue, 15 Apr 2008 07:56:02 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id C14DA3A6EF3 for ; Tue, 15 Apr 2008 07:56:02 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3FEWjTY024754; Tue, 15 Apr 2008 07:32:46 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3FEW2T2024417 for ; Tue, 15 Apr 2008 07:32:02 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3FEVvXK006677 for ; Tue, 15 Apr 2008 14:31:58 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m3FEVvY7051861 for ; Tue, 15 Apr 2008 08:31:57 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m3FEVv0B012623 for ; Tue, 15 Apr 2008 09:31:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m3FEVv6o012622 for anonsec@postel.org; Tue, 15 Apr 2008 09:31:57 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 15 Apr 2008 09:31:57 -0500 From: Nicolas Williams To: anonsec@postel.org Message-ID: <20080415143157.GH8027@Sun.COM> Mail-Followup-To: anonsec@postel.org Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Subject: [anonsec] Changes for draft-ietf-btns-connection-latching-07 X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org At Philadelphia I had a conversation with Daniel Migault about connection latching. Daniel's main insight was that the key task for us in this I-D was to make absolutely clear what is the impact of this work on the IPsec architecture, and that that impact is minimal, or none even. Daniel subsequently posted suggested text and ASCII art, and though I used very little of that text as is, Daniel's text and art inspired me to follow along those lines. So I made the following changes: - Simplified and clarified the connection latch state machine, including a state machine diagram. - Tailored the description of the normative model of connection latching to make clear that at its bare minimum it's just a purely local conflict detection and notification mechanism. - All features whereby local policy is logically updated are now optional, with clear warnings that no such logical policy updates survive reboots. - Added text to the security considerations section about the impact of this feature on the IPsec architecture. The impact of optional features is described in a separate section. - Added an informative diagram showing the relationships between various components of an IPsec w/ connection latching system, all in terms likely to be understood by operating systems developers. - Added a section describing how connection latching works for each of the three major transport protocols, even though all the details therein follow from the remainder of the draft. I thought it would be good to show that the details relating to SCTP were as simple as those relating to TCP. The URL to the rfcdiff tool for the diffs between -06 and -07 is: http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-btns-connection-latching-06.txt&url2=http://tools.ietf.org/id/draft-ietf-btns-connection-latching-07.txt [No, I've not yet spell-checked -07. I just noticed I misspelt "simultaneous" -- how embarrassing.] Nico -- _______________________________________________ From anonsec-bounces@postel.org Mon Apr 21 14:16:37 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3C73A6C64 for ; Mon, 21 Apr 2008 14:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScxSKMq-djiO for ; Mon, 21 Apr 2008 14:16:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id BA37D3A69AD for ; Mon, 21 Apr 2008 14:16:36 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3LKxBlx008807; Mon, 21 Apr 2008 13:59:12 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3LKw7vG008077 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 21 Apr 2008 13:58:08 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3LKvwX5016547 for ; Mon, 21 Apr 2008 20:58:07 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m3LKvwm9005785 for ; Mon, 21 Apr 2008 14:57:58 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m3LKvwqs017151 for ; Mon, 21 Apr 2008 15:57:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m3LKvwep017150 for anonsec@postel.org; Mon, 21 Apr 2008 15:57:58 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 21 Apr 2008 15:57:58 -0500 From: Nicolas Williams To: anonsec@postel.org Message-ID: <20080421205758.GM13552@Sun.COM> Mail-Followup-To: anonsec@postel.org References: <20080415143157.GH8027@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080415143157.GH8027@Sun.COM> User-Agent: Mutt/1.5.7i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: nicolas.williams@sun.com Subject: [anonsec] WGLC for connection-latching-07 (Re: Changes for draft-ietf-btns-connection-latching-07) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org Julian, Love, I think draft-ietf-btns-connection-latching-07 is ready for WGLC. Early May would be great. Nico -- _______________________________________________ From anonsec-bounces@postel.org Wed Apr 23 09:16:57 2008 Return-Path: X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB443A6C6A for ; Wed, 23 Apr 2008 09:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kFfKlUZfn64 for ; Wed, 23 Apr 2008 09:16:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id A82D33A6E27 for ; Wed, 23 Apr 2008 09:16:29 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3NFpi17029122; Wed, 23 Apr 2008 08:51:44 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3NFoqnu028800 for ; Wed, 23 Apr 2008 08:51:03 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 22so3939838fkq.13 for ; Wed, 23 Apr 2008 08:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Jnwui4Uak49Y3dIMNu0GGbCfAR5oFaO1EzZhk7iT1N4=; b=qMGgXPyuPMs9P8k7QrPGkk3Pe+sGxRR1IaWI9x4PQbE+A6oI5tIk5q37eNJKcCjGphB2F/2hw8Ao9yk8TpBK8Sv7b3/5NEO0z4pK3mZhiicxSikSx8C+h/XZjVjmq15vqmHkYB/vVRULDEYZfb4RlH5H6YtEEwzNEkOP6C6gV8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=jX/INF8z8ULjZZHMrvv81xRqrxQNpRCqJypNV8szupgbP0HrMRAowL1cuSqQolurlGTDyjQeLmzU+dweyXv7Hdik++fl+yPRkNBPWb0Uk6hKOnXVr9D8LpzdlduWT3gGyU32V8YI/AtpgwGTQzy+fIA5JhuNf2C/KRBhlIAejaw= Received: by 10.82.177.5 with SMTP id z5mr1201303bue.49.1208965851568; Wed, 23 Apr 2008 08:50:51 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id w5sm926131mue.2.2008.04.23.08.50.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Apr 2008 08:50:50 -0700 (PDT) From: Julien Laganier To: anonsec@postel.org Date: Wed, 23 Apr 2008 17:50:51 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20080415143157.GH8027@Sun.COM> <20080421205758.GM13552@Sun.COM> In-Reply-To: <20080421205758.GM13552@Sun.COM> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200804231750.52177.julien.IETF@laposte.net> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: julien.laganier@gmail.com Cc: Love =?iso-8859-15?q?H=F6rnquist_=C5strand?= Subject: Re: [anonsec] WGLC for connection-latching-07 (Re: Changes for draft-ietf-btns-connection-latching-07) X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org On Monday 21 April 2008, Nicolas Williams wrote: > Julian, Love, > > I think draft-ietf-btns-connection-latching-07 is ready for WGLC. > Early May would be great. All right. Let's do that then. --julien _______________________________________________