From midcom-bounces@ietf.org Mon Aug 01 08:52:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzZmC-0002FI-RZ; Mon, 01 Aug 2005 08:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzZm6-0002F3-BR for midcom@megatron.ietf.org; Mon, 01 Aug 2005 08:52:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06295 for ; Mon, 1 Aug 2005 08:52:07 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzaIK-0007Uj-Td for midcom@ietf.org; Mon, 01 Aug 2005 09:25:32 -0400 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j71Cq5Fo028509 for ; Mon, 1 Aug 2005 07:52:05 -0500 (CDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Aug 2005 08:52:04 -0400 Message-ID: <1B8C2E08B21B8743A2B3AED07407DA760975FE4E@nj7460exch002u.ho.lucent.com> From: "Townsend, Richard L, JR (Rick)" To: "'midcom@ietf.org'" Date: Mon, 1 Aug 2005 08:52:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [midcom] Available for MIDCOM discussions in Paris X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Hi all, Some of you may recall that I introduced a draft to MIDCOM entitled . I just spoke with Allison and she suggested that SAFENeT might be one of the several drafts on protocols for traversing NAT/FWs that could go forward as Experimental documents since it does address specific concerns for enterprise environments. Because MIDCOM is not meeting here in Paris, I want to make myself available in Paris during the meeting for off-line discussion on the pros and cons of SAFENeT and on how to proceed forward with a SAFENeT draft. Comments are welcome. Rick _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Mon Aug 01 11:45:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzcTi-0001y8-C6; Mon, 01 Aug 2005 11:45:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzcTg-0001wA-39 for midcom@megatron.ietf.org; Mon, 01 Aug 2005 11:45:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19219 for ; Mon, 1 Aug 2005 11:45:17 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzczw-0007Nc-SZ for midcom@ietf.org; Mon, 01 Aug 2005 12:18:43 -0400 Received: from openconcorde-21-115.ietf63.ietf.org (open-31-49.ietf63.ietf.org [86.255.31.49]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 39CDE1BAC4D; Mon, 1 Aug 2005 17:45:08 +0200 (CEST) Date: Mon, 01 Aug 2005 17:45:04 +0200 From: Juergen Quittek To: "Townsend, Richard L, JR (Rick)" , "'midcom@ietf.org'" Subject: Re: [midcom] Available for MIDCOM discussions in Paris Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Hi Rick, --On 8/1/2005 8:52 AM -0400 Townsend, Richard L, JR (Rick) wrote: > Hi all, > Some of you may recall that I introduced a draft to MIDCOM > entitled . I just spoke with Allison > and she suggested that SAFENeT might be one of the several drafts on > protocols for traversing NAT/FWs that could go forward as Experimental > documents since it does address specific concerns for enterprise > environments. I think I asked this before: Reading your draft, I have not seen any technical feature of SAFENeT in your draft that is specific for enterprise environments. All scenarios you describe are fully matched by the MIDCOM semantics and MIDCOM MIB. Would you explain which TECHNICAL feature of SAFENeT you see that do "address specific concerns for enterprise environments"? > Because MIDCOM is not meeting here in Paris, > I want to make myself available in Paris during the meeting for > off-line discussion on the pros and cons of SAFENeT and on how > to proceed forward with a SAFENeT draft. Comments are welcome. My first recommendation is positioning SAFENeT with respect to the MIDCOM requirements (RFC 3304), framework (RFC 3303) and protocol semantics (RFC 3989). Do you comply with these documents or do you differ from them. If you differ, it would be good to know which aspects are different. When would you be available for a discussion? Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Rick > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Mon Aug 01 12:26:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzd7w-00085l-0p; Mon, 01 Aug 2005 12:26:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzd7u-00084q-51 for midcom@megatron.ietf.org; Mon, 01 Aug 2005 12:26:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22086 for ; Mon, 1 Aug 2005 12:26:51 -0400 (EDT) Received: from wall.ikr.uni-stuttgart.de ([129.69.170.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzdeB-0000vZ-Bq for midcom@ietf.org; Mon, 01 Aug 2005 13:00:17 -0400 Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id A2DEA56D31; Mon, 1 Aug 2005 18:26:29 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 95451BD604; Mon, 1 Aug 2005 18:26:29 +0200 (CEST) Received: from ikr.uni-stuttgart.de (lnc6 [10.21.12.26]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id 4D3C0BD602; Mon, 1 Aug 2005 18:26:29 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Mon, 1 Aug 2005 18:26:29 +0200 Date: Mon, 1 Aug 2005 18:26:29 +0200 From: Sebastian Kiesel To: Juergen Quittek Subject: Re: [midcom] Available for MIDCOM discussions in Paris Message-ID: <20050801182629.D14540@ikr.uni-stuttgart.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from quittek@netlab.nec.de on Mon, Aug 01, 2005 at 05:45:04PM +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on netsrv1 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "'midcom@ietf.org'" X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Hi Rick, On Mon, Aug 01, 2005 at 05:45:04PM +0200, Juergen Quittek wrote: > Hi Rick, > > --On 8/1/2005 8:52 AM -0400 Townsend, Richard L, JR (Rick) wrote: > > > Hi all, > > Some of you may recall that I introduced a draft to MIDCOM > > entitled . I just spoke with Allison > > and she suggested that SAFENeT might be one of the several drafts on > > protocols for traversing NAT/FWs that could go forward as Experimental > > documents since it does address specific concerns for enterprise > > environments. > > I think I asked this before: Reading your draft, I have not seen any > technical feature of SAFENeT in your draft that is specific for enterprise > environments. > > All scenarios you describe are fully matched by the MIDCOM semantics > and MIDCOM MIB. > > Would you explain which TECHNICAL feature of SAFENeT you see that > do "address specific concerns for enterprise environments"? Or, if you believe that SAFENeT is better suited for enterprise environments because it is a "lightweight MIDCOM" and therefore easier to implement or to deploy, please state which requirements of MIDCOM (that cause a substantial effort) are not needed with SAFENeT? > > Because MIDCOM is not meeting here in Paris, > > I want to make myself available in Paris during the meeting for > > off-line discussion on the pros and cons of SAFENeT and on how > > to proceed forward with a SAFENeT draft. Comments are welcome. > > When would you be available for a discussion? I would be interested in a discussion, too. When? Thanks, Sebastian -- Sebastian Kiesel University of Stuttgart Tel: +49 711 685 7992 Institute of Communication Networks and Fax: +49 711 685 7983 Computer Engineering (IKR, formerly: IND) kiesel@ikr.uni-stuttgart.de Pfaffenwaldring 47, 70569 Stuttgart, Germany _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Tue Aug 02 03:56:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzrdl-0002YS-Lr; Tue, 02 Aug 2005 03:56:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzrdj-0002Xw-KQ for midcom@megatron.ietf.org; Tue, 02 Aug 2005 03:56:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28029 for ; Tue, 2 Aug 2005 03:56:41 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzsA9-0000mm-7B for midcom@ietf.org; Tue, 02 Aug 2005 04:30:15 -0400 Received: from [10.0.1.2] (w1x-10-68.ietf63.ietf.org [86.255.10.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0C4181BAC4D; Tue, 2 Aug 2005 09:56:31 +0200 (CEST) Date: Tue, 02 Aug 2005 09:56:26 +0200 From: Martin Stiemerling To: "Townsend, Richard L, JR (Rick)" , "'midcom@ietf.org'" Subject: Re: [midcom] Available for MIDCOM discussions in Paris Message-ID: In-Reply-To: <1B8C2E08B21B8743A2B3AED07407DA760975FE4E@nj7460exch002u.ho.lucent.com> References: <1B8C2E08B21B8743A2B3AED07407DA760975FE4E@nj7460exch002u.ho.luce nt.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org --On Montag, 1. August 2005 8:52 Uhr -0400 "Townsend, Richard L, JR (Rick)" wrote: | Hi all, | Some of you may recall that I introduced a draft to MIDCOM entitled | . I just spoke with Allison and she | suggested that SAFENeT might be one of the several drafts on protocols | for traversing NAT/FWs that could go forward as Experimental documents | since it does address specific concerns for enterprise environments. | Because MIDCOM is not meeting here in Paris, I want to make myself | available in Paris during the meeting for off-line discussion on the pros | and cons of SAFENeT and on how to proceed forward with a SAFENeT draft. | Comments are welcome. Rick I'm available for a meeting to talk about it but I would like to see the reasoning for SAFENeT beforehand. I think Juergen posted a question on this in his reply to your email. I'm still asking myself what your protocol is? Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Tue Aug 02 05:52:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztRk-00077d-E6; Tue, 02 Aug 2005 05:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztRh-00076V-NU for midcom@megatron.ietf.org; Tue, 02 Aug 2005 05:52:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03431 for ; Tue, 2 Aug 2005 05:52:23 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzty9-0005n2-Bd for midcom@ietf.org; Tue, 02 Aug 2005 06:25:58 -0400 Received: from [10.0.1.2] (w1x-10-68.ietf63.ietf.org [86.255.10.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 17C6B1BAC4D; Tue, 2 Aug 2005 11:52:14 +0200 (CEST) Date: Tue, 02 Aug 2005 11:52:08 +0200 From: Martin Stiemerling To: "Townsend, Richard L, JR (Rick)" , midcom@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Subject: [midcom] Basic question about SAFENeT I-D X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Hi Rick, I'm re-reading the SAFENeT I-D and have a basic question. It is about Section 2.4 "The MIDCOM and NSIS Solutions". You say this section is describes existing solutions on middlebox traversal and configuration. After reading it again, I still miss a reference to any already available/existing that refers to a MIDCOM-type solution. How about the FCP of Jiri Kuthan, MIDCOM MIB, or SIMCO? The solution described in Section 4.4 "Details of SAFENeT UA Communication Protocol (SUCP)" will fit to SIPPING working group and not MIDCOM. If not specified there, or in the SIP working group, already. I would like to see a clarification on this before we can meet face to face. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Tue Aug 02 06:07:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztgS-0003yr-Sy; Tue, 02 Aug 2005 06:07:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztgQ-0003yT-Q1 for midcom@megatron.ietf.org; Tue, 02 Aug 2005 06:07:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04655 for ; Tue, 2 Aug 2005 06:07:35 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuCt-0006XN-BW for midcom@ietf.org; Tue, 02 Aug 2005 06:41:11 -0400 Received: from wired-5-117.ietf63.ietf.org (wired-5-117.ietf63.ietf.org [86.255.5.117]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5ADB21BAC4D; Tue, 2 Aug 2005 12:07:28 +0200 (CEST) Date: Tue, 02 Aug 2005 12:07:24 +0200 From: Juergen Quittek To: Martin Stiemerling , "Townsend, Richard L, JR (Rick)" , midcom@ietf.org Subject: Re: [midcom] Basic question about SAFENeT I-D Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org --On 8/2/2005 11:52 AM +0200 Martin Stiemerling wrote: > Hi Rick, > > I'm re-reading the SAFENeT I-D and have a basic question. It is about > Section 2.4 "The MIDCOM and NSIS Solutions". You say this section is > describes existing solutions on middlebox traversal and configuration. > After reading it again, I still miss a reference to any already > available/existing that refers to a MIDCOM-type solution. How about > the FCP of Jiri Kuthan, MIDCOM MIB, or SIMCO? > > The solution described in Section 4.4 "Details of SAFENeT UA Communication > Protocol (SUCP)" will fit to SIPPING working group and not MIDCOM. If not > specified there, or in the SIP working group, already. > > I would like to see a clarification on this before we can meet > face to face. A meeting would be a great opportunity for clarifying this and other issues. Rick, when would you be available? Thanks, Juergen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Tue Aug 02 08:53:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwGU-0003pC-Qx; Tue, 02 Aug 2005 08:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwGQ-0003lB-SD for midcom@megatron.ietf.org; Tue, 02 Aug 2005 08:53:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16348 for ; Tue, 2 Aug 2005 08:52:57 -0400 (EDT) Received: from [69.55.225.91] (helo=www.implementers.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzwmu-0006IM-29 for midcom@ietf.org; Tue, 02 Aug 2005 09:26:33 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 537752A181B3; Tue, 2 Aug 2005 05:52:54 -0700 (PDT) Received: from [10.1.28.4] (localhost [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id C7A442A18199; Tue, 2 Aug 2005 05:52:49 -0700 (PDT) Message-ID: <42EF6CA1.7000708@acm.org> Date: Tue, 02 Aug 2005 05:52:49 -0700 From: Marc Petit-Huguenin User-Agent: Debian Thunderbird 1.0.2 (X11/20050611) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [midcom] updated TURN draft References: <42E553D5.4020009@cisco.com> In-Reply-To: <42E553D5.4020009@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Midcom X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Hi Jonathan, Let say that a SIP client sends an Offer with a TURN Derived Transport Address in the m/c line to a second endpoint. The second endpoint, according to RFC 3264, "MAY send media immediately.", but the RTP packets will be discarded because there is no permission for this source address. The Offerer will be able to add a permission only after receiving the Answer, so RTP packets will be lost. If it is an audio session that is established, this means losing partially or completely the first word said by the user of the called party. Jonathan Rosenberg wrote: > Folks, > > I did an update to the turn spec. I goofed on the I-D boilerplate, so > there is a good chance it won't make it into the repository, in which > case I'll submit right after ietf. Either way, you can pick up the > update draft here: > > http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-08.txt > > There are many changes from the previous version, addressing most of the > comments and concerns I have received privately and on the list. The > comment on the list I did not resolve yet is how the server can > differentiate TLS vs. regular TCP connections, the former used for > shared secret requests, the latter for allocate. > -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Professional: petithug@acm.org Work: marc@8x8.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Tue Aug 02 10:51:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzy6t-0001uV-4V; Tue, 02 Aug 2005 10:51:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzy6r-0001t1-S8 for midcom@megatron.ietf.org; Tue, 02 Aug 2005 10:51:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25678 for ; Tue, 2 Aug 2005 10:51:10 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzydL-0003YW-Lf for midcom@ietf.org; Tue, 02 Aug 2005 11:24:48 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j72Ep8Z9027545; Tue, 2 Aug 2005 09:51:08 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 2 Aug 2005 10:51:08 -0400 Message-ID: <1B8C2E08B21B8743A2B3AED07407DA760975FE5B@nj7460exch002u.ho.lucent.com> From: "Townsend, Richard L, JR (Rick)" To: "'Juergen Quittek'" , Martin Stiemerling , midcom@ietf.org Subject: RE: [midcom] Basic question about SAFENeT I-D Date: Tue, 2 Aug 2005 10:51:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Hi Juergen and Martin, Sorry to take so long getting back to you but I've been working an issue with my boss in another standards body. I took the opportunity over the past week to talk and develop a better understanding of where MIDCOM is in their decision process. Back to that in a minute. First let me address your questions. I put together a couple of slides last week that I can share with you. Slide 1: Assumptions for SAFENeT Optimized for enterprise environment with respect to security and performance Call Server owned by enterprise SIP-based, system supports S/MIME TLS using mutually authenticated certification for secure message exchange NAT vendors may implement their devices however they see fit, i.e., SAFENeT is not restricted in the type of NAT. Slide 2: Side by side comparison of SIMCO and SAFENeT SIMCO SAFENeT Target customer General, comprehensive Optimized for enterprise Call server ownership Call server could be owned by anybody Call server owned by enterprise Protocol binary ASCII Message transmittal - server to NAT/FW IPsec potentially across public realm TLS within enterprise (maybe with a shared key) Performance One message/command Assert better than current draft regarding traffic volume Versatility Could be extended to address Offers opportunity to address issues such as QoS Simplicity Binary is better ASCII addresses enterprise market so inexpensive is not an issue Explaining the advantages of SAFENeT in the table: Advantages of SAFENeT: Addresses higher level of security for those enterprises requiring it. Enterprise ownership of call server lowers risk of security attack, i.e., SIMCO uses messages to server to initiate NAT/FW actions remember, server could be within enterprise Protocol offers more functionality such as setting QoS parameters. Easier to establish/coordinate rules between server and NAT/FW, i.e., administered by same enterprise IT group. Protocol for reservation lowers traffic volume with more control given to the (enterprise owned) call server, i.e., can reserve in blocks. ************************** Having stated that let me state what I believe (and I could be wrong) what the status in MIDCOM is. The group has done and published an RFC on protocol evaluation (RFC 4097) and in that analysis, SNMP came out the winner. It may need some simple extensions but it is the best of the group. The people I talked with believe SIMCO is on a track towards Experimental RFC. The IESG rules allow more than one Experimental RFC from a group. I now realize that with RFC 4097, my goal of SAFENeT becoming an RFC is either premature, unrealizable, or both. So let me take a more realistic position and note that, given the advantages I see as noted above, SAFENeT should be offered as being on an Experimental RFC track too. While others may not see or agree with the advantages I see, we do have a client who does, one who looks on security as uppermost. Let me add that I see nothing wrong with SIMCO nor the decision by th egroup on SNMP. I just see an advantage for a simpler, higher performance and more secure spec on which to build a product (and restricts some of its messaging in the provision process); and yes, it gives up something concerning the comprehensive nature of the others. I hope the above clarifies my position. I'll be in BEHAVE and MSEC this afternoon although there isn't much time after either of those. Would meeting after PKI4IPSEC be better? I could stay in the room after to be easier to find. Rick -----Original Message----- From: Juergen Quittek [mailto:quittek@netlab.nec.de] Sent: Tuesday, August 02, 2005 6:07 AM To: Martin Stiemerling; Townsend, Richard L, JR (Rick); midcom@ietf.org Subject: Re: [midcom] Basic question about SAFENeT I-D --On 8/2/2005 11:52 AM +0200 Martin Stiemerling wrote: > Hi Rick, > > I'm re-reading the SAFENeT I-D and have a basic question. It is about > Section 2.4 "The MIDCOM and NSIS Solutions". You say this section is > describes existing solutions on middlebox traversal and configuration. > After reading it again, I still miss a reference to any already > available/existing that refers to a MIDCOM-type solution. How about > the FCP of Jiri Kuthan, MIDCOM MIB, or SIMCO? > > The solution described in Section 4.4 "Details of SAFENeT UA Communication > Protocol (SUCP)" will fit to SIPPING working group and not MIDCOM. If not > specified there, or in the SIP working group, already. > > I would like to see a clarification on this before we can meet > face to face. A meeting would be a great opportunity for clarifying this and other issues. Rick, when would you be available? Thanks, Juergen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Tue Aug 02 11:31:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzyjd-0008Jp-HE; Tue, 02 Aug 2005 11:31:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzyjb-0008HF-Tu for midcom@megatron.ietf.org; Tue, 02 Aug 2005 11:31:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29110 for ; Tue, 2 Aug 2005 11:31:13 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzG5-0005fk-4c for midcom@ietf.org; Tue, 02 Aug 2005 12:04:51 -0400 Received: from wired-5-117.ietf63.ietf.org (wired-6-133.ietf63.ietf.org [86.255.6.133]) by kyoto.netlab.nec.de (Postfix) with ESMTP id AB44A1BAC4D; Tue, 2 Aug 2005 17:31:02 +0200 (CEST) Date: Tue, 02 Aug 2005 17:31:00 +0200 From: Juergen Quittek To: "Townsend, Richard L, JR (Rick)" , Martin Stiemerling , midcom@ietf.org Subject: RE: [midcom] Basic question about SAFENeT I-D Message-ID: <079E79432A80A9BFB35422E2@wired-6-133.ietf63.ietf.org> In-Reply-To: <1B8C2E08B21B8743A2B3AED07407DA760975FE5B@nj7460exch002u.ho.lucent.com> References: <1B8C2E08B21B8743A2B3AED07407DA760975FE5B@nj7460exch002u.ho.lucent.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Rick, Thanks for the information you sent. Please find comments inline. --On 8/2/2005 10:51 AM -0400 Townsend, Richard L, JR (Rick) wrote: > Hi Juergen and Martin, > > Sorry to take so long getting back to you but I've been working an issue > with my boss in another standards body. > I took the opportunity over the past week to talk and develop a better > understanding of where MIDCOM is in their decision process. > Back to that in a minute. > > First let me address your questions. I put together a couple of slides > last week that I can share with you. > > Slide 1: Assumptions for SAFENeT > Optimized for enterprise environment with respect to security and performance > Call Server owned by enterprise I am still curious to see what your optimization you achieved that is not achieved by MIDCOM. > SIP-based, system supports S/MIME > TLS using mutually authenticated certification for secure message exchange > NAT vendors may implement their devices however they see fit, i.e., SAFENeT > is not restricted in the type of NAT. Do you also support NAT-PT? I could not find it in your draft, because your protocol is not specified in there. The draft just gives examples of SAFENeT messages. > Slide 2: Side by side comparison of SIMCO and SAFENeT Sorry, this is hard to read. Do you have a PPT of PDF version of your slide? > SIMCO SAFENeT > Target customer General, comprehensive Optimized for enterprise > Call server ownership Call server could be owned by anybody Call server owned by enterprise > Protocol binary ASCII > Message transmittal - server to NAT/FW IPsec potentially across public realm TLS within enterprise (maybe with a shared key) > Performance One message/command Assert better than current draft regarding traffic volume > Versatility Could be extended to address Offers opportunity to address issues such as QoS > Simplicity Binary is better ASCII addresses enterprise market so inexpensive is not an issue > > Explaining the advantages of SAFENeT in the table: > > Advantages of SAFENeT: > > Addresses higher level of security for those enterprises requiring it. Which what technical feature. I do not see it yet. You say you disallow running SAFENeT over public Internet. This implies that you have less need for security. Right? > Enterprise ownership of call server lowers risk of security attack, > i.e., SIMCO uses messages to server to initiate NAT/FW actions > remember, server could be within enterprise MIDCOM MIB, SIMCO and any other protocol complying with the MIDCOM semantics work very well when owned by an enterprise that operates its own network. What is technically different for SAFENeT except that you say it cannot operate in the public Internet? > Protocol offers more functionality such as setting QoS parameters. Yes, this is a technical difference. MIDCOM is not dealing with QoS configuration. > Easier to establish/coordinate rules between server and NAT/FW, > i.e., administered by same enterprise IT group. Which is true for all MIDCOM protocols. > Protocol for reservation lowers traffic volume with more control > given to the (enterprise owned) call server, i.e., can reserve in > blocks. Reserving of blocks is also supported by the MIDCOM semantics. > ************************** > > Having stated that let me state what I believe (and I could be wrong) what the status in MIDCOM is. > > The group has done and published an RFC on protocol evaluation > (RFC 4097) and in that analysis, SNMP came out the winner. > It may need some simple extensions but it is the best of the group. > > The people I talked with believe SIMCO is on a track towards Experimental RFC. I think Martin and I submitted it individually as an Informational RFC. It complies with the MIDCOM semantics, it has been discussed by the MIDCOM WG, but it is not an output of the MIDCOM WG. > The IESG rules allow more than one Experimental RFC from a group. Yes, certainly. > I now realize that with RFC 4097, my goal of SAFENeT becoming an > RFC is either premature, unrealizable, or both. So let me take a > more realistic position and note that, given the advantages I see > as noted above, SAFENeT should be offered as being on an > Experimental RFC track too. While others may not see or agree with > the advantages I see, we do have a client who does, one who looks > on security as uppermost. > > Let me add that I see nothing wrong with SIMCO nor the decision by > the group on SNMP. I just see an advantage for a simpler, higher > performance and more secure spec on which to build a product (and > restricts some of its messaging in the provision process); and yes, > it gives up something concerning the comprehensive nature of the others. Please substantiate your claims that SAFENeT is - simpler - providing higher performance - more secure than existing solutions. Thanks, Juergen > I hope the above clarifies my position. > > I'll be in BEHAVE and MSEC this afternoon although there isn't much time > after either of those. Would meeting after PKI4IPSEC be better? > I could stay in the room after to be easier to find. > > Rick > > > > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > Sent: Tuesday, August 02, 2005 6:07 AM > To: Martin Stiemerling; Townsend, Richard L, JR (Rick); midcom@ietf.org > Subject: Re: [midcom] Basic question about SAFENeT I-D > > --On 8/2/2005 11:52 AM +0200 Martin Stiemerling wrote: >> Hi Rick, >> >> I'm re-reading the SAFENeT I-D and have a basic question. It is about >> Section 2.4 "The MIDCOM and NSIS Solutions". You say this section is >> describes existing solutions on middlebox traversal and configuration. >> After reading it again, I still miss a reference to any already >> available/existing that refers to a MIDCOM-type solution. How about >> the FCP of Jiri Kuthan, MIDCOM MIB, or SIMCO? >> >> The solution described in Section 4.4 "Details of SAFENeT UA Communication >> Protocol (SUCP)" will fit to SIPPING working group and not MIDCOM. If not >> specified there, or in the SIP working group, already. >> >> I would like to see a clarification on this before we can meet >> face to face. > > A meeting would be a great opportunity for clarifying this and other > issues. > > Rick, when would you be available? > > Thanks, > > Juergen > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Tue Aug 02 14:35:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E01bm-0004VS-EL; Tue, 02 Aug 2005 14:35:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E01bk-0004VN-A9 for midcom@megatron.ietf.org; Tue, 02 Aug 2005 14:35:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10053 for ; Tue, 2 Aug 2005 14:35:17 -0400 (EDT) Received: from mail.siemenscom.com ([12.146.131.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E028F-0005Jj-IE for midcom@ietf.org; Tue, 02 Aug 2005 15:08:56 -0400 Received: from imail1.icn.siemens.com (localhost [127.0.0.1]) by mail.siemenscom.com (8.12.10/8.12.10) with ESMTP id j72IRlNl002166 for ; Tue, 2 Aug 2005 11:27:47 -0700 Received: from [165.218.35.88] (mars.inside.efficient.com [165.218.35.88]) by imail1.icn.siemens.com (8.12.10/8.12.10) with ESMTP id j72IX1ec014200 for ; Tue, 2 Aug 2005 11:33:01 -0700 (PDT) Message-ID: <42EFBCE2.2090004@siemens.com> Date: Tue, 02 Aug 2005 13:35:14 -0500 From: Stephen Lyda User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [midcom] SIMCO with IPSec X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Greetings, I was wondering if someone could elaborate on the need for the use of IPSec with the SIMCO protocol. If this protocol is designed to be light-weight and usable with lower end middleboxes, then I do not understand why IPSec encapsulation would be a firm requirement for all messages. For the most part, it seems to me that SIMCO messages are going to be traveling on a local, firewalled, network...and not vulerable to many malicious attacks from the outside world. It seems SIMCOs session establishment messages would be adequate enough to authenticate the SIMCO agent with the middlebox. The middlebox would also have the option to reject or select configurations set up by the agent. -Stephen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Thu Aug 04 05:05:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bfO-0008EX-6H; Thu, 04 Aug 2005 05:05:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bfM-0008EO-3h for midcom@megatron.ietf.org; Thu, 04 Aug 2005 05:05:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14128 for ; Thu, 4 Aug 2005 05:05:26 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cCA-0006ls-5T for midcom@ietf.org; Thu, 04 Aug 2005 05:39:25 -0400 Received: from open-31-127.ietf63.ietf.org (open-25-68.ietf63.ietf.org [86.255.25.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id D96F91BAC4D; Thu, 4 Aug 2005 11:05:12 +0200 (CEST) Date: Thu, 04 Aug 2005 11:05:11 +0200 From: Martin Stiemerling To: Stephen Lyda , midcom@ietf.org Subject: Re: [midcom] SIMCO with IPSec Message-ID: <65660FCF57A8CFD4EFDC2DE3@wired-5-56.ietf63.ietf.org> In-Reply-To: <42EFBCE2.2090004@siemens.com> References: <42EFBCE2.2090004@siemens.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Hi Stephen, --On Dienstag, 2. August 2005 13:35 Uhr -0500 Stephen Lyda wrote: | Greetings, | | I was wondering if someone could elaborate on the need for the use of | IPSec with the SIMCO protocol. | | If this protocol is designed to be light-weight and usable with lower | end middleboxes, then I do not understand why IPSec encapsulation would | be a firm requirement for all messages. | | For the most part, it seems to me that SIMCO messages are going to be | traveling on a local, firewalled, network...and not vulerable to many | malicious attacks from the outside world. | | It seems SIMCOs session establishment messages would be adequate enough | to authenticate the SIMCO agent with the middlebox. The middlebox would | also have the option to reject or select configurations set up by the | agent. SIMCO works fine in all scenarios and basically there two cases to distinguish: 1) running SIMCO in an "unsafe" environment, e.g., over the Internet or in local Ethernet-based network with shared links 2) running SIMCO in a closed/controlled environment. You are referring to case 2). In this case there is indeed no need to run SIMCO over IPsec. IPsec is recommended to be used in case 1. However, it is up to you to decided whether you run SIMCO over IPsec or not. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Thu Aug 04 11:23:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hYv-0002pt-Ay; Thu, 04 Aug 2005 11:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hYt-0002pg-Ve for midcom@megatron.ietf.org; Thu, 04 Aug 2005 11:23:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18664 for ; Thu, 4 Aug 2005 11:23:09 -0400 (EDT) Received: from mail.siemenscom.com ([12.146.131.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0i5m-0006ue-H2 for midcom@ietf.org; Thu, 04 Aug 2005 11:57:12 -0400 Received: from imail1.icn.siemens.com (localhost [127.0.0.1]) by mail.siemenscom.com (8.12.10/8.12.10) with ESMTP id j74FFPNl022798; Thu, 4 Aug 2005 08:15:25 -0700 Received: from [165.218.35.88] (mars.inside.efficient.com [165.218.35.88]) by imail1.icn.siemens.com (8.12.10/8.12.10) with ESMTP id j74FKotN019642; Thu, 4 Aug 2005 08:20:51 -0700 (PDT) Message-ID: <42F232D9.90403@siemens.com> Date: Thu, 04 Aug 2005 10:23:05 -0500 From: Stephen Lyda User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [midcom] SIMCO with IPSec References: <42EFBCE2.2090004@siemens.com> <65660FCF57A8CFD4EFDC2DE3@wired-5-56.ietf63.ietf.org> In-Reply-To: <65660FCF57A8CFD4EFDC2DE3@wired-5-56.ietf63.ietf.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: midcom@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Martin, It really was not clear to me reading the latest draft that IPSec was an option. Thank you for the clarification. -Stephen Martin Stiemerling wrote: > Hi Stephen, > > --On Dienstag, 2. August 2005 13:35 Uhr -0500 Stephen Lyda > wrote: > > | Greetings, > | > | I was wondering if someone could elaborate on the need for the use of > | IPSec with the SIMCO protocol. > | > | If this protocol is designed to be light-weight and usable with lower > | end middleboxes, then I do not understand why IPSec encapsulation would > | be a firm requirement for all messages. > | > | For the most part, it seems to me that SIMCO messages are going to be > | traveling on a local, firewalled, network...and not vulerable to many > | malicious attacks from the outside world. > | > | It seems SIMCOs session establishment messages would be adequate enough > | to authenticate the SIMCO agent with the middlebox. The middlebox would > | also have the option to reject or select configurations set up by the > | agent. > > SIMCO works fine in all scenarios and basically there two cases to > distinguish: > > 1) running SIMCO in an "unsafe" environment, e.g., over the > Internet or in local Ethernet-based network with shared links > 2) running SIMCO in a closed/controlled environment. > > You are referring to case 2). In this case there is indeed no need > to run SIMCO over IPsec. IPsec is recommended to be used in case 1. > However, it is up to you to decided whether you run SIMCO over IPsec > or not. > > Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom