From jmpolk@cisco.com Wed Apr 1 08:00:19 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3FDA3A6DD2 for ; Wed, 1 Apr 2009 08:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAKd3G8DP2Dl for ; Wed, 1 Apr 2009 08:00:19 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 203DD3A6DCB for ; Wed, 1 Apr 2009 08:00:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="149113929" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 01 Apr 2009 15:01:19 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n31F1Jhe007338 for ; Wed, 1 Apr 2009 08:01:19 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n31F1HEj012899 for ; Wed, 1 Apr 2009 15:01:19 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 11:01:18 -0400 Received: from jmpolk-wxp01.cisco.com ([10.86.253.254]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 11:01:18 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Apr 2009 10:01:17 -0500 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2009 15:01:18.0636 (UTC) FILETIME=[B635BEC0:01C9B2DA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=394; t=1238598079; x=1239462079; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20WGLC=20for=20Port=20Randomization=20starts=20no w=20(April=201st) |Sender:=20; bh=kQF651cTDFkaK0yDs6ZXT628QabZL6oSx+jzJ583h38=; b=pky6dWt2KmND+HmsJcZVpt8V094a/aJ302Ee9unH+T15n3tQc6yHvmZtGz uDc9cQjTMl8oTXyTtO0bTaC1wEVPChv9P58j6MJS2bpGKGSoVbLjDgaic/iQ lEQQS+15oJ; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Tsvwg] WGLC for Port Randomization starts now (April 1st) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:00:19 -0000 WG This is the start of the WGLC for Port Randomization, which will last for 14 days - starting April 1st, going through April 15th. Please review this document and post comments to the TSVWG list and authors. Please find the latest version here http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-port-randomization/ cheers, James Lars Magnus IETF TSVWG co-chairs From rja@extremenetworks.com Fri Apr 3 09:24:18 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A293A685B for ; Fri, 3 Apr 2009 09:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 4mXXoh2sysOy for ; Fri, 3 Apr 2009 09:24:17 -0700 (PDT) Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by core3.amsl.com (Postfix) with ESMTP id B48A23A680D for ; Fri, 3 Apr 2009 09:24:17 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHJ00LM39LZYQ00@vms173015.mailsrvcs.net> for tsvwg@ietf.org; Fri, 03 Apr 2009 11:25:16 -0500 (CDT) Resent-message-id: <0KHJ00LM49LZYQ00@vms173015.mailsrvcs.net> Resent-to: tsvwg list IETF From: RJ Atkinson To: Michael Behringer In-reply-to: Resent-from: RJ Atkinson References: Message-id: Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit Resent-date: Fri, 03 Apr 2009 12:25:11 -0400 MIME-version: 1.0 (Apple Message framework v930.3) Date: Fri, 03 Apr 2009 08:29:21 -0700 X-Mailer: Apple Mail (2.930.3) Cc: Randall Atkinson Subject: Re: [Tsvwg] Next version of draft-ietf-tsvwg-rsvp-security-groupkeying-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:24:18 -0000 All, This -03 version seems to have resolved my previous comments. The additional detail makes it much more clear which mechanisms do and don't provide which capabilities. Thanks very much, Ran From lars.eggert@nokia.com Wed Apr 8 08:11:55 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8C93A6952 for ; Wed, 8 Apr 2009 08:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_10CONS_WORD=0.639, SARE_SUB_6CONS_WORD=0.356] 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 YqcrSyI+a5lL for ; Wed, 8 Apr 2009 08:11:54 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id DF29F3A68DA for ; Wed, 8 Apr 2009 08:11:51 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n38FCtpP084284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 8 Apr 2009 18:12:55 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: tsvwg@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-36-1050854054; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 18:12:55 +0300 X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 08 Apr 2009 18:12:55 +0300 (EEST) Subject: [Tsvwg] WG adoption of draft-stewart-tsvwg-sctpstrrst X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 15:11:55 -0000 --Apple-Mail-36-1050854054 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, during the WG meeting in SF, there was consensus to take on draft- stewart-tsvwg-sctpstrrst as a WG item in TSVWG. As always, we'd like to confirm this result on the list. If you disagree with this consensus decision, please speak up by April 15. Thanks, Lars --Apple-Mail-36-1050854054 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MDgxNTEyNTVaMCMGCSqGSIb3DQEJBDEWBBTsCKNKKnPMqNTC +V0EReWw3AV83DCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAQ5b6dphHLjuER/H1QOj94NxAAeOLcB40Z6M61zsUI6G+C+sA3Eux 9aOIk5hHiafQ0+2fdvPFeHt0tyc6zYSROZoaqY+hn2RqVE2ONp2mT1vK2X6JFA/IKvsQ8zkUm97/ lmnUUYcmXRIfegJ0mvZ1nLeG/2gsxtr0UheKmTWw/wrDg6Odzr03TGWwg2u4ukq2GEKgEqrLVSxl xosZu3eKuZ1As2jyq+UavcPdqhmRF9ekmb9WSCS7xTjQPfEcHNSi7P6NBqHfVoylpGKxhbad39aS 3RGkfnOnxwyw97RKbXWxOyeShtq67QU+o0f5EmVHTW3B3GtNULMg86BTRDfS2AAAAAAAAA== --Apple-Mail-36-1050854054-- From kg_mmmec@yahoo.com Mon Apr 13 02:24:42 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD82B3A6D21 for ; Mon, 13 Apr 2009 02:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.194 X-Spam-Level: * X-Spam-Status: No, score=1.194 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 TC7vsQ8KWeL5 for ; Mon, 13 Apr 2009 02:24:42 -0700 (PDT) Received: from n6-vm1.bullet.mail.in.yahoo.com (n6-vm1.bullet.mail.in.yahoo.com [202.86.4.133]) by core3.amsl.com (Postfix) with SMTP id 7FCD73A6CEE for ; Mon, 13 Apr 2009 02:24:41 -0700 (PDT) Received: from [202.86.4.171] by n6.bullet.mail.in.yahoo.com with NNFMP; 13 Apr 2009 09:25:51 -0000 Received: from [203.104.18.55] by t2.bullet.in.yahoo.com with NNFMP; 13 Apr 2009 09:25:50 -0000 Received: from [127.0.0.1] by omp107.mail.in2.yahoo.com with NNFMP; 13 Apr 2009 09:25:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 949756.90793.bm@omp107.mail.in2.yahoo.com Received: (qmail 72201 invoked by uid 60001); 13 Apr 2009 09:25:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1239614750; bh=7TbRiHO+WrJ0tiH6q7UyEZGIdcOkz8hZgG6+DLsG80E=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=6iY/dGvyILvrMLJZ9EMRvQQV/klVcM+a94wUnPTXfAVJCeGnfs8jOGbi7d83LP/N08PxWPmiMhO5tHdX3TBUSkUlg1dFsBMYzU9j8l68fhclzfA086UZ+VSWlZu0tigLOKOTp6et0z96E3lZ3EHG7yJzZE2ijuirMJ9CQO/W0/w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=t4RhgC9yXXoXhcZJ3+LzCDQEOTDE5bdCRBkYhSR+2wNrVnJUf7rKoGPqb6K8XfSEv4vyrz+FREQyFpN26IGeXhShHk1fA1Ykt1rJImyGysExX3cfONq6vX0s6rNQnyjAtMZz9Nr3luika3bVRd3dV5zcF+UrOBHxeeSQ3vNlvNg=; Message-ID: <817108.71381.qm@web94714.mail.in2.yahoo.com> X-YMail-OSG: Rj7_U7gVM1nGYurb1rzROFaF1iIIuEZtS1CYTbTAAWL4EGPTq4xYkorHNh7RMpHpb4PCV8hoShK9KzH8K54n5VMfiKjlIZP7tCslykN3VgLvIu7iTtq0sX4_ieT8b6Y7TNtbR_QXPMmIXneaI08arTzkIqmQwmlwMfez00Gjw6C3g_Gphma6XZ.CuVFKJvZztmMZJtUMTETu2U6cG9NQYQIkzsXZlpf.tQ_20vD_1GFCRkGWN7gtHhgZs9sat1jv Received: from [15.219.201.69] by web94714.mail.in2.yahoo.com via HTTP; Mon, 13 Apr 2009 14:55:50 IST X-Mailer: YahooMailClassic/5.2.15 YahooMailWebService/0.7.289.1 Date: Mon, 13 Apr 2009 14:55:50 +0530 (IST) From: kumar gaurav To: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1642722974-1239614750=:71381" Subject: [Tsvwg] SCTP: Reusing association in SHUTDOWN_SENT state X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 09:24:42 -0000 --0-1642722974-1239614750=:71381 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, =A0 =A0=A0=A0=A0=A0=A0 Section 5.2.2 of rfc 2960 allows the=A0reuse of an assoc= iation=A0in SHUTDOWN_SENT. i.e. if the other end of the association reconne= cts(after recovering from crash), association moves from SHUTDOWN_SENT to E= STABLISHED state. An association reaches SHUTDOWN_SENT state when an applic= ation either calls close or shutdown(SHUT_WR) on the socket.=A0In=A0both=A0= cases the application is not willing to=A0send any further data to the othe= r end of the connection.=20 =A0 I am not able to understand the=A0purpose of reusing an association in SHUT= DOWN_SENT state.Is there some special case where transition from SHUTDOWN_S= ENT to ESTABLISHED is useful from application point of view? =A0 Thanks, Gaurav=0A=0A=0A Add more friends to your messenger and enjoy! Go to ht= tp://messenger.yahoo.com/invite/ --0-1642722974-1239614750=:71381 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
 
       Section 5.2.2 of rfc 2960 allows = the reuse of an association in SHUTDOWN_SENT. i.e. if the other e= nd of the association reconnects(after recovering from crash), association = moves from SHUTDOWN_SENT to ESTABLISHED state. An association reaches SHUTD= OWN_SENT state when an application either calls close or shutdown(SHUT_WR) = on the socket. In both cases the application is not willing = to send any further data to the other end of the connection.
 
I am not able to understand the purpose of reusing an association= in SHUTDOWN_SENT state.Is there some special case where transition from SH= UTDOWN_SENT to ESTABLISHED is useful from application point of view?
 
Thanks,
Gaurav

=0A
= Add more friends to your messenger and enjoy! Invite them = now. --0-1642722974-1239614750=:71381-- From randall@lakerest.net Mon Apr 13 02:33:24 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91353A6B89 for ; Mon, 13 Apr 2009 02:33:24 -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 4nGT7V-F2P+e for ; Mon, 13 Apr 2009 02:33:23 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 456BB3A6C8A for ; Mon, 13 Apr 2009 02:33:23 -0700 (PDT) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n3D9YU0N083806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Apr 2009 05:34:31 -0400 (EDT) (envelope-from randall@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1239615271; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=FqU6vDOjxI2ULRwDKF8/Nds1O7v9gUiCtNv/EZKx1tiHPW9/B3lg6Zf 38A51LPRk0WY4w4+Tmuc6cJHdZlffPg== Message-Id: From: Randy Stewart To: kumar gaurav In-Reply-To: <817108.71381.qm@web94714.mail.in2.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 05:34:31 -0400 References: <817108.71381.qm@web94714.mail.in2.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP: Reusing association in SHUTDOWN_SENT state X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 09:33:24 -0000 Gaurav: You are overlooking the one-to-many socket model. Its possible on a one-to-many listener to close an association without doing shutdown() OR close(). For example I can do sd = socket(..); listen(sd..); ... sendmsg(..., addr1) recvmsg(... (from addr)..) semdmsg(..., addr1, SCTP_EOF) .. and still be talking to other endpoints that have connected to the socket. In such a case the peer at addr1 may do this. R On Apr 13, 2009, at 5:25 AM, kumar gaurav wrote: > Hi, > > Section 5.2.2 of rfc 2960 allows the reuse of an association > in SHUTDOWN_SENT. i.e. if the other end of the association > reconnects(after recovering from crash), association moves from > SHUTDOWN_SENT to ESTABLISHED state. An association reaches > SHUTDOWN_SENT state when an application either calls close or > shutdown(SHUT_WR) on the socket. In both cases the application is > not willing to send any further data to the other end of the > connection. > > I am not able to understand the purpose of reusing an association in > SHUTDOWN_SENT state.Is there some special case where transition from > SHUTDOWN_SENT to ESTABLISHED is useful from application point of view? > > Thanks, > Gaurav > > Add more friends to your messenger and enjoy! Invite them now. ----- Randall Stewart randall@lakerest.net From mbehring@cisco.com Tue Apr 14 14:08:42 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03EBE3A695B for ; Tue, 14 Apr 2009 14:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 T1HiH0eCBU7O for ; Tue, 14 Apr 2009 14:08:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C009C3A67A8 for ; Tue, 14 Apr 2009 14:08:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,187,1238976000"; d="scan'208";a="38296288" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2009 21:09:44 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3EL9iTk006375; Tue, 14 Apr 2009 23:09:44 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3EL9hIJ009098; Tue, 14 Apr 2009 21:09:43 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 23:09:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Apr 2009 23:09:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments at IETF74 regarding draft-ietf-tsvwg-rsvp-security-groupkeying-04 Thread-Index: Acm9RVNdkeEO+nTLRV6oKrN8sQalWQ== From: "Michael Behringer (mbehring)" To: "Bob Briscoe" X-OriginalArrivalTime: 14 Apr 2009 21:09:43.0937 (UTC) FILETIME=[555DBF10:01C9BD45] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2035; t=1239743384; x=1240607384; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbehring@cisco.com; z=From:=20=22Michael=20Behringer=20(mbehring)=22=20 |Subject:=20Comments=20at=20IETF74=20regarding=20draft-ietf -tsvwg-rsvp-security-groupkeying-04 |Sender:=20; bh=92aDsN/G3DgcG5NTBfkxqnsYOEKJUM2R8dVHEkNDzr4=; b=mmgOgT8VSjWCOMygJexlK5b6KGsgxF72ZOBY8wUANhaqBm1M23USB8H95A Ydphm+m7pWyvRN+xwkZOBHhCtp0eX7b0vdkKRvl4m7GXKkParOJG40dvlPXF XxPCwd5o3A; Authentication-Results: ams-dkim-2; header.From=mbehring@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: tsvwg@ietf.org Subject: [Tsvwg] Comments at IETF74 regarding draft-ietf-tsvwg-rsvp-security-groupkeying-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 21:08:42 -0000 Bob,=20 At the last IETF you made a comment at the microphone regarding=20 http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-security-groupkeying I wasn't there personally, but I believe your comment was along the lines: "tunnel mode with address preservation is subject to change of the outer address (like we pointed out for tunnel mode already), and this should be mentioned explicitly."=20 Do I capture your comment / suggestion correctly?=20 If so, would the following change in section 6.6 address your comment, or is it too simplistic? (suggested changes marked with ***) -- 6.6. Applicability of Tunnel Mode with Address Preservation The document "Multicast Extensions to the Security Architecture for the Internet Protocol" [RFC5374] defines in section 3.1 a new tunnel mode: Tunnel mode with address preservation. This mode copies the destination and optionally the source address from the inner header to the outer header. Therefore the encapsulated packet will have the same destination address as the original packet, and be normally subject to the same routing decisions. While [RFC5374] is focusing on multicast environments, tunnel mode with address preservation can be used also to protect unicast traffic in conjunction with group keying. Tunnel mode with address preservation, in conjunction with group keying, allows the use of IPsec AH or ESP for protection of RSVP even in cases where non-RSVP nodes have to be traversed. This is because it allows routing of the IPsec protected packet through the non-RSVP nodes in the same way as if it was not IPsec protected. ***Note that IPsec tunnel mode with address preservation is also susceptible to the man-in-the-middle attack described in section=20 6.2, since the outer header is not protected. This is a property of=20 IPsec tunnel mode; address-preservation does not change this property. -- Thanks for your help in reviewing this document!=20 Michael From mallman@icir.org Tue Apr 14 20:32:07 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF41B3A685C for ; Tue, 14 Apr 2009 20:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 b7rqN4eItgYC for ; Tue, 14 Apr 2009 20:32:06 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id C0A243A681A for ; Tue, 14 Apr 2009 20:32:06 -0700 (PDT) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n3F3XF0b007978; Tue, 14 Apr 2009 20:33:17 -0700 Received: from lawyers.icir.org (unknown [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 14CA9394DDA3; Tue, 14 Apr 2009 23:33:10 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F00C0CD585E; Tue, 14 Apr 2009 23:33:07 -0400 (EDT) To: "James M. Polk" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Given to Fly MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma21872-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 14 Apr 2009 23:33:07 -0400 Sender: mallman@icir.org Message-Id: <20090415033307.F00C0CD585E@lawyers.icir.org> Cc: tsvwg Subject: Re: [Tsvwg] WGLC for Port Randomization starts now (April 1st) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 03:32:08 -0000 ----------ma21872-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > This is the start of the WGLC for Port Randomization, which will > last for 14 days - starting April 1st, going through April > 15th. Please review this document and post comments to the TSVWG > list and authors. I read the document today. Comments: - The title is bogus. The prose carefully says that the document is not about port randomization, but about port obfuscation. The title should be corrected. - While the early part of the document does talk in terms of obfuscation and not randomization the entire document needs scrubbed because there are plenty of places where the document discusses "randomization" when it really means "obfuscation". I flagged a bunch of these but am not including them in this email because there are just too many. I suggest searching for "random" and fixing all the bogus instances. - Section 1: "tihs" --> "this" - Section 1: "produce a random" --> "produce a mathematically random" - Section 2.1: There is a claim that the ephemeral port space is "traditionally" from 49152-65535. I think it is more traditional for hosts to use monotonically increasing ports starting at 1024. Even if hosts do use this upper range they also use this lower range a bunch. I'd nuke this statement as probably wrong, but at least dubious. - Section 2.2: suggest tacking "at a given point in time" to the end of the last sentence. - In 2.2 and several other places the notion of a 'blind' attacker is stretched. I.e., the document discusses attackers that cannot see some particular connection directly but can view some other, perhaps related, communication with the host. It might be nice to see this developed when the concept of a 'blind attack' is developed because it isn't quite blind and it feels a little funny being introduced in the middle after we have been told the document deals with blind attacks. - In 2.3 you might note that an alternative approach is for both hosts to keep state about recent connections. I am not arguing it is a good approach or a bad approach...just an alternate approach that would work towards minimizing the collision rate. - In 3.1 collisions are discussed as "interoperability problems". I don't think that is quite right. I think the real issue is that there is added delay in getting things setup. - I found the notion of a bit array in 3.2 to be way too much detail. Just note that a host could introduce a system to track which port numbers are going to be used specifically by applications and leave it at that. The bit array isn't the Clear Right Answer so just leave the data structures out. - I think the notion: Although carefully chosen random sources and optimized five-tuple lookup mechanisms (e.g., optimized through hashing) will mitigate the cost of this verification, some systems may still not want to incur this search time. I remain of the opinion that this is just used-car-salesman talk. Hosts have to be able to associate incoming packets with connection state on every packet arrival. That is the same kind of lookup they have to do to check whether a chosen connection-id is in use. The above is simply FUD. Trying a couple of these connection-ids is in no way an onerous task. I strongly suggest this sentence be removed. - Further in 3.3.1 you note that web proxies and NATs are examples of systems that "create many connections from a single local IP address to a single service". I think that's pretty dubious. You might say that they make more connections to popular services than end hosts do (because of the aggregation) and thus increase the population of used ephemeral ports and hence the chance of collision using Alg. 1 or 2. But, I think it's sort of dubious to just leave it hanging as these things hit the problematic case as a matter of course, which is not generally true, I bet. - Again, the paragraph under "figure 3" is dubious. First, it is predicated on the notion that lookup time is somehow consequential, which is pretty off-the-mark as I noted above. Second, the data we have suggests that there are *less* port choices required to handle remote collisions with Alg. 2 when compared to Alg. 1. While that is not exactly what is being discussed in this section it seems like we can use remote collisions as a proxy here for what the local collision rate likely looks like. (See table 3 in [Allman].) And, in fact, going a step further nearly all the collisions are taken care of by two port choices. So, it's hard to believe that this playing up of the possibility of some arduous search through the port space is really warrented. - Perhaps I missed it, but it would be nice to define the "traditional BSD algorithm" early in the document. - Section 3.3.4: "that even a" --> "that a" - Section 3.3.4: "systems recommend" --> "systems we recommend" - Section 3.3.4: It'd be nice to see some reasoning about why a table size of 1024 is being recommended. It seems like this is arbitrarily pulled out of the air. I think it'd be fine to leave this to the implementer. I.e., note that [Allman] shows 10 entries will work fine for collision avoidance and increasing the table size increases the obfuscation and leave it at that. If you pick a number then at least motivate it somehow. - 3.3.5: "introduced yet another" --> "introduced another" - 3.3.5: The algorithm is wrong. This is my fault. The paper is not clear. Alas. When a collision is found we do not increment by one, but choose a new random increment. This is just not discussed in the paper, but should have been. However, I looked at the code for my simulator and that is how I did it. - 3.3.5: I'd like to see more prose about algorithm 5 to mirror the other sections. I.e., to give the intuition behind it, etc. - 3.5: You should likely add the caveat to our results that goes "in the two environments assessed" or something like that. - I think it's slanted that you sort of report results for Algorithms 1 and 2, but not for the remainder of the algorithms. The "sort of" being that you just say "they were the worst". We have numbers here. Let the data do the talking. - And, if I had one request about data it would be to note that no matter what algorithm is chosen the fraction of hosts we saw having *any* collisions is exceedingly small. I.e., the collision problem is really a non-problem for most cases. And, so it might be reasonable to use something dumb and simple in the general case and a little more expensive in a less general case. At least that's how I think the data really comes down. - [Allman] should be: Mark Allman. Comments On Selecting Ephemeral Ports. ACM Computer Communication Review, 39(2), April 2009. That's a pretty long list. But, I don't think there is really anything difficult in there. In general I think the document is in pretty decent shape, but I would like to see most of the above addressed before the document moves forward. FWIW. allman ----------ma21872-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknlVXMACgkQWyrrWs4yIs6rTwCfVBEY0Kx7skRgsl3Do6xprhaZ QNoAniJweDQNCAla1Oy9hUhxu9vqVXjG =vxiE -----END PGP SIGNATURE----- ----------ma21872-1-- From BeckW@telekom.de Wed Apr 15 01:06:51 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9FF23A6B46; Wed, 15 Apr 2009 01:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 WSO6-laIdbhF; Wed, 15 Apr 2009 01:06:50 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 6B9163A6A96; Wed, 15 Apr 2009 01:06:49 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 15 Apr 2009 10:08:00 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 10:08:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Apr 2009 10:07:59 +0200 Message-ID: <4A956CE47D1066408D5C7EB34368A511043C9C01@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [P2PSIP] Comments on draft-baset-tsvwg-tcp-over-udp-00 Thread-Index: Acm5ODXziTlh83yyQ+eRm/Fx+6QCtwEZX4Ow References: From: To: , X-OriginalArrivalTime: 15 Apr 2009 08:08:00.0488 (UTC) FILETIME=[4B252680:01C9BDA1] X-Mailman-Approved-At: Wed, 15 Apr 2009 03:38:56 -0700 Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] [P2PSIP] Comments on draft-baset-tsvwg-tcp-over-udp-00 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 08:06:51 -0000 =20 The figure in seection 2 describes ToU as a library. This is desirable for quick adoption, but is basically an implementation detail. The socket-like API in section 5 is of limited use if you want to mix ordinary file descriptors and libraries with ToU sockets (eg gtk_input_add, or Qt's QSocketNotifier). DLL trickeries might give better results. The draft doesn't discuss any timing constraints that a library implementer would have to meet: is it enough to check timers on every tou_ call? Or do I need a background thread? What information needs to be shared among several applications using ToU, like ISN and TCBs? Is this even possible if applications on a single system use different ToU libraries? (should this draft be discussed in p2psip or tsvwg?) Wolfgang From lars.eggert@nokia.com Wed Apr 15 07:54:27 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0283A6E0B for ; Wed, 15 Apr 2009 07:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 e18PU51oEHBi for ; Wed, 15 Apr 2009 07:54:26 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id CAAAC3A697A for ; Wed, 15 Apr 2009 07:54:24 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3FEtKKY045725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2009 17:55:20 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <40307809-6388-4F1C-8194-307E806EE642@nokia.com> From: Lars Eggert To: "mallman@icir.org" In-Reply-To: <20090415033307.F00C0CD585E@lawyers.icir.org> Content-Type: multipart/signed; boundary=Apple-Mail-7--492884967; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 17:55:19 +0300 References: <20090415033307.F00C0CD585E@lawyers.icir.org> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 15 Apr 2009 17:55:20 +0300 (EEST) Cc: "James M. Polk" , tsvwg Subject: Re: [Tsvwg] WGLC for Port Randomization starts now (April 1st) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:54:27 -0000 --Apple-Mail-7--492884967 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, thanks for the review, Mark. Authors, please discuss this review with Mark. The chairs think that eventually, a document revision will be needed to address the points that Mark has raised. Thanks, Lars On 2009-4-15, at 6:33, Mark Allman wrote: > >> This is the start of the WGLC for Port Randomization, which will >> last for 14 days - starting April 1st, going through April >> 15th. Please review this document and post comments to the TSVWG >> list and authors. > > I read the document today. Comments: > > - The title is bogus. The prose carefully says that the document is > not about port randomization, but about port obfuscation. The > title > should be corrected. > > - While the early part of the document does talk in terms of > obfuscation and not randomization the entire document needs > scrubbed > because there are plenty of places where the document discusses > "randomization" when it really means "obfuscation". I flagged a > bunch of these but am not including them in this email because > there > are just too many. I suggest searching for "random" and fixing all > the bogus instances. > > - Section 1: "tihs" --> "this" > > - Section 1: "produce a random" --> "produce a mathematically random" > > - Section 2.1: There is a claim that the ephemeral port space is > "traditionally" from 49152-65535. I think it is more traditional > for hosts to use monotonically increasing ports starting at 1024. > Even if hosts do use this upper range they also use this lower > range > a bunch. I'd nuke this statement as probably wrong, but at least > dubious. > > - Section 2.2: suggest tacking "at a given point in time" to the end > of the last sentence. > > - In 2.2 and several other places the notion of a 'blind' attacker is > stretched. I.e., the document discusses attackers that cannot see > some particular connection directly but can view some other, > perhaps > related, communication with the host. It might be nice to see this > developed when the concept of a 'blind attack' is developed because > it isn't quite blind and it feels a little funny being introduced > in > the middle after we have been told the document deals with blind > attacks. > > - In 2.3 you might note that an alternative approach is for both > hosts > to keep state about recent connections. I am not arguing it is a > good approach or a bad approach...just an alternate approach that > would work towards minimizing the collision rate. > > - In 3.1 collisions are discussed as "interoperability problems". I > don't think that is quite right. I think the real issue is that > there is added delay in getting things setup. > > - I found the notion of a bit array in 3.2 to be way too much detail. > Just note that a host could introduce a system to track which port > numbers are going to be used specifically by applications and leave > it at that. The bit array isn't the Clear Right Answer so just > leave the data structures out. > > - I think the notion: > > Although carefully chosen random sources and optimized five-tuple > lookup mechanisms (e.g., optimized through hashing) will mitigate > the cost of this verification, some systems may still not want to > incur this search time. > > I remain of the opinion that this is just used-car-salesman talk. > Hosts have to be able to associate incoming packets with connection > state on every packet arrival. That is the same kind of lookup > they > have to do to check whether a chosen connection-id is in use. The > above is simply FUD. Trying a couple of these connection-ids is in > no way an onerous task. I strongly suggest this sentence be > removed. > > - Further in 3.3.1 you note that web proxies and NATs are examples of > systems that "create many connections from a single local IP > address > to a single service". I think that's pretty dubious. You might > say > that they make more connections to popular services than end hosts > do (because of the aggregation) and thus increase the population of > used ephemeral ports and hence the chance of collision using Alg. 1 > or 2. But, I think it's sort of dubious to just leave it hanging > as > these things hit the problematic case as a matter of course, which > is not generally true, I bet. > > - Again, the paragraph under "figure 3" is dubious. First, it is > predicated on the notion that lookup time is somehow consequential, > which is pretty off-the-mark as I noted above. Second, the data we > have suggests that there are *less* port choices required to handle > remote collisions with Alg. 2 when compared to Alg. 1. While that > is not exactly what is being discussed in this section it seems > like > we can use remote collisions as a proxy here for what the local > collision rate likely looks like. (See table 3 in [Allman].) And, > in fact, going a step further nearly all the collisions are taken > care of by two port choices. So, it's hard to believe that this > playing up of the possibility of some arduous search through the > port space is really warrented. > > - Perhaps I missed it, but it would be nice to define the > "traditional > BSD algorithm" early in the document. > > - Section 3.3.4: "that even a" --> "that a" > > - Section 3.3.4: "systems recommend" --> "systems we recommend" > > - Section 3.3.4: It'd be nice to see some reasoning about why a table > size of 1024 is being recommended. It seems like this is > arbitrarily pulled out of the air. I think it'd be fine to leave > this to the implementer. I.e., note that [Allman] shows 10 entries > will work fine for collision avoidance and increasing the table > size > increases the obfuscation and leave it at that. If you pick a > number then at least motivate it somehow. > > - 3.3.5: "introduced yet another" --> "introduced another" > > - 3.3.5: The algorithm is wrong. This is my fault. The paper is not > clear. Alas. When a collision is found we do not increment by > one, > but choose a new random increment. This is just not discussed in > the paper, but should have been. However, I looked at the code for > my simulator and that is how I did it. > > - 3.3.5: I'd like to see more prose about algorithm 5 to mirror the > other sections. I.e., to give the intuition behind it, etc. > > - 3.5: You should likely add the caveat to our results that goes "in > the two environments assessed" or something like that. > > - I think it's slanted that you sort of report results for Algorithms > 1 and 2, but not for the remainder of the algorithms. The "sort > of" > being that you just say "they were the worst". We have numbers > here. Let the data do the talking. > > - And, if I had one request about data it would be to note that no > matter what algorithm is chosen the fraction of hosts we saw having > *any* collisions is exceedingly small. I.e., the collision problem > is really a non-problem for most cases. And, so it might be > reasonable to use something dumb and simple in the general case and > a little more expensive in a less general case. At least that's > how > I think the data really comes down. > > - [Allman] should be: > > Mark Allman. Comments On Selecting Ephemeral Ports. ACM > Computer > Communication Review, 39(2), April 2009. > > That's a pretty long list. But, I don't think there is really > anything > difficult in there. In general I think the document is in pretty > decent > shape, but I would like to see most of the above addressed before the > document moves forward. FWIW. > > allman > > > --Apple-Mail-7--492884967 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MTUxNDU1MjBaMCMGCSqGSIb3DQEJBDEWBBRP6gBRhFFnuNwy SLf8gu+KnATvxjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAgPF89Xl8dbfI5OXBWC0sQ/RKs6CL2IHR2d1aLyiiHRomFgS3wP6T lqAICzLCpwn4OmS2qdJI9SR9ulJIqYo/muAjw/JFvwb1E+O3AxUajPanN9g8pen0nlVW6+GIBlhe tDO4Fk/12FqBuFtJ22ubxkJS3w6yxQdp0Hx4RbSWCJzFLXpskh91+paq2zAk4gVx2QEv80FF3FmQ C9MEUCWH45saGA64t+SrdhgryZ+bWx/f/L7uYhWpswME6Qzfeth1xza/sTeObdXSckLG9vHh2tVv f+1pOew6PzSriWgP8YWUjRkgoj0/myfiwz6rXLX0t/qVk9uI8eIgbjOIEGl3PQAAAAAAAA== --Apple-Mail-7--492884967-- From fluffy@cisco.com Wed Apr 15 10:04:07 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6203A6ACB; Wed, 15 Apr 2009 10:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 RsTMo0gsFoHV; Wed, 15 Apr 2009 10:04:06 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 668D53A6975; Wed, 15 Apr 2009 10:04:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="171993542" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2009 17:05:14 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3FH5CO6017518; Wed, 15 Apr 2009 10:05:12 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3FH5B6A015941; Wed, 15 Apr 2009 17:05:12 GMT From: Cullen Jennings To: "" In-Reply-To: <4A956CE47D1066408D5C7EB34368A511043C9C01@S4DE8PSAAQC.mitte.t-com.de> Impp: xmpp:cullenfluffyjennings@jabber.org References: <4A956CE47D1066408D5C7EB34368A511043C9C01@S4DE8PSAAQC.mitte.t-com.de> Message-Id: <9E9E3463-AE80-496E-ACAE-C7B17AD9AAF4@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 11:05:10 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=153; t=1239815112; x=1240679112; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Tsvwg]=20[P2PSIP]=20Comments=20on=20dr aft-baset-tsvwg-tcp-over-udp-00 |Sender:=20; bh=U3ineUpXK9wailAkeS+nA1BSt8pDOlymA+qK6nbcUPo=; b=ID4wOwe4IjAxlpnpIDvGK2fLEkKauSjoDQbxokN84ERNYhPNFHXobVf77Y R1fPp5jvbIGpprOc9DR80H2r/NSH3E1WPT4pY3m8ZiexrALaRE/P8PQRxeSc bOhafPnEGm; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sa2086@columbia.edu, p2psip@ietf.org, tsvwg@ietf.org Subject: Re: [Tsvwg] [P2PSIP] Comments on draft-baset-tsvwg-tcp-over-udp-00 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 17:04:07 -0000 On Apr 15, 2009, at 2:07 AM, wrote: > > (should this draft be discussed in p2psip or tsvwg?) > tsvwg From lars.eggert@nokia.com Mon Apr 27 13:27:33 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2B73A6BF0 for ; Mon, 27 Apr 2009 13:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, SARE_SUB_10CONS_WORD=0.639, SARE_SUB_6CONS_WORD=0.356] 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 aHAE3+Fdsu-X for ; Mon, 27 Apr 2009 13:27:33 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 0EA003A6BA1 for ; Mon, 27 Apr 2009 13:27:31 -0700 (PDT) Received: from lars-2.vzbi.com (lars-2.vzbi.com [166.58.67.119]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3RKSkeU082009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Apr 2009 23:28:48 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <0895D967-10F8-4110-B527-7F54DC4BDCA4@nokia.com> From: Lars Eggert To: tsvwg In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-35-563916365; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 16:28:41 -0400 References: X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Mon, 27 Apr 2009 23:28:49 +0300 (EEST) Cc: draft-stewart-tsvwg-sctpstrrst@tools.ietf.org Subject: Re: [Tsvwg] WG adoption of draft-stewart-tsvwg-sctpstrrst X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 20:27:33 -0000 --Apple-Mail-35-563916365 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The consensus from SF has been confirmed. Authors, please submit the next version of this document as draft-ietf-tsvwg-sctp-strrst-00. Lars On 2009-4-8, at 11:12, Eggert Lars (Nokia-NRC/Espoo) wrote: > Hi, > > during the WG meeting in SF, there was consensus to take on draft- > stewart-tsvwg-sctpstrrst as a WG item in TSVWG. As always, we'd like > to confirm this result on the list. If you disagree with this > consensus decision, please speak up by April 15. > > Thanks, > Lars --Apple-Mail-35-563916365 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MjcyMDI4NDFaMCMGCSqGSIb3DQEJBDEWBBTDi3lIRnjUdTrT 2KZw2AfIy2IwyzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAKfP8SW+UjW8n0+j3TpSiGrBdP526dsGFOS5pBH1rICj6AD6WeI4d MDN9ECZJPEKa90myN3jZpP3ChJLqc7hIRevY1edaX4qF1F5ml2gUsZcaF6v6WxCCTkOwRl7Zcgjv em/l70vQ7/2kwYxBtYE4X3YqAQ8hk6BQeZJrREnpmM9zrHMBCVOJCKEd2726Sinfwsp5y4sATXK4 a4luByAT25IKg+krWyGrBKz1Q2UOlz50lwJxDG9E49/I+vUR/vCVb9KkhuR0FkqXjCTVpOZsqv68 omA5FLoA6B1RzLqfPlqySDCbeQZ6MB7W/U/OET6kA4aFUOPZWG9OLo7eZltbvgAAAAAAAA== --Apple-Mail-35-563916365-- From magnus.westerlund@ericsson.com Wed Apr 29 04:42:01 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378913A6AA0 for ; Wed, 29 Apr 2009 04:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 LRhQUf-pRIgE for ; Wed, 29 Apr 2009 04:42:00 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 772EB3A6918 for ; Wed, 29 Apr 2009 04:41:59 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb8ae000006a07-75-49f83d56ac76 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F1.2A.27143.65D38F94; Wed, 29 Apr 2009 13:43:19 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 13:43:18 +0200 Received: from [147.214.183.173] ([147.214.183.173]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 13:43:18 +0200 Message-ID: <49F83D56.4010704@ericsson.com> Date: Wed, 29 Apr 2009 13:43:18 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: tsvwg X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Apr 2009 11:43:18.0631 (UTC) FILETIME=[B0BDD770:01C9C8BF] X-Brightmail-Tracker: AAAAAA== Subject: [Tsvwg] Writeup for draft-ietf-tsvwg-rsvp-l3vpn-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 11:42:01 -0000 Doc shepherd writeup for draft-ietf-tsvwg-rsvp-l3vpn requested to be published as proposed standard by Magnus Westerlund (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document shepherd is Magnus Westerlund who has reviewed version 01 and believes it ready with a few exceptions that can be handed as AD evaluation comments. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has gotten review from both TSVWG RSVP expert and L3VPN WG people. No concerns over the level of review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns or issues. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It has strong consensus from the RSVP interested in the WG. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. ID-nits give some warnings due to that it was submitted prior to boiler plate changes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. No downward references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes, IANA section seems to be in order. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There is no formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Technical Summary RFC 4364 and RFC 4659 define an approach to building provider- provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to use RSVP to perform admission control on the links between CE and PE routers. This document specifies procedures by which RSVP messages travelling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported. Working Group Summary This document has been last called in both TSVWG and L3VPN. There is strong consensus from the RSVP interested in this document to publish it. Document Quality This document has gotten reviews from key people in TSVWG and L3VPN. Personnel Document Shepherd and Responsible AD Magnus Westerlund -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Apr 29 04:46:10 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000333A6AA0 for ; Wed, 29 Apr 2009 04:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 yNZxh0N1x4QV for ; Wed, 29 Apr 2009 04:46:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A4DF63A6859 for ; Wed, 29 Apr 2009 04:45:40 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb8ae000006a07-fe-49f83e35c2ff Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id FE.8A.27143.53E38F94; Wed, 29 Apr 2009 13:47:01 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 13:47:01 +0200 Received: from [147.214.183.173] ([147.214.183.173]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 13:47:01 +0200 Message-ID: <49F83E35.7070405@ericsson.com> Date: Wed, 29 Apr 2009 13:47:01 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Magnus Westerlund References: <49F83D56.4010704@ericsson.com> In-Reply-To: <49F83D56.4010704@ericsson.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Apr 2009 11:47:01.0305 (UTC) FILETIME=[35773290:01C9C8C0] X-Brightmail-Tracker: AAAAAA== Cc: tsvwg Subject: Re: [Tsvwg] Writeup for draft-ietf-tsvwg-rsvp-l3vpn-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 11:46:10 -0000 Magnus Westerlund skrev: > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. > > No concerns or issues. > Here I went a bit to fast. There is an IPR statement on this document: https://datatracker.ietf.org/ipr/989/ The WG was informed and no one has raised any concerns over the statement. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Apr 29 06:17:09 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76563A6D0D for ; Wed, 29 Apr 2009 06:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 8Y+L54BKkcg2 for ; Wed, 29 Apr 2009 06:17:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 722593A6EBE for ; Wed, 29 Apr 2009 06:17:08 -0700 (PDT) X-AuditID: c1b4fb3c-b7b4bae000001105-fe-49f853a4a3d0 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id AA.EC.04357.4A358F94; Wed, 29 Apr 2009 15:18:29 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 15:18:28 +0200 Received: from [147.214.183.173] ([147.214.183.173]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 15:18:28 +0200 Message-ID: <49F853A4.9070009@ericsson.com> Date: Wed, 29 Apr 2009 15:18:28 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: draft-ietf-tsvwg-rsvp-l3vpn@tools.ietf.org, tsvwg X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Apr 2009 13:18:28.0724 (UTC) FILETIME=[FC38E340:01C9C8CC] X-Brightmail-Tracker: AAAAAA== Subject: [Tsvwg] AD evaluation comments on draft-ietf-tsvwg-rsvp-l3vpn-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:17:10 -0000 Hi, I have done my AD review of "Support for RSVP in Layer 3 VPNs" and have some comments. 1. Section 1: "We note that similar techniques may be applicable to other protocols used for admission control such as NSIS [RFC4080]." Should this reference be to the QoS NSLP (draft-ietf-nsis-qos-nslp)? 2. Section 3.1, second paragraph: "However, MPLS VPN PE routers (especially those separated by Option-B ASBRs)" Use of ASBR without reference or expansion. 3. Section 5.1, first paragraph: There is talk about "CAC". This abbreviation is not expanded. Also, it is really approproate, why not use admission control simply? 4. Section 8.1: "The VPN- IPv4 address in this object is built by combining the IPv4 address from the incoming SESSION with the RD in the BGP advertisement from the egress PE for this prefix and customer." How is this combining done? Please provide either a reference or a normative description of how the combining is to happen and in which order. This definition issue reoccurs also in Section 8.2, 8.6 and 8.7. 5. Section 8.1: "The protocol ID, flags, and DstPort are identical to the IPv4 and IPv6 SESSION objects." Please provide a reference to that object. 6. Section 8.5: "The flags and DSCP are identical to the AGGREGATE-IPv4 and AGGREGATE-IPv6 SESSION objects." Reference to where these objects are defined. 7. Section 8.5: " The flags, PHB-ID, vDstPort and Extended vDstPort are identical to the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-IPv6 SESSION objects." Reference to their definition. 8. Section 10: What is the required to implement security functions for this RSVP extension? Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From rbriscoe@jungle.bt.co.uk Wed Apr 29 10:59:02 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2009B3A6934 for ; Wed, 29 Apr 2009 10:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] 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 fpss3IjlfqgL for ; Wed, 29 Apr 2009 10:58:55 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B06AB3A6BBD for ; Wed, 29 Apr 2009 10:58:54 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 19:00:16 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 19:00:15 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1241028014258; Wed, 29 Apr 2009 19:00:14 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n3TI0DcG009150; Wed, 29 Apr 2009 19:00:13 +0100 Message-Id: <200904291800.n3TI0DcG009150@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Apr 2009 19:00:24 +0100 To: "Michael Behringer (mbehring)" From: Bob Briscoe In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 29 Apr 2009 18:00:15.0769 (UTC) FILETIME=[599B3890:01C9C8F4] Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] Comments at IETF74 regarding draft-ietf-tsvwg-rsvp-security-groupkeying-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 17:59:02 -0000 Michael, Sorry for holding you up on this. inline... At 22:09 14/04/2009, Michael Behringer (mbehring) wrote: >At the last IETF you made a comment at the microphone regarding >http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-security-groupkeying > >I wasn't there personally, but I believe your comment was along the >lines: "tunnel mode with address preservation is subject to change of >the outer address (like we pointed out for tunnel mode already), and >this should be mentioned explicitly." My comment wasn't just about "tunnel mode with address preservation" as far as I recall. It was about AH in tunnel mode in general, as shown in slide 4 (and discussed in S6.3 of the draft). Slide 4 implied that AH tunnel mode only protects the inner IP header, while in fact I believe it also protects the immutable fields of the outer header (RFC4302 S3.1.2). Also your S6.3 omits to say AH tunnel mode protects the immutable fields of the outer header, although I think the spirit of the text implies that it does, when comparing ESP against AH. Whatever, it needs to be clearer. Am I right? "6.3. Using IPsec AH ... IPsec AH tunnel mode ... protects the entire original IP packet, including the IP header, IP options or extension headers, plus the entire RSVP packet. " A/plus the immutable fields of the outer header/ At the IETF I believed the slide, so I pointed out this would allow the outer header to be changed en route. However, having looked up RFC4302, I think the criticism should have been that the wording needs to be made clearer that AH tunnel mode protects the immutable fields in the outer header too. If this is correct, then using AH in tunnel mode to protect RSVP PATH messages would not make them vulnerable to being diverted. I've now read the latest version of the draft through (skipping unchanged parts) and, other than the above problem, it's a good one - a potentially useful addition to the RFC series. Thanks. Cheers Bob >Do I capture your comment / suggestion correctly? > >If so, would the following change in section 6.6 address your comment, >or is it too simplistic? (suggested changes marked with ***) > >-- >6.6. Applicability of Tunnel Mode with Address Preservation > > The document "Multicast Extensions to the Security Architecture for > the Internet Protocol" [RFC5374] defines in section 3.1 a new tunnel > mode: Tunnel mode with address preservation. This mode copies the > destination and optionally the source address from the inner header > to the outer header. Therefore the encapsulated packet will have the > same destination address as the original packet, and be normally > subject to the same routing decisions. While [RFC5374] is focusing > on multicast environments, tunnel mode with address preservation can > be used also to protect unicast traffic in conjunction with group > keying. > > Tunnel mode with address preservation, in conjunction with group > keying, allows the use of IPsec AH or ESP for protection of RSVP even > in cases where non-RSVP nodes have to be traversed. This is because > it allows routing of the IPsec protected packet through the non-RSVP > nodes in the same way as if it was not IPsec protected. > >***Note that IPsec tunnel mode with address preservation > is also susceptible to the man-in-the-middle attack described in >section > 6.2, since the outer header is not protected. This is a property of > IPsec tunnel mode; address-preservation does not change this >property. >-- > >Thanks for your help in reviewing this document! >Michael ________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research From jmpolk@cisco.com Wed Apr 29 15:26:39 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA0D28C27E for ; Wed, 29 Apr 2009 15:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BxMiaRrrD2sm for ; Wed, 29 Apr 2009 15:26:38 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 920AC28C2C8 for ; Wed, 29 Apr 2009 15:25:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,268,1238976000"; d="scan'208";a="157801143" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 29 Apr 2009 22:27:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3TMR5O6022531 for ; Wed, 29 Apr 2009 15:27:05 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3TMR5m7022072 for ; Wed, 29 Apr 2009 22:27:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 15:27:04 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.22.47]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 15:27:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Apr 2009 17:27:00 -0500 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Apr 2009 22:27:04.0680 (UTC) FILETIME=[9FA92E80:01C9C919] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=192; t=1241044025; x=1241908025; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20IETF74=20TSVWG=20Minutes=20posted |Sender:=20; bh=B+X/ITKrF346MQWF64KULulF/aJU5O1fJDy66A/r3AY=; b=WgGR7XrcehaZkDQ2drGr+2sUl9lqHgDnaRI1GG4ydq/T2zUf56rJZCjuHb QgOBHx7z85pgdNT2f2UQec/4G11MgwtdSa4CBqCj9d0azcx9aABQtdB+RPCZ UygPBaXBfK; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Tsvwg] IETF74 TSVWG Minutes posted X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 22:26:39 -0000 Please see the page at the following link for our TSVWG minutes http://www.ietf.org/proceedings/09mar/minutes/tsvwg.txt cheers, James Lars Magnus IETF TSVWG co-chairs From flefauch@cisco.com Wed Apr 29 21:53:41 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833573A6CAC for ; Wed, 29 Apr 2009 21:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.293 X-Spam-Level: X-Spam-Status: No, score=-10.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 sxQrc8xERYsY for ; Wed, 29 Apr 2009 21:53:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 03C123A69A1 for ; Wed, 29 Apr 2009 21:53:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,270,1238976000"; d="scan'208";a="39464921" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Apr 2009 04:55:01 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3U4t1IQ023575; Thu, 30 Apr 2009 06:55:01 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3U4t1vC001182; Thu, 30 Apr 2009 04:55:01 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 06:55:00 +0200 Received: from ams-flefauch-8712.cisco.com ([10.55.161.195]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 06:55:00 +0200 Message-Id: <2F11C221-5F16-411B-BBCB-F57F84D78882@cisco.com> From: Francois Le Faucheur IMAP To: "James M. Polk" , Lars Eggert In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 06:54:58 +0200 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 30 Apr 2009 04:55:00.0560 (UTC) FILETIME=[D12A9D00:01C9C94F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=761; t=1241067301; x=1241931301; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[Tsvwg]=20IETF74=20TSVWG=20Minutes=20po sted |Sender:=20; bh=B+zDo+ka3uXg/Q4XJ2qJTgjaFNcoGrK6+TPC5bBWIOw=; b=fGxVfxoesXaTc0lGe1JeOw8MDiAHdK6DIJvr5JjFWgVsOt3D6MPZRBwGim L2jEHQJHrp+dGRa867utKjUnK6Rj3rskRHwM9OhawdEAf2BkTBhxySOWP3oo j91RdPgRSC; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: tsvwg IETF list , ken carlberg Subject: Re: [Tsvwg] IETF74 TSVWG Minutes posted X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 04:53:41 -0000 Hello James, Lars, Regarding: " * Francois- Applicability of Keying Methods for RSVP Security draft-ietf-tsvwg-rsvp-security-groupkeying 1315-1325 (10 min) " ... 1) " Lars: Francois needs to lobby folks to review doc before there can be a WGLC " I understood Lars was also going to drop a note on the list to call for review volunteer. Can you do this? 2) " - who volunteers to review it? (no hands) " I believe Ken volunteered. Francois On 30 Apr 2009, at 00:27, James M. Polk wrote: > Please see the page at the following link for our TSVWG minutes > > http://www.ietf.org/proceedings/09mar/minutes/tsvwg.txt > > > cheers, > > James > Lars > Magnus > IETF TSVWG co-chairs