From exim@www1.ietf.org Fri Apr 2 17:12:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07376 for ; Fri, 2 Apr 2004 17:12:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wt2-00076s-Af for midcom-archive@odin.ietf.org; Fri, 02 Apr 2004 17:11:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MBeET027307 for midcom-archive@odin.ietf.org; Fri, 2 Apr 2004 17:11:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W59-0006jE-6m; Fri, 02 Apr 2004 16:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SzX-0003Eh-Gl for midcom@optimus.ietf.org; Fri, 02 Apr 2004 13:02:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21178 for ; Fri, 2 Apr 2004 13:02:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9SzV-0005vY-00 for midcom@ietf.org; Fri, 02 Apr 2004 13:02:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9SyZ-0005od-00 for midcom@ietf.org; Fri, 02 Apr 2004 13:01:07 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Sy6-0005h9-00 for midcom@ietf.org; Fri, 02 Apr 2004 13:00:38 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2004 10:08:08 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i32I06n2013698 for ; Fri, 2 Apr 2004 10:00:06 -0800 (PST) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ASO70086; Fri, 2 Apr 2004 10:00:04 -0800 (PST) Date: Fri, 2 Apr 2004 13:00:00 -0500 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <8F7AD74C-84CF-11D8-85BE-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] DHCP option - trying again Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As I mentioned earlier this week, there's a new proposal to use DHCP to configure middlebox addresses into endpoints. Is this something the WG should take on? Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Apr 3 07:43:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18169 for ; Sat, 3 Apr 2004 07:43:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9kUL-00037f-HC for midcom-archive@odin.ietf.org; Sat, 03 Apr 2004 07:43:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33Ch5da011945 for midcom-archive@odin.ietf.org; Sat, 3 Apr 2004 07:43:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9kUH-0002zk-5p; Sat, 03 Apr 2004 07:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9kTz-0002aU-8O for midcom@optimus.ietf.org; Sat, 03 Apr 2004 07:42:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18153 for ; Sat, 3 Apr 2004 07:42:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9kTy-0006jG-00 for midcom@ietf.org; Sat, 03 Apr 2004 07:42:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9kT0-0006cD-00 for midcom@ietf.org; Sat, 03 Apr 2004 07:41:43 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B9kRz-0006Q3-00 for midcom@ietf.org; Sat, 03 Apr 2004 07:40:39 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i33Ce6ew028805 for ; Sat, 3 Apr 2004 04:40:06 -0800 (PST) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ASP42473; Sat, 3 Apr 2004 04:40:05 -0800 (PST) Date: Sat, 3 Apr 2004 07:40:00 -0500 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Fwd: [midcom] DHCP option - trying again From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <05D336F0-856C-11D8-85BE-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Begin forwarded message: > From: "Vikram Nair" > Date: Sat Apr 3, 2004 2:09:56 AM US/Eastern > To: "Melinda Shore" , > Subject: Re: [midcom] DHCP option - trying again > Reply-To: "Vikram Nair" > > Hi, > > Myself always in favour of autoconfiguration as much > as possible. > > No reservation as such to go with extending DHCP. Definitely > a plus for midcom. > > But just wondering, IPv6 itself advocates autoconfiguration > of the clients (including next-hops). Why not explore the > extension on the same lines. > > regards, > - Vikram > > ----- Original Message ----- > From: "Melinda Shore" > To: > Sent: Friday, April 02, 2004 11:30 PM > Subject: [midcom] DHCP option - trying again > > >> As I mentioned earlier this week, there's a new proposal to use DHCP >> to >> configure middlebox addresses into endpoints. Is this something the >> WG >> should take on? >> >> Melinda >> >> >> _______________________________________________ >> 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 exim@www1.ietf.org Mon Apr 5 10:14:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02428 for ; Mon, 5 Apr 2004 10:14:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUrT-0002V8-T7 for midcom-archive@odin.ietf.org; Mon, 05 Apr 2004 10:14:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35EE3J2009615 for midcom-archive@odin.ietf.org; Mon, 5 Apr 2004 10:14:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUrQ-0002Tn-NA; Mon, 05 Apr 2004 10:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUr4-0002Q1-9m for midcom@optimus.ietf.org; Mon, 05 Apr 2004 10:13:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02363 for ; Mon, 5 Apr 2004 10:13:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUr1-0002nW-00 for midcom@ietf.org; Mon, 05 Apr 2004 10:13:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUq2-0002go-00 for midcom@ietf.org; Mon, 05 Apr 2004 10:12:34 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BAUpG-0002TL-00 for midcom@ietf.org; Mon, 05 Apr 2004 10:11:46 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i35EBG9h050857 for ; Mon, 5 Apr 2004 16:11:16 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i35E7QbN050240 for ; Mon, 5 Apr 2004 16:07:26 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i35E7P9h050233; Mon, 05 Apr 2004 16:07:26 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 7090311A5EB; Mon, 5 Apr 2004 16:07:23 +0200 (CEST) Date: Mon, 05 Apr 2004 16:07:21 +0200 From: Martin Stiemerling To: Melinda Shore , midcom@ietf.org Cc: Joel Tran Subject: Re: [midcom] DHCP option - trying again Message-ID: <2147483647.1081181241@[10.1.1.109]> In-Reply-To: <8F7AD74C-84CF-11D8-85BE-000A95E35274@cisco.com> References: <8F7AD74C-84CF-11D8-85BE-000A95E35274@cisco.com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I quickly read the documents and I see that they DHCP options might be useful. The limiting factor is the, by MIDCOM required, mutual authentication of agent and middlebox. That's not provided at all. Anyway, learning your middlebox's address might is useful. One remark: The text needs probably some shaping for better readability: " Midcom middlebox DHCPv6 IPv6 address list option (as illustrated in figure 2) specifies a list of Midcom middlebox IPv6 addresses that are present in the network." The "list of MIDCOM middlebox IPv6 addresses that are present in the network" is what: - Available IPv6 addresses you probably get assigned by a NAT on its external interface - or (more likely) the list of middleboxes that offer MIDCOM service at these IPv6 addresses? Regards, Martin --On Freitag, 2. April 2004 13:00 Uhr -0500 Melinda Shore wrote: | As I mentioned earlier this week, there's a new proposal to use DHCP to | configure middlebox addresses into endpoints. Is this something the WG | should take on? | | Melinda | | | _______________________________________________ | 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 exim@www1.ietf.org Mon Apr 5 10:22:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03155 for ; Mon, 5 Apr 2004 10:22:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUzC-0005pZ-Bu for midcom-archive@odin.ietf.org; Mon, 05 Apr 2004 10:22:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35EM2wj022409 for midcom-archive@odin.ietf.org; Mon, 5 Apr 2004 10:22:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUzB-0005oh-8V; Mon, 05 Apr 2004 10:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUye-0005cQ-DY for midcom@optimus.ietf.org; Mon, 05 Apr 2004 10:21:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03074 for ; Mon, 5 Apr 2004 10:21:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUyc-0003mT-00 for midcom@ietf.org; Mon, 05 Apr 2004 10:21:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUxh-0003fa-00 for midcom@ietf.org; Mon, 05 Apr 2004 10:20:29 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BAUwo-0003Sr-00 for midcom@ietf.org; Mon, 05 Apr 2004 10:19:34 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i35EIx9p052078 for ; Mon, 5 Apr 2004 16:19:03 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i35EBPFv050885 for ; Mon, 5 Apr 2004 16:11:25 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i35EBO9h050883; Mon, 05 Apr 2004 16:11:25 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0FACC11FC0B; Mon, 5 Apr 2004 16:11:23 +0200 (CEST) Date: Mon, 05 Apr 2004 16:11:20 +0200 From: Martin Stiemerling To: midcom@ietf.org Cc: Vikram Nair Subject: Re: Fwd: [midcom] DHCP option - trying again Message-ID: <2147483647.1081181480@[10.1.1.109]> In-Reply-To: <05D336F0-856C-11D8-85BE-000A95E35274@cisco.com> References: <05D336F0-856C-11D8-85BE-000A95E35274@cisco.com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, | |> From: "Vikram Nair" |> Date: Sat Apr 3, 2004 2:09:56 AM US/Eastern |> To: "Melinda Shore" , |> Subject: Re: [midcom] DHCP option - trying again |> Reply-To: "Vikram Nair" |> |> Hi, |> |> Myself always in favour of autoconfiguration as much |> as possible. I'm too. |> |> No reservation as such to go with extending DHCP. Definitely |> a plus for midcom. |> |> But just wondering, IPv6 itself advocates autoconfiguration |> of the clients (including next-hops). Why not explore the |> extension on the same lines. Yes, IPv6 does offer stateless autoconfiguration. Anyway, transporting IP addresses of MIDCOM-type middleboxes is more a 'service' configuration and probably not at the level of IPv6 address autoconfiguration. The MIDCOM service would be more like SIP proxy, meaning that this should go to DHCP instead of IPv6 autoconfiguration. Regards, Martin Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@netlab.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de |> |> regards, |> - Vikram |> |> ----- Original Message ----- |> From: "Melinda Shore" |> To: |> Sent: Friday, April 02, 2004 11:30 PM |> Subject: [midcom] DHCP option - trying again |> |> |>> As I mentioned earlier this week, there's a new proposal to use DHCP |>> to |>> configure middlebox addresses into endpoints. Is this something the |>> WG |>> should take on? |>> |>> Melinda |>> |>> |>> _______________________________________________ |>> 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Apr 5 11:30:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07254 for ; Mon, 5 Apr 2004 11:30:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAW2t-0006wN-94 for midcom-archive@odin.ietf.org; Mon, 05 Apr 2004 11:29:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35FTtpI026654 for midcom-archive@odin.ietf.org; Mon, 5 Apr 2004 11:29:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAW2d-0006Uc-R7; Mon, 05 Apr 2004 11:29:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAVYU-000774-DA for midcom@optimus.ietf.org; Mon, 05 Apr 2004 10:58:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05701 for ; Mon, 5 Apr 2004 10:58:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAVYQ-0001NY-00 for midcom@ietf.org; Mon, 05 Apr 2004 10:58:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAVXX-0001Em-00 for midcom@ietf.org; Mon, 05 Apr 2004 10:57:32 -0400 Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BAVWe-000157-00 for midcom@ietf.org; Mon, 05 Apr 2004 10:56:36 -0400 Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2.enterasys.com [134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i35EuXiR010098 for ; Mon, 5 Apr 2004 10:56:33 -0400 (EDT) Received: from NHROCCNC1.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 05 Apr 2004 10:56:36 -0400 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Mon, 05 Apr 2004 10:56:36 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 10:56:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : [midcom] DHCP options drafts Date: Mon, 5 Apr 2004 10:56:34 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA017E131F@NHROCMBX1.ets.enterasys.com> Thread-Topic: RE : [midcom] DHCP options drafts Thread-Index: AcQXMa/IpzjmWGb4TgefRo/Ik01ERgD6DEBw From: "Harrington, David" To: X-OriginalArrivalTime: 05 Apr 2004 14:56:36.0093 (UTC) FILETIME=[31289AD0:01C41B1E] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:78.1961 M:99.8514 P:95.9108 R:95.9108 S:45.3495 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, Since the communications between a midcom agent and the middlebox is = done via SNMPv3, to provide mutual authentication, the discovery needs = to be done using SNMPv3. DHCP is good for dynamically assigning addresses, but SNMPv3 has = specific requirements about the identification of managed nodes, and = addresses have proven inadequate for identification purposes, largely as = the result of technologies such as DHCP and NAT. It is also possible to = have multiple SNMPv3 agents at the same address (e.g. to manage = different types of functionality present on the same box), and to have = one SNMP agent respond at multiple addresses (e.g. in a router or in a = multi-blade chassis).=20 That's why SNMPv3 uses engineIDs for identification. SNMPv3 discovery = entails a type of mutual discovery, during which the SNMP engines share = their SNMPv3 engineIDs, and clock sync information. This permits SNMPv3 = to communicate with different engines at a given address, or to = recognize when one engine has multiple addresses. This discovered = information cannot be provided via DHCP. There is also the issue of key distribution. The initial distribution of = keys must be done outside SNMPv3, using a secure protocol. This may = accomplished using a key distribution protocol, such as kerberos, or by = kickstarting a "root" or "admin" type of security relationship, and then = distributing additional keys using SNMPv3. DHCP is inappropriate for key = distribution. DHCP might be useful for saying "there is an SNMP engine (which may be a = midcom agent or a middlebox or some other type of SNMP engine) at = address a.b.c.d, but the information DHCP provides alone will be = inadequate for establishing secure SNMPv3 communications or for = establishing non-secure SNMPv3 communications. It might be adequate for = identifying where there is an SNMP engine that could then be = "discovered" using SNMPv3 discovery. If DHCP provided the engineIDs for = the SNMP engines, as well as the addresses to use to reach each SNMP = engine, that could be a good thing. dbh > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On=20 > Behalf Of Joel Tran > Sent: Wednesday, March 31, 2004 10:01 AM > To: 'Melinda Shore'; midcom@ietf.org > Subject: RE : [midcom] DHCP options drafts >=20 > There has been an error during the submission of the two=20 > drafts. While this > get fix, the documents will be available at:=20 >=20 > http://www-edu.gel.usherb.ca/traj1901/draft-tran-midcom-dhcp-o > ption-00.txt > http://www-edu.gel.usherb.ca/traj1901/draft-tran-midcom-dhcpv6 > -option-00.txt >=20 > These documents present a technique for discovering the=20 > midcom agent in an > IPv4 and IPv6 network using DHCP. This technique will be=20 > useful for end-user > device which will implement midcom. >=20 > Any comments are appreciated. > Thanks, > ...J=20 >=20 > -----Message d'origine----- > De=A0: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] De=20 > la part de > Melinda Shore > Envoy=E9=A0: 31 mars, 2004 07:22 > =C0=A0: midcom@ietf.org > Objet=A0: [midcom] DHCP options drafts >=20 > By now you may have seen the announcements for two > new drafts on using DHCP to configure middlebox addresses > into clients. This work would probably most appropriately be > done in the dhc working group, but first we need to make sure > that midcom participants think that the idea is sound and > second we'd need to review the document and make sure that > the options, etc. are correct. So, first question first: > is this worth doing? >=20 > Thanks, >=20 > Melinda >=20 > http://www.ietf.org/internet-drafts/draft-tran-midcom-dhcp-opt > ion-00.txt > http://www.ietf.org/internet-drafts/draft-tran-midcom-dhcpv6-option-=20 > 00.txt >=20 >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 >=20 >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Apr 5 15:13:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28124 for ; Mon, 5 Apr 2004 15:13:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAZXB-0003aq-OR for midcom-archive@odin.ietf.org; Mon, 05 Apr 2004 15:13:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35JDPWj013766 for midcom-archive@odin.ietf.org; Mon, 5 Apr 2004 15:13:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAZWp-0003HU-D9; Mon, 05 Apr 2004 15:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAZWR-00039J-Fe for midcom@optimus.ietf.org; Mon, 05 Apr 2004 15:12:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27723 for ; Mon, 5 Apr 2004 15:12:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAZWQ-0006HC-00 for midcom@ietf.org; Mon, 05 Apr 2004 15:12:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAZLP-0004CB-00 for midcom@ietf.org; Mon, 05 Apr 2004 15:01:16 -0400 Received: from smtp2.usherbrooke.ca ([132.210.244.18]) by ietf-mx with esmtp (Exim 4.12) id 1BAYwB-0001RA-00 for midcom@ietf.org; Mon, 05 Apr 2004 14:35:12 -0400 Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178]) by smtp2.usherbrooke.ca (8.12.8/8.12.8) with ESMTP id i35IYqvj019289; Mon, 5 Apr 2004 14:34:52 -0400 From: "Joel Tran" To: "'Martin Stiemerling'" , Subject: RE : [midcom] DHCP option - trying again Date: Mon, 5 Apr 2004 14:33:51 -0400 Message-ID: <000901c41b3c$8ade7900$b248d284@kamel> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <2147483647.1081181241@[10.1.1.109]> X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: joel.tran@usherbrooke.ca X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Martin, Comments inline, > I quickly read the documents and I see that they DHCP options > might be > useful. The limiting factor is the, by MIDCOM required, mutual > authentication of agent and middlebox. That's not provided at all. This technique only provides a way to know the presence of Midcom middlebox in a network. The scope of this document does not include authentication which will be done with SNMPv3/Midcom. > One remark: The text needs probably some shaping for better > readability: " Midcom middlebox DHCPv6 IPv6 address list > option (as illustrated in figure 2) specifies a list of > Midcom middlebox IPv6 addresses that are present in the network." Fixed this in the next version. > > The "list of MIDCOM middlebox IPv6 addresses that are present in the > network" is what: > - Available IPv6 addresses you probably get assigned by a NAT on its > external interface > - or (more likely) the list of middleboxes that offer MIDCOM > service at > these IPv6 addresses? Fixed! Thanks for you input! ...J _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Apr 5 16:03:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03229 for ; Mon, 5 Apr 2004 16:03:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJE-0002yE-4N for midcom-archive@odin.ietf.org; Mon, 05 Apr 2004 16:03:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35K34vY011419 for midcom-archive@odin.ietf.org; Mon, 5 Apr 2004 16:03:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaJB-0002xd-01; Mon, 05 Apr 2004 16:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaIO-0002oQ-OI for midcom@optimus.ietf.org; Mon, 05 Apr 2004 16:02:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03118 for ; Mon, 5 Apr 2004 16:02:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaIN-0004Hp-00 for midcom@ietf.org; Mon, 05 Apr 2004 16:02:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAa6f-00028F-00 for midcom@ietf.org; Mon, 05 Apr 2004 15:50:06 -0400 Received: from smtp2.usherbrooke.ca ([132.210.244.18]) by ietf-mx with esmtp (Exim 4.12) id 1BAZdp-0007IU-00 for midcom@ietf.org; Mon, 05 Apr 2004 15:20:17 -0400 Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178]) by smtp2.usherbrooke.ca (8.12.8/8.12.8) with ESMTP id i35JJtvj010471; Mon, 5 Apr 2004 15:19:55 -0400 From: "Joel Tran" To: "'Harrington, David'" , Subject: RE : RE : [midcom] DHCP options drafts Date: Mon, 5 Apr 2004 15:18:54 -0400 Message-ID: <000a01c41b42$d5ea4c70$b248d284@kamel> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA017E131F@NHROCMBX1.ets.enterasys.com> X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: joel.tran@usherbrooke.ca X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Comments inline. > Since the communications between a midcom agent and the > middlebox is done via SNMPv3, to provide mutual > authentication, the discovery needs to be done using SNMPv3. True, preferably, the discovery should by done using SNMPv3. However, I can't figure out one thing: How we can ONLY identify SNMPv3 agent performing Midcom services in an effective way? With the use of DHCP, we can pin-point directly the Midcom device in a network. > DHCP is good for dynamically assigning addresses, but SNMPv3 > has specific requirements about the identification of managed > nodes, and addresses have proven inadequate for > identification purposes, largely as the result of > technologies such as DHCP and NAT. DHCP serves as assigning dynamically addresses and configuration parameter. In our case, Midcom agent needs to know the addresses of Midcom middlebox. DHCP provides this means. For identification/authentication is out of scope of DHCP. The Midcom agent will thus have to provide authentication to the Midcom middlebox. > It is also possible to > have multiple SNMPv3 agents at the same address (e.g. to > manage different types of functionality present on the same > box), Quick question, in this case, are all the SNMP agents listening to the port or they have individual port? > That's why SNMPv3 uses engineIDs for identification. SNMPv3 > discovery entails a type of mutual discovery, during which > the SNMP engines share their SNMPv3 engineIDs, and clock sync > information. This permits SNMPv3 to communicate with > different engines at a given address, or to recognize when > one engine has multiple addresses. This discovered > information cannot be provided via DHCP. > There is also the issue of key distribution. The initial > distribution of keys must be done outside SNMPv3, using a > secure protocol. This may accomplished using a key > distribution protocol, such as kerberos, or by kickstarting a > "root" or "admin" type of security relationship, and then > distributing additional keys using SNMPv3. DHCP is > inappropriate for key distribution. > DHCP might be useful for saying "there is an SNMP engine > (which may be a midcom agent or a middlebox or some other > type of SNMP engine) at address a.b.c.d, but the information > DHCP provides alone will be inadequate for establishing > secure SNMPv3 communications or for establishing non-secure > SNMPv3 communications. It might be adequate for identifying > where there is an SNMP engine that could then be "discovered" > using SNMPv3 discovery. If DHCP provided the engineIDs for > the SNMP engines, as well as the addresses to use to reach > each SNMP engine, that could be a good thing. As you mentioned, it will probably be interesting to provide engineIDs to identify the good SNMPv3 agent in the document. Anybody have some other comments on this? ...J _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Apr 5 17:01:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09088 for ; Mon, 5 Apr 2004 17:01:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbDO-0002xP-Hg for midcom-archive@odin.ietf.org; Mon, 05 Apr 2004 17:01:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35L16GH011356 for midcom-archive@odin.ietf.org; Mon, 5 Apr 2004 17:01:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbDK-0002vD-DB; Mon, 05 Apr 2004 17:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbCN-0002OF-Du for midcom@optimus.ietf.org; Mon, 05 Apr 2004 17:00:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08796 for ; Mon, 5 Apr 2004 16:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAbCL-0003QI-00 for midcom@ietf.org; Mon, 05 Apr 2004 17:00:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAay3-0000iT-00 for midcom@ietf.org; Mon, 05 Apr 2004 16:45:17 -0400 Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BAaQD-0005c7-00 for midcom@ietf.org; Mon, 05 Apr 2004 16:10:17 -0400 Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2.enterasys.com [134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i35KADiR009217 for ; Mon, 5 Apr 2004 16:10:13 -0400 (EDT) Received: from NHROCCNC1.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 05 Apr 2004 16:10:16 -0400 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Mon, 05 Apr 2004 16:10:16 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 16:10:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : RE : [midcom] DHCP options drafts Date: Mon, 5 Apr 2004 16:10:15 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA017E137B@NHROCMBX1.ets.enterasys.com> Thread-Topic: RE : RE : [midcom] DHCP options drafts Thread-Index: AcQbQwhxI0NSTzUqTJWSCtTgc4w/EQAAWLSQ From: "Harrington, David" To: "Joel Tran" , X-OriginalArrivalTime: 05 Apr 2004 20:10:15.0991 (UTC) FILETIME=[02B12470:01C41B4A] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:82.4442 M:97.7712 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Joel, Comments inline.=20 > -----Original Message----- > From: Joel Tran [mailto:joel.tran@USherbrooke.ca]=20 > Sent: Monday, April 05, 2004 3:19 PM > To: Harrington, David; midcom@ietf.org > Subject: RE : RE : [midcom] DHCP options drafts >=20 > Comments inline. >=20 > > Since the communications between a midcom agent and the > > middlebox is done via SNMPv3, to provide mutual > > authentication, the discovery needs to be done using SNMPv3. >=20 > True, preferably, the discovery should by done using SNMPv3.=20 > However, I > can't figure out one thing: How we can ONLY identify SNMPv3=20 > agent performing > Midcom services in an effective way? With the use of DHCP, we=20 > can pin-point > directly the Midcom device in a network. Using SNMPv3's initial discovery mechanism, one engine can discover the other engine's engineID and time sync parameters. If the application (SNMP manager) knows the pre-shared keys of the SNMP agent on the middlebox, the application can look to see if the MIDCIM MIB module is supported by doing a GET of one or more of the OIDs used in the MIDCOM MIB module. That type of discovery is standard operating procedure for most SNMP applications. That type of discovery would be appropriate for discovering MIDCOM agents and middleboxes. If an application searching for middleboxes doesn't have the shared keys for the middlebox, then it probably shouldn't be given access to determine what specific types of functionality the other SNMP engine supports. This argues for having the application (MIDCOM agent) record the address of the middlebox whose SNMPv3 keys are being set into its database. >=20 > > DHCP is good for dynamically assigning addresses, but SNMPv3 > > has specific requirements about the identification of managed > > nodes, and addresses have proven inadequate for > > identification purposes, largely as the result of > > technologies such as DHCP and NAT. >=20 > DHCP serves as assigning dynamically addresses and=20 > configuration parameter. > In our case, Midcom agent needs to know the addresses of=20 > Midcom middlebox. > DHCP provides this means. For identification/authentication=20 > is out of scope > of DHCP. The Midcom agent will thus have to provide=20 > authentication to the > Midcom middlebox. I think there is a question of the order of events. If both sides need to know the shared keys, wouldn't an operator be likely to be able to tell the midcom agent what the address of the middlebox is at the same time?=20 What is the usage scenario that requires DHCP to tell the midcom agent the address of the middlebox, if the shared keys have already been set into both devices?=20 Understand that I am not objecting to the use of DHCP. I am trying to understand the scenario in which it is actually necessary, given that SNMPv3 currently requires key distribution for mutual authentication before secure communications can be established. SNMPv3 was explicitly designed to protect its information from disclosure to unauthenticated entities. During SNMpv3 design discussions, there was a significant segemnt of the market (part of the US govt) that argued an SNMPv3 engine shouldn't reply to an unauthenticed entity because that would reveal that an SNMP engine exists at a given address. On top of the strong authentication, seeing into the MIB to see what functionality is supported is tightly controlled by design, using the VACM access control model.=20 Given that MIDCOM is designed to manipulate security-related features such as firewalls and NATs, it is fairly imperative that a strong SNMPv3 security model is maintained. A hacker would need to work to get through the SNMPv3 authentication mechanisms to talk to the box, and then past the data access controls (authorizations) to determine that a box supports the MIDCOM MIB module. I am not convinced that using DHCP to advertise "the entity at this address is a middlebox, with SNMP support of the MIDCOM MIB module" is a very secure thing to do, and that it doesn't defeat some of the SNMPv3 security philosophy to a degree.=20 It helps the hacker to discover which services are running on which boxes, which is why port scans are considered a general security threat. What mechanisms are in place to ensure that DHCP doesn't disclose information about entities that shouldn't be disclosed? What happens if the DHCP server is compromised? OTOH, SNMpv3 was also designed explicitly to not use obscurity as a security mechanism. Even if you tell a hacker that a device is a middlebox manageable using the MIDCOM MIB module, the SNMPv3 security should prevent them gaining unauthorized access.=20 =20 >=20 > > It is also possible to > > have multiple SNMPv3 agents at the same address (e.g. to > > manage different types of functionality present on the same > > box), >=20 > Quick question, in this case, are all the SNMP agents=20 > listening to the port > or they have individual port? Multiple agents MAY work together, with one agent listening on a given port, and then the "dispatcher" of the SNMP listener can forward the requests directly to the appropriate registered engine, possibly (but not necessarily) through a different port. There are multiple SNMP-legal ways to support multiple engines at the same address, including the SNMP proxy mechanisms defined in RFC3413(?). >=20 > > That's why SNMPv3 uses engineIDs for identification. SNMPv3 > > discovery entails a type of mutual discovery, during which > > the SNMP engines share their SNMPv3 engineIDs, and clock sync > > information. This permits SNMPv3 to communicate with > > different engines at a given address, or to recognize when > > one engine has multiple addresses. This discovered > > information cannot be provided via DHCP. >=20 > > There is also the issue of key distribution. The initial > > distribution of keys must be done outside SNMPv3, using a > > secure protocol. This may accomplished using a key > > distribution protocol, such as kerberos, or by kickstarting a > > "root" or "admin" type of security relationship, and then > > distributing additional keys using SNMPv3. DHCP is > > inappropriate for key distribution. >=20 > > DHCP might be useful for saying "there is an SNMP engine > > (which may be a midcom agent or a middlebox or some other > > type of SNMP engine) at address a.b.c.d, but the information > > DHCP provides alone will be inadequate for establishing > > secure SNMPv3 communications or for establishing non-secure > > SNMPv3 communications. It might be adequate for identifying > > where there is an SNMP engine that could then be "discovered" > > using SNMPv3 discovery. If DHCP provided the engineIDs for > > the SNMP engines, as well as the addresses to use to reach > > each SNMP engine, that could be a good thing. >=20 > As you mentioned, it will probably be interesting to provide=20 > engineIDs to > identify the good SNMPv3 agent in the document. Anybody have=20 > some other > comments on this? >=20 >=20 > ...J >=20 David Harrington =20 dbh@enterasys.com co-chair, IETF SNMPv3 WG, concluded =20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Apr 6 02:23:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10216 for ; Tue, 6 Apr 2004 02:23:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAjzM-0000zM-I9 for midcom-archive@odin.ietf.org; Tue, 06 Apr 2004 02:23:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i366NCkb003795 for midcom-archive@odin.ietf.org; Tue, 6 Apr 2004 02:23:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAjzJ-0000wm-GM; Tue, 06 Apr 2004 02:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAjyl-0000au-8Z for midcom@optimus.ietf.org; Tue, 06 Apr 2004 02:22:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10074 for ; Tue, 6 Apr 2004 02:22:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAjyh-0005y7-00 for midcom@ietf.org; Tue, 06 Apr 2004 02:22:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAjlK-0003SE-00 for midcom@ietf.org; Tue, 06 Apr 2004 02:08:43 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BAjCj-0000OB-00 for midcom@ietf.org; Tue, 06 Apr 2004 01:32:57 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i365WM9h077533 for ; Tue, 6 Apr 2004 07:32:22 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i365SeEB077506 for ; Tue, 6 Apr 2004 07:28:40 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i365Sd9h077505; Tue, 06 Apr 2004 07:28:40 +0200 (CEST) Received: from [10.1.1.27] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0528011EFB0; Tue, 6 Apr 2004 07:28:38 +0200 (CEST) Date: Mon, 05 Apr 2004 19:27:22 +0200 From: Juergen Quittek To: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] DHCP option - trying again Message-ID: <2147483647.1081193242@localhost> In-Reply-To: <8F7AD74C-84CF-11D8-85BE-000A95E35274@cisco.com> References: <8F7AD74C-84CF-11D8-85BE-000A95E35274@cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda, I think Joel made a very useful suggestion for solving (or reducing) the middlebox topology problem that Cedric pointed out several times. Joel's approach fits well into the existing IP infrastructure and should be followed by the IETF. My initial thought was that this work rather belongs to the DHC WG (I have not seen an announcement there), but probably the MIDCOM WG is a much better home for it. Consequently, I support a MIDCOM work item on DHC options for distributing middlebox topology information. The two drafts are a very good starting point for such an activity although I think that so far they solve only a part of the problem. After a discussion with my colleague Cristian who implemented SIMCO as well as the full DHCPv6 standard, he came up with a set of suggestions for improvement, which we can discuss on this list if we accept this new work item. Thanks, Juergen -- Juergen Quittek quittek@ccrle.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.ccrle.nec.de --On 02.04.2004 13:00 Uhr -0500 Melinda Shore wrote: > As I mentioned earlier this week, there's a new proposal to use DHCP to > configure middlebox addresses into endpoints. Is this something the WG > should take on? > > Melinda > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Apr 6 02:23:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10217 for ; Tue, 6 Apr 2004 02:23:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAjzM-0000zN-IC for midcom-archive@odin.ietf.org; Tue, 06 Apr 2004 02:23:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i366NCv1003796 for midcom-archive@odin.ietf.org; Tue, 6 Apr 2004 02:23:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAjzK-0000x4-2A; Tue, 06 Apr 2004 02:23:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAjyl-0000b7-Rv for midcom@optimus.ietf.org; Tue, 06 Apr 2004 02:22:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10079 for ; Tue, 6 Apr 2004 02:22:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAjyi-0005yD-00 for midcom@ietf.org; Tue, 06 Apr 2004 02:22:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAjlL-0003SM-00 for midcom@ietf.org; Tue, 06 Apr 2004 02:08:44 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BAjCj-0000OT-00 for midcom@ietf.org; Tue, 06 Apr 2004 01:32:57 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i365WM9n077533 for ; Tue, 6 Apr 2004 07:32:25 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i365Slht077510 for ; Tue, 6 Apr 2004 07:28:47 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i365Sk9h077508; Tue, 06 Apr 2004 07:28:47 +0200 (CEST) Received: from [10.1.1.27] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 892F511EFB0; Tue, 6 Apr 2004 07:28:44 +0200 (CEST) Date: Mon, 05 Apr 2004 19:39:47 +0200 From: Juergen Quittek To: Melinda Shore , midcom@ietf.org, vnair@hss.hns.com Subject: Re: Fwd: [midcom] DHCP option - trying again Message-ID: <2147483647.1081193987@localhost> In-Reply-To: <05D336F0-856C-11D8-85BE-000A95E35274@cisco.com> References: <05D336F0-856C-11D8-85BE-000A95E35274@cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_06_12 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vikram, --On 03.04.2004 7:40 Uhr -0500 Melinda Shore wrote: > Begin forwarded message: > >> From: "Vikram Nair" >> Date: Sat Apr 3, 2004 2:09:56 AM US/Eastern >> To: "Melinda Shore" , >> Subject: Re: [midcom] DHCP option - trying again >> Reply-To: "Vikram Nair" >> >> Hi, >> >> Myself always in favour of autoconfiguration as much >> as possible. >> >> No reservation as such to go with extending DHCP. Definitely >> a plus for midcom. >> >> But just wondering, IPv6 itself advocates autoconfiguration >> of the clients (including next-hops). Why not explore the >> extension on the same lines. Thank you for this hint. Yes, you are right: IPv6 offers stateless autoconfiguration. This is a feature that is very useful for open network, such as dial-in access or WLAN hot spots, but not for any controlled infrastructue. In a company network you would not like to allow any host to connect to the LAN without checking its MAC address or other authentication. That's when you need DHC for IPv6 address assignment. Juergen >> regards, >> - Vikram >> >> ----- Original Message ----- >> From: "Melinda Shore" >> To: >> Sent: Friday, April 02, 2004 11:30 PM >> Subject: [midcom] DHCP option - trying again >> >> >>> As I mentioned earlier this week, there's a new proposal to use DHCP >>> to >>> configure middlebox addresses into endpoints. Is this something the >>> WG >>> should take on? >>> >>> Melinda >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Apr 6 03:25:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15971 for ; Tue, 6 Apr 2004 03:25:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkxK-0001Be-I6 for midcom-archive@odin.ietf.org; Tue, 06 Apr 2004 03:25:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i367PAhj004563 for midcom-archive@odin.ietf.org; Tue, 6 Apr 2004 03:25:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkxH-0001AR-04; Tue, 06 Apr 2004 03:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkx6-00016u-Kh for midcom@optimus.ietf.org; Tue, 06 Apr 2004 03:24:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15739 for ; Tue, 6 Apr 2004 03:24:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAkx4-0005oL-00 for midcom@ietf.org; Tue, 06 Apr 2004 03:24:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAkjo-0003Nr-00 for midcom@ietf.org; Tue, 06 Apr 2004 03:11:14 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BAkEh-0000IL-00 for midcom@ietf.org; Tue, 06 Apr 2004 02:39:03 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i366cS9r078424 for ; Tue, 6 Apr 2004 08:38:33 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i366Zstp078390 for ; Tue, 6 Apr 2004 08:35:54 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i366Zr9h078388; Tue, 06 Apr 2004 08:35:53 +0200 (CEST) Received: from [10.1.1.27] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 606F1120347; Tue, 6 Apr 2004 08:35:50 +0200 (CEST) Date: Tue, 06 Apr 2004 08:37:16 +0200 From: Juergen Quittek To: "Harrington, David" , midcom@ietf.org Subject: RE: RE : [midcom] DHCP options drafts Message-ID: <2147483647.1081240635@[10.1.1.26]> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA017E131F@NHROCMBX1.ets.enterasys.com> References: <6D745637A7E0F94DA070743C55CDA9BA017E131F@NHROCMBX1.ets.enterasys.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable David, I completely agree with your analysis. The missing integration with the MIDCOM MIB is one of the shortcomings of the current drafts. Another one is lacking support for multihoming. Still I think that the general idea of supporting MIDCOM by DHCP options is useful. Both shortcomings can be fixed. Thanks, Juergen --On 05.04.2004 10:56 Uhr -0400 Harrington, David wrote: > Hi, > > Since the communications between a midcom agent and the middlebox is done via SNMPv3, to provide mutual authentication, the discovery needs to be done using SNMPv3. > > DHCP is good for dynamically assigning addresses, but SNMPv3 has specific requirements about the identification of managed nodes, and addresses have proven inadequate for identification purposes, largely as the result of technologies such as DHCP and > NAT. It is also possible to have multiple SNMPv3 agents at the same address (e.g. to manage different types of functionality present on the same box), and to have one SNMP agent respond at multiple addresses (e.g. in a router or in a multi-blade > chassis). > > That's why SNMPv3 uses engineIDs for identification. SNMPv3 discovery entails a type of mutual discovery, during which the SNMP engines share their SNMPv3 engineIDs, and clock sync information. This permits SNMPv3 to communicate with different engines > at a given address, or to recognize when one engine has multiple addresses. This discovered information cannot be provided via DHCP. > > There is also the issue of key distribution. The initial distribution of keys must be done outside SNMPv3, using a secure protocol. This may accomplished using a key distribution protocol, such as kerberos, or by kickstarting a "root" or "admin" type > of security relationship, and then distributing additional keys using SNMPv3. DHCP is inappropriate for key distribution. > > DHCP might be useful for saying "there is an SNMP engine (which may be a midcom agent or a middlebox or some other type of SNMP engine) at address a.b.c.d, but the information DHCP provides alone will be inadequate for establishing secure SNMPv3 > communications or for establishing non-secure SNMPv3 communications. It might be adequate for identifying where there is an SNMP engine that could then be "discovered" using SNMPv3 discovery. If DHCP provided the engineIDs for the SNMP engines, as well > as the addresses to use to reach each SNMP engine, that could be a good thing. > > dbh > >> -----Original Message----- >> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On >> Behalf Of Joel Tran >> Sent: Wednesday, March 31, 2004 10:01 AM >> To: 'Melinda Shore'; midcom@ietf.org >> Subject: RE : [midcom] DHCP options drafts >> >> There has been an error during the submission of the two >> drafts. While this >> get fix, the documents will be available at: >> >> http://www-edu.gel.usherb.ca/traj1901/draft-tran-midcom-dhcp-o >> ption-00.txt >> http://www-edu.gel.usherb.ca/traj1901/draft-tran-midcom-dhcpv6 >> -option-00.txt >> >> These documents present a technique for discovering the >> midcom agent in an >> IPv4 and IPv6 network using DHCP. This technique will be >> useful for end-user >> device which will implement midcom. >> >> Any comments are appreciated. >> Thanks, >> ...J >> >> -----Message d'origine----- >> De=A0: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] De >> la part de >> Melinda Shore >> Envoy=E9=A0: 31 mars, 2004 07:22 >> =C0=A0: midcom@ietf.org >> Objet=A0: [midcom] DHCP options drafts >> >> By now you may have seen the announcements for two >> new drafts on using DHCP to configure middlebox addresses >> into clients. This work would probably most appropriately be >> done in the dhc working group, but first we need to make sure >> that midcom participants think that the idea is sound and >> second we'd need to review the document and make sure that >> the options, etc. are correct. So, first question first: >> is this worth doing? >> >> Thanks, >> >> Melinda >> >> http://www.ietf.org/internet-drafts/draft-tran-midcom-dhcp-opt >> ion-00.txt >> http://www.ietf.org/internet-drafts/draft-tran-midcom-dhcpv6-option- >> 00.txt >> >> >> _______________________________________________ >> 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 >> >> > > _______________________________________________ > 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 exim@www1.ietf.org Tue Apr 6 05:24:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26116 for ; Tue, 6 Apr 2004 05:24:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmoO-0005MC-Mo for midcom-archive@odin.ietf.org; Tue, 06 Apr 2004 05:24:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i369O4Dv020582 for midcom-archive@odin.ietf.org; Tue, 6 Apr 2004 05:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmoN-0005Kl-V0; Tue, 06 Apr 2004 05:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmns-00052e-OF for midcom@optimus.ietf.org; Tue, 06 Apr 2004 05:23:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25880 for ; Tue, 6 Apr 2004 05:23:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAmnp-0004S6-00 for midcom@ietf.org; Tue, 06 Apr 2004 05:23:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAmfu-0002pH-00 for midcom@ietf.org; Tue, 06 Apr 2004 05:15:20 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BAmKL-0007dc-00 for midcom@ietf.org; Tue, 06 Apr 2004 04:53:01 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i368qQ9r089222 for ; Tue, 6 Apr 2004 10:52:30 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i368oeqC088993 for ; Tue, 6 Apr 2004 10:50:40 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i368oe9h088989; Tue, 06 Apr 2004 10:50:40 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5F857119D33; Tue, 6 Apr 2004 10:50:38 +0200 (CEST) Date: Tue, 06 Apr 2004 10:50:35 +0200 From: Martin Stiemerling To: "Harrington, David" , Joel Tran , midcom@ietf.org Subject: RE: RE : RE : [midcom] DHCP options drafts Message-ID: <2147483647.1081248635@[10.1.1.109]> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA017E137B@NHROCMBX1.ets.enterasys.com> References: <6D745637A7E0F94DA070743C55CDA9BA017E137B@NHROCMBX1.ets.enterasy s.com> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi David, I agree with all your analysis. A point for configuring the IP addresses of middleboxes dynamically might be (as Juergen pointed out) multihoming. An MIDCOM agent that has preconfigured security associations with the middleboxes could learn which of the boxes is the right one for a particular destination. This could be conveyed via a MIDCOM option in DHCP and some additional routing information options. Martin --On Montag, 5. April 2004 16:10 Uhr -0400 "Harrington, David" wrote: | Hi Joel, | | Comments inline. | |> -----Original Message----- |> From: Joel Tran [mailto:joel.tran@USherbrooke.ca] |> Sent: Monday, April 05, 2004 3:19 PM |> To: Harrington, David; midcom@ietf.org |> Subject: RE : RE : [midcom] DHCP options drafts |> |> Comments inline. |> |> > Since the communications between a midcom agent and the |> > middlebox is done via SNMPv3, to provide mutual |> > authentication, the discovery needs to be done using SNMPv3. |> |> True, preferably, the discovery should by done using SNMPv3. |> However, I |> can't figure out one thing: How we can ONLY identify SNMPv3 |> agent performing |> Midcom services in an effective way? With the use of DHCP, we |> can pin-point |> directly the Midcom device in a network. | | Using SNMPv3's initial discovery mechanism, one engine can discover the | other engine's engineID and time sync parameters. If the application | (SNMP manager) knows the pre-shared keys of the SNMP agent on the | middlebox, the application can look to see if the MIDCIM MIB module is | supported by doing a GET of one or more of the OIDs used in the MIDCOM | MIB module. That type of discovery is standard operating procedure for | most SNMP applications. | | That type of discovery would be appropriate for discovering MIDCOM | agents and middleboxes. If an application searching for middleboxes | doesn't have the shared keys for the middlebox, then it probably | shouldn't be given access to determine what specific types of | functionality the other SNMP engine supports. | | This argues for having the application (MIDCOM agent) record the address | of the middlebox whose SNMPv3 keys are being set into its database. | |> |> > DHCP is good for dynamically assigning addresses, but SNMPv3 |> > has specific requirements about the identification of managed |> > nodes, and addresses have proven inadequate for |> > identification purposes, largely as the result of |> > technologies such as DHCP and NAT. |> |> DHCP serves as assigning dynamically addresses and |> configuration parameter. |> In our case, Midcom agent needs to know the addresses of |> Midcom middlebox. |> DHCP provides this means. For identification/authentication |> is out of scope |> of DHCP. The Midcom agent will thus have to provide |> authentication to the |> Midcom middlebox. | | I think there is a question of the order of events. If both sides need | to know the shared keys, wouldn't an operator be likely to be able to | tell the midcom agent what the address of the middlebox is at the same | time? | | What is the usage scenario that requires DHCP to tell the midcom agent | the address of the middlebox, if the shared keys have already been set | into both devices? | | Understand that I am not objecting to the use of DHCP. I am trying to | understand the scenario in which it is actually necessary, given that | SNMPv3 currently requires key distribution for mutual authentication | before secure communications can be established. SNMPv3 was explicitly | designed to protect its information from disclosure to unauthenticated | entities. During SNMpv3 design discussions, there was a significant | segemnt of the market (part of the US govt) that argued an SNMPv3 engine | shouldn't reply to an unauthenticed entity because that would reveal | that an SNMP engine exists at a given address. On top of the strong | authentication, seeing into the MIB to see what functionality is | supported is tightly controlled by design, using the VACM access control | model. | | Given that MIDCOM is designed to manipulate security-related features | such as firewalls and NATs, it is fairly imperative that a strong SNMPv3 | security model is maintained. A hacker would need to work to get through | the SNMPv3 authentication mechanisms to talk to the box, and then past | the data access controls (authorizations) to determine that a box | supports the MIDCOM MIB module. I am not convinced that using DHCP to | advertise "the entity at this address is a middlebox, with SNMP support | of the MIDCOM MIB module" is a very secure thing to do, and that it | doesn't defeat some of the SNMPv3 security philosophy to a degree. | | | It helps the hacker to discover which services are running on which | boxes, which is why port scans are considered a general security threat. | What mechanisms are in place to ensure that DHCP doesn't disclose | information about entities that shouldn't be disclosed? What happens if | the DHCP server is compromised? | | OTOH, SNMpv3 was also designed explicitly to not use obscurity as a | security mechanism. Even if you tell a hacker that a device is a | middlebox manageable using the MIDCOM MIB module, the SNMPv3 security | should prevent them gaining unauthorized access. | |> |> > It is also possible to |> > have multiple SNMPv3 agents at the same address (e.g. to |> > manage different types of functionality present on the same |> > box), |> |> Quick question, in this case, are all the SNMP agents |> listening to the port |> or they have individual port? | | Multiple agents MAY work together, with one agent listening on a given | port, and then the "dispatcher" of the SNMP listener can forward the | requests directly to the appropriate registered engine, possibly (but | not necessarily) through a different port. There are multiple SNMP-legal | ways to support multiple engines at the same address, including the SNMP | proxy mechanisms defined in RFC3413(?). | |> |> > That's why SNMPv3 uses engineIDs for identification. SNMPv3 |> > discovery entails a type of mutual discovery, during which |> > the SNMP engines share their SNMPv3 engineIDs, and clock sync |> > information. This permits SNMPv3 to communicate with |> > different engines at a given address, or to recognize when |> > one engine has multiple addresses. This discovered |> > information cannot be provided via DHCP. |> |> > There is also the issue of key distribution. The initial |> > distribution of keys must be done outside SNMPv3, using a |> > secure protocol. This may accomplished using a key |> > distribution protocol, such as kerberos, or by kickstarting a |> > "root" or "admin" type of security relationship, and then |> > distributing additional keys using SNMPv3. DHCP is |> > inappropriate for key distribution. |> |> > DHCP might be useful for saying "there is an SNMP engine |> > (which may be a midcom agent or a middlebox or some other |> > type of SNMP engine) at address a.b.c.d, but the information |> > DHCP provides alone will be inadequate for establishing |> > secure SNMPv3 communications or for establishing non-secure |> > SNMPv3 communications. It might be adequate for identifying |> > where there is an SNMP engine that could then be "discovered" |> > using SNMPv3 discovery. If DHCP provided the engineIDs for |> > the SNMP engines, as well as the addresses to use to reach |> > each SNMP engine, that could be a good thing. |> |> As you mentioned, it will probably be interesting to provide |> engineIDs to |> identify the good SNMPv3 agent in the document. Anybody have |> some other |> comments on this? |> |> |> ...J |> | David Harrington | dbh@enterasys.com | co-chair, IETF SNMPv3 WG, concluded | | | | | _______________________________________________ | 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 exim@www1.ietf.org Tue Apr 6 05:24:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26141 for ; Tue, 6 Apr 2004 05:24:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmoO-0005MD-Lh for midcom-archive@odin.ietf.org; Tue, 06 Apr 2004 05:24:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i369O42F020583 for midcom-archive@odin.ietf.org; Tue, 6 Apr 2004 05:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmoL-0005Jk-U2; Tue, 06 Apr 2004 05:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmnr-00052Z-LM for midcom@optimus.ietf.org; Tue, 06 Apr 2004 05:23:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25877 for ; Tue, 6 Apr 2004 05:23:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAmno-0004Rv-00 for midcom@ietf.org; Tue, 06 Apr 2004 05:23:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAmfr-0002og-00 for midcom@ietf.org; Tue, 06 Apr 2004 05:15:16 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BAmKF-0007dA-00 for midcom@ietf.org; Tue, 06 Apr 2004 04:52:55 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i368qQ9h089222 for ; Tue, 6 Apr 2004 10:52:26 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i368jhcm088596 for ; Tue, 6 Apr 2004 10:45:43 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i368jh9h088593; Tue, 06 Apr 2004 10:45:43 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3B81811AA8B; Tue, 6 Apr 2004 10:45:41 +0200 (CEST) Date: Tue, 06 Apr 2004 10:45:38 +0200 From: Martin Stiemerling To: Juergen Quittek , Melinda Shore , midcom@ietf.org Subject: Re: [midcom] DHCP option - trying again Message-ID: <2147483647.1081248338@[10.1.1.109]> In-Reply-To: <2147483647.1081193242@localhost> References: <8F7AD74C-84CF-11D8-85BE-000A95E35274@cisco.com> <2147483647.1081193242@localhost> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, --On Montag, 5. April 2004 19:27 Uhr +0200 Juergen Quittek wrote: | Melinda, | | I think Joel made a very useful suggestion for solving (or reducing) the | middlebox topology problem that Cedric pointed out several times. Yes, this dhc options could be beneficial for solving the topology problem. There are some dhcp options defined (or under investigation, I'm not total sure) for transmitting routing information (destination prefix and corresponding next hop). Joel's draft would have to be extended to cover this issue. | | Joel's approach fits well into the existing IP infrastructure and should | be | followed by the IETF. My initial thought was that this work rather | belongs | to the DHC WG (I have not seen an announcement there), but probably the | MIDCOM WG is a much better home for it. I see that this fits better to the MIDCOM wg since not only pure dhc problems have to be solved, but more MIDCOM specific problems. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Apr 6 05:27:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26558 for ; Tue, 6 Apr 2004 05:27:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmrF-0006iq-CB for midcom-archive@odin.ietf.org; Tue, 06 Apr 2004 05:27:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i369R15C025838 for midcom-archive@odin.ietf.org; Tue, 6 Apr 2004 05:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmrF-0006iL-3S; Tue, 06 Apr 2004 05:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmqV-0006UM-8C for midcom@optimus.ietf.org; Tue, 06 Apr 2004 05:26:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26549 for ; Tue, 6 Apr 2004 05:26:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAmqR-00052L-00 for midcom@ietf.org; Tue, 06 Apr 2004 05:26:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAmmT-0004Bw-00 for midcom@ietf.org; Tue, 06 Apr 2004 05:22:07 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BAmad-0001lA-00 for midcom@ietf.org; Tue, 06 Apr 2004 05:09:51 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i3699M9h091096 for ; Tue, 6 Apr 2004 11:09:22 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8E493A5966 for ; Tue, 6 Apr 2004 11:09:21 +0200 (CEST) Date: Tue, 06 Apr 2004 11:09:19 +0200 From: Martin Stiemerling To: midcom@ietf.org Message-ID: <2147483647.1081249759@[10.1.1.109]> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========93F2B68D3FB0147ADA03==========" X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,MIME_SUSPECT_NAME autolearn=no version=2.60 Subject: [midcom] I-D ACTION:draft-stiemerling-midcom-simco-05.txt (fwd) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --==========93F2B68D3FB0147ADA03========== Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi all, Please find below the announcement for a new version of the MIDCOM-type protocol called SIMCO (SImple Middlebox COnfiguration) Protocol. This protocol implements all semantics defined in draft-ietf-midcom-semantics-07.txt in a binary encoding. Regards, Martin ------------ Forwarded Message ------------ Date: Montag, 5. April 2004 10:41 Uhr -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-stiemerling-midcom-simco-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 Author(s) : M. Stiemerling, et al. Filename : draft-stiemerling-midcom-simco-05.txt Pages : 62 Date : 2004-4-2 This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the MIDCOM semantics described in [RFCXXXX]. Compared to earlier experimental versions of the SIMCO protocol, this version 3 uses binary message encodings in order to reduce resource requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stiemerling-midcom-simco-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-midcom-simco-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---------- End Forwarded Message ---------- --==========93F2B68D3FB0147ADA03========== Content-Type: message/rfc822; name="I-D ACTION:draft-stiemerling-midcom-simco-05.txt" Return-Path: X-Sieve: cmu-sieve 2.0 Received: from yamato.ccrle.nec.de (neptune.office [10.1.1.83]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 46C19104290; Mon, 5 Apr 2004 17:09:46 +0200 (CEST) Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by yamato.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i35F9hfl005030; Mon, 5 Apr 2004 17:09:44 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAVJn-0003zq-AY; Mon, 05 Apr 2004 10:43:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAVI7-0003ju-RF for i-d-announce@optimus.ietf.org; Mon, 05 Apr 2004 10:41:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04631 for ; Mon, 5 Apr 2004 10:41:30 -0400 (EDT) Message-Id: <200404051441.KAA04631@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-stiemerling-midcom-simco-05.txt Date: Mon, 05 Apr 2004 10:41:29 -0400 Sender: i-d-announce-admin@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Scanned-By: MIMEDefang 2.35 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 Author(s) : M. Stiemerling, et al. Filename : draft-stiemerling-midcom-simco-05.txt Pages : 62 Date : 2004-4-2 This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the MIDCOM semantics described in [RFCXXXX]. Compared to earlier experimental versions of the SIMCO protocol, this version 3 uses binary message encodings in order to reduce resource requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stiemerling-midcom-simco-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-midcom-simco-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-5110140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stiemerling-midcom-simco-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-stiemerling-midcom-simco-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-5110140.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce --==========93F2B68D3FB0147ADA03==========-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Apr 8 07:57:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10380 for ; Thu, 8 Apr 2004 07:57:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBY9e-0004aX-NX for midcom-archive@odin.ietf.org; Thu, 08 Apr 2004 07:57:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38BvARu017638 for midcom-archive@odin.ietf.org; Thu, 8 Apr 2004 07:57:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBY9b-0004Yv-N5; Thu, 08 Apr 2004 07:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBY9P-0004Ur-8L for midcom@optimus.ietf.org; Thu, 08 Apr 2004 07:56:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10327 for ; Thu, 8 Apr 2004 07:56:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBY9N-0006xa-00 for midcom@ietf.org; Thu, 08 Apr 2004 07:56:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBWCR-0006zM-00 for midcom@ietf.org; Thu, 08 Apr 2004 05:51:57 -0400 Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx with esmtp (Exim 4.12) id 1BBTuk-0006em-00 for midcom@ietf.org; Thu, 08 Apr 2004 03:25:30 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i387OZ706314; Thu, 8 Apr 2004 09:24:35 +0200 (MEST) Received: from zctfc004.europe.nortel.com ([47.164.129.45]) by zctfc040.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2P48N8LD; Thu, 8 Apr 2004 09:24:34 +0200 Received: from [192.168.201.2] (actft04j.europe.nortel.com [47.164.193.141]) by zctfc004.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1N6PNSXP; Thu, 8 Apr 2004 09:24:34 +0200 In-Reply-To: <2147483647.1081248635@[10.1.1.109]> References: <6D745637A7E0F94DA070743C55CDA9BA017E137B@NHROCMBX1.ets.enterasy s.com> <2147483647.1081248635@[10.1.1.109]> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Joel Tran , "Harrington, David" , midcom@ietf.org From: "Cedric Aoun" Subject: Re: RE : RE : [midcom] DHCP options drafts Date: Thu, 8 Apr 2004 09:24:32 +0200 To: Martin Stiemerling X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We need to be careful with the DHCP option and have clear applicability statements about multihomed networks. Not all networks allows a Midcom agent to deterministically know which Middlebox to signal for flows with a specific destination at a particular time, why?: -Time of day routing -Qos routing -Load balancing (ECMP) -Router failures and implied route changes All of the above need to be documented in the applicability statement when a network has more than 1 Middlebox. I'm sure that we'll hear some arguments that a Midcom agent could co-host a routing control engine and be aware of the routing :-); a reality check would show that this is definitely not the case in most (if not all) the implementations. Cedric On Apr 6, 2004, at 10:50, Martin Stiemerling wrote: > Hi David, > > I agree with all your analysis. A point for configuring the IP > addresses of middleboxes dynamically might be (as Juergen pointed out) > multihoming. An MIDCOM agent that has preconfigured security > associations with the middleboxes could learn which of the boxes is > the right one for a particular destination. This could be conveyed via > a MIDCOM option in DHCP and some additional routing information > options. > > > Martin > > > --On Montag, 5. April 2004 16:10 Uhr -0400 "Harrington, David" > wrote: > > | Hi Joel, > | > | Comments inline. > | > |> -----Original Message----- > |> From: Joel Tran [mailto:joel.tran@USherbrooke.ca] > |> Sent: Monday, April 05, 2004 3:19 PM > |> To: Harrington, David; midcom@ietf.org > |> Subject: RE : RE : [midcom] DHCP options drafts > |> > |> Comments inline. > |> > |> > Since the communications between a midcom agent and the > |> > middlebox is done via SNMPv3, to provide mutual > |> > authentication, the discovery needs to be done using SNMPv3. > |> > |> True, preferably, the discovery should by done using SNMPv3. > |> However, I > |> can't figure out one thing: How we can ONLY identify SNMPv3 > |> agent performing > |> Midcom services in an effective way? With the use of DHCP, we > |> can pin-point > |> directly the Midcom device in a network. > | > | Using SNMPv3's initial discovery mechanism, one engine can discover > the > | other engine's engineID and time sync parameters. If the application > | (SNMP manager) knows the pre-shared keys of the SNMP agent on the > | middlebox, the application can look to see if the MIDCIM MIB module > is > | supported by doing a GET of one or more of the OIDs used in the > MIDCOM > | MIB module. That type of discovery is standard operating procedure > for > | most SNMP applications. > | > | That type of discovery would be appropriate for discovering MIDCOM > | agents and middleboxes. If an application searching for middleboxes > | doesn't have the shared keys for the middlebox, then it probably > | shouldn't be given access to determine what specific types of > | functionality the other SNMP engine supports. > | > | This argues for having the application (MIDCOM agent) record the > address > | of the middlebox whose SNMPv3 keys are being set into its database. > | > |> > |> > DHCP is good for dynamically assigning addresses, but SNMPv3 > |> > has specific requirements about the identification of managed > |> > nodes, and addresses have proven inadequate for > |> > identification purposes, largely as the result of > |> > technologies such as DHCP and NAT. > |> > |> DHCP serves as assigning dynamically addresses and > |> configuration parameter. > |> In our case, Midcom agent needs to know the addresses of > |> Midcom middlebox. > |> DHCP provides this means. For identification/authentication > |> is out of scope > |> of DHCP. The Midcom agent will thus have to provide > |> authentication to the > |> Midcom middlebox. > | > | I think there is a question of the order of events. If both sides > need > | to know the shared keys, wouldn't an operator be likely to be able to > | tell the midcom agent what the address of the middlebox is at the > same > | time? > | > | What is the usage scenario that requires DHCP to tell the midcom > agent > | the address of the middlebox, if the shared keys have already been > set > | into both devices? > | > | Understand that I am not objecting to the use of DHCP. I am trying to > | understand the scenario in which it is actually necessary, given that > | SNMPv3 currently requires key distribution for mutual authentication > | before secure communications can be established. SNMPv3 was > explicitly > | designed to protect its information from disclosure to > unauthenticated > | entities. During SNMpv3 design discussions, there was a significant > | segemnt of the market (part of the US govt) that argued an SNMPv3 > engine > | shouldn't reply to an unauthenticed entity because that would reveal > | that an SNMP engine exists at a given address. On top of the strong > | authentication, seeing into the MIB to see what functionality is > | supported is tightly controlled by design, using the VACM access > control > | model. > | > | Given that MIDCOM is designed to manipulate security-related features > | such as firewalls and NATs, it is fairly imperative that a strong > SNMPv3 > | security model is maintained. A hacker would need to work to get > through > | the SNMPv3 authentication mechanisms to talk to the box, and then > past > | the data access controls (authorizations) to determine that a box > | supports the MIDCOM MIB module. I am not convinced that using DHCP to > | advertise "the entity at this address is a middlebox, with SNMP > support > | of the MIDCOM MIB module" is a very secure thing to do, and that it > | doesn't defeat some of the SNMPv3 security philosophy to a degree. > | > | > | It helps the hacker to discover which services are running on which > | boxes, which is why port scans are considered a general security > threat. > | What mechanisms are in place to ensure that DHCP doesn't disclose > | information about entities that shouldn't be disclosed? What happens > if > | the DHCP server is compromised? > | > | OTOH, SNMpv3 was also designed explicitly to not use obscurity as a > | security mechanism. Even if you tell a hacker that a device is a > | middlebox manageable using the MIDCOM MIB module, the SNMPv3 security > | should prevent them gaining unauthorized access. > | > |> > |> > It is also possible to > |> > have multiple SNMPv3 agents at the same address (e.g. to > |> > manage different types of functionality present on the same > |> > box), > |> > |> Quick question, in this case, are all the SNMP agents > |> listening to the port > |> or they have individual port? > | > | Multiple agents MAY work together, with one agent listening on a > given > | port, and then the "dispatcher" of the SNMP listener can forward the > | requests directly to the appropriate registered engine, possibly (but > | not necessarily) through a different port. There are multiple > SNMP-legal > | ways to support multiple engines at the same address, including the > SNMP > | proxy mechanisms defined in RFC3413(?). > | > |> > |> > That's why SNMPv3 uses engineIDs for identification. SNMPv3 > |> > discovery entails a type of mutual discovery, during which > |> > the SNMP engines share their SNMPv3 engineIDs, and clock sync > |> > information. This permits SNMPv3 to communicate with > |> > different engines at a given address, or to recognize when > |> > one engine has multiple addresses. This discovered > |> > information cannot be provided via DHCP. > |> > |> > There is also the issue of key distribution. The initial > |> > distribution of keys must be done outside SNMPv3, using a > |> > secure protocol. This may accomplished using a key > |> > distribution protocol, such as kerberos, or by kickstarting a > |> > "root" or "admin" type of security relationship, and then > |> > distributing additional keys using SNMPv3. DHCP is > |> > inappropriate for key distribution. > |> > |> > DHCP might be useful for saying "there is an SNMP engine > |> > (which may be a midcom agent or a middlebox or some other > |> > type of SNMP engine) at address a.b.c.d, but the information > |> > DHCP provides alone will be inadequate for establishing > |> > secure SNMPv3 communications or for establishing non-secure > |> > SNMPv3 communications. It might be adequate for identifying > |> > where there is an SNMP engine that could then be "discovered" > |> > using SNMPv3 discovery. If DHCP provided the engineIDs for > |> > the SNMP engines, as well as the addresses to use to reach > |> > each SNMP engine, that could be a good thing. > |> > |> As you mentioned, it will probably be interesting to provide > |> engineIDs to > |> identify the good SNMPv3 agent in the document. Anybody have > |> some other > |> comments on this? > |> > |> > |> ...J > |> > | David Harrington > | dbh@enterasys.com > | co-chair, IETF SNMPv3 WG, concluded > | > | > | > | > | _______________________________________________ > | 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 > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Apr 22 13:22:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11939 for ; Thu, 22 Apr 2004 13:22:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhlL-0008ST-By for midcom-archive@odin.ietf.org; Thu, 22 Apr 2004 13:13:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MHDNbR032513 for midcom-archive@odin.ietf.org; Thu, 22 Apr 2004 13:13:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGheC-0005zU-NO; Thu, 22 Apr 2004 13:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhWY-0003sB-IN for midcom@optimus.ietf.org; Thu, 22 Apr 2004 12:58:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10335 for ; Thu, 22 Apr 2004 12:58:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhWT-0000ZA-7X for midcom@ietf.org; Thu, 22 Apr 2004 12:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhVT-0000GR-00 for midcom@ietf.org; Thu, 22 Apr 2004 12:57:02 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by ietf-mx with esmtp (Exim 4.12) id 1BGhUN-0007Tk-00 for midcom@ietf.org; Thu, 22 Apr 2004 12:55:51 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i3MI0iw9017192 for ; Thu, 22 Apr 2004 13:00:45 -0500 Reply-To: From: "Christopher A. Martin" To: Date: Thu, 22 Apr 2004 11:55:25 -0500 Organization: SIP1 Information Services Message-ID: <026501c4288a$9c4211b0$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0266_01C42860.B36C09B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 Subject: [midcom] Comments regarding scalability issues with STUN/TURN/etc... Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0266_01C42860.B36C09B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0267_01C42860.B36C09B0" ------=_NextPart_001_0267_01C42860.B36C09B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, it has been awhile since I last posted. These were some items posted to a common list for VoIP which I responded to regarding considerations that should be made for any protocol being used to address traversal of VoIP via middle boxes (in this case firewalls). Statements have been made that the solutions mentioned in the title provide scalability over the emerging session border controller technologies. Also the latest draft by Melinda brought up some additional points with direct statements naming a couple of these vendors. I would like to bring this discussion up a bit more to investigate the true scalability factors. I believe that we do need an IETF solution to the problem at hand that does not present yet another issue to the mix, and that the current protocol proposals need to consider scalability factors for a number of reasons. Let the attachments be a start to the discussion, while I formally write up some more examples, which were between me, Johnathan, and Jiri. Thanks in advance, Chris ------=_NextPart_001_0267_01C42860.B36C09B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone, it has been awhile = since I last posted.

 

These were some items posted to a = common list for VoIP which I responded to regarding considerations that should = be made for any protocol being used to address traversal of VoIP via middle = boxes (in this case firewalls).

 

Statements have been made that the solutions mentioned in the title provide scalability over the emerging = session border controller technologies.

 

Also the latest draft by Melinda = brought up some additional points with direct statements naming a couple of = these vendors. I would like to bring this discussion up a bit more to = investigate the true scalability factors.

 

I believe that we do need an IETF = solution to the problem at hand that does not present yet another issue to the = mix, and that the current protocol proposals need to consider scalability factors = for a number of reasons.

 

Let the attachments be a start to = the discussion, while I formally write up some more examples, which were = between me, Johnathan, and Jiri.

 

Thanks in = advance,

Chris

------=_NextPart_001_0267_01C42860.B36C09B0-- ------=_NextPart_000_0266_01C42860.B36C09B0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Reply-To: From: "Christopher A. Martin" To: "'Free World Dialup - The Future of Dialing'" Subject: RE: [FWD] STUN server, when should I use it? Date: Thu, 8 Apr 2004 18:08:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0259_01C42860.B3674EC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <6.0.3.0.0.20040408203632.02dfff00@localhost> This is a multi-part message in MIME format. ------=_NextPart_000_0259_01C42860.B3674EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit STUN servers use keep-alives between client and sip proxy to keep the firewall/nat binding open for incoming media using null sip packets from what I have seen. Chris -----Original Message----- From: Free World Dialup - The Future of Dialing [mailto:FWD@LISTSERV.PULVER.COM] On Behalf Of Jiri Kuthan Sent: Thursday, April 08, 2004 1:38 PM To: FWD@LISTSERV.PULVER.COM Subject: Re: [FWD] STUN server, when should I use it? At 07:47 PM 4/8/2004, Christopher A. Martin wrote: >What about the keepalive issue? How does that scale? I'm not sure to what keepalive issue are you reffering to, but media relay scales imho much worse than keepalives. Cheers, -jiri _____________________________________________________________ List Archives: (http://listserv.pulver.com/archives/fwd.html) Unsubscribe: (http://tinyurl.com/mg1m) ------=_NextPart_000_0259_01C42860.B3674EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [FWD] STUN server, when should I use it?

STUN servers use keep-alives between client and sip = proxy to keep the firewall/nat binding open for incoming media using = null sip packets from what I have seen.

Chris

-----Original Message-----
From: Free World Dialup - The Future of Dialing [mailto:FWD@LISTSERV.PULVER.COM] On Behalf Of Jiri Kuthan
Sent: Thursday, April 08, 2004 1:38 PM
To: FWD@LISTSERV.PULVER.COM
Subject: Re: [FWD] STUN server, when should I use = it?

At 07:47 PM 4/8/2004, Christopher A. Martin = wrote:
>What about the keepalive issue? How does that = scale?

I'm not sure to what keepalive issue are you reffering = to,
but media relay scales imho much worse than = keepalives.

Cheers,

-jiri

_____________________________________________________________
List Archives: (http://listserv.pul= ver.com/archives/fwd.html)
Unsubscribe:   (http://tinyurl.com/mg1m)

------=_NextPart_000_0259_01C42860.B3674EC0-- ------=_NextPart_000_0266_01C42860.B36C09B0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Reply-To: From: "Christopher A. Martin" To: "'Free World Dialup - The Future of Dialing'" Subject: RE: [FWD] STUN server, when should I use it? Date: Wed, 7 Apr 2004 23:35:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025D_01C42860.B369BFC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <6.0.1.1.0.20040407191757.02869eb0@pop.mailaka.net> This is a multi-part message in MIME format. ------=_NextPart_000_025D_01C42860.B369BFC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit STUN is necessary when there is no other means of traversing a NAT. Without it no one would be able to send inbound calls your way, and potentially no calls would work. There is a downside to STUN from the provider perspective in relation to the keepalive mechanism used to keep the NAT/FW bindings fresh. This is why session border controllers are used, such as the Jasomi outbound proxy listed on the FWD website. Outbound proxies provide a lot more scalability for the VoIP provider. Chris -----Original Message----- From: Free World Dialup - The Future of Dialing [mailto:FWD@LISTSERV.PULVER.COM] On Behalf Of boatman Sent: Wednesday, April 07, 2004 9:24 PM To: FWD@LISTSERV.PULVER.COM Subject: Re: [FWD] STUN server, when should I use it? Will I have less latency if I use the non-NAT configuration whenever possible? By non-NAT I mean setting the voice terminal as one would do if it had it's own IP address and was not behind something, or behind one of the SIP aware routers you mentioned. When should one use the STUN settings? Is STUN a work-around for being behind a router? At 04:59 PM 4/7/04, you wrote: >"whenever you are behind a NAT router/firewall" is a bit too general. Some >NAT systems are "SIP aware" and poke around in the data stream dynamically >to change the embedded IP addresses. > >So if you have a SIP-aware NAT box/software, you can probably get away >without doing anything "special". > >Don > > >-----Original Message----- >From: Free World Dialup - The Future of Dialing >[mailto:FWD@LISTSERV.PULVER.COM]On Behalf Of boatman >Sent: Wednesday, April 07, 2004 2:54 PM >To: FWD@LISTSERV.PULVER.COM >Subject: [FWD] STUN server, when should I use it? > > >Referring to >http://www.freeworlddialup.com/support/configuration_guide/configure_yo ur_fw >d_certified_phone/sipura_spa_2000 > >I have a Sipura SPA-2000. > >I understand that I should use the Outbound Proxy settings whenever I am >behind a NAT firewall. When should I or shouldn't I use the settings for >STUN? > >What is a STUN server? > >When I use the outbound proxy settings do my voice packets always go through >the proxy during conversation? Wouldn't there be less latency if the >packets were routed directly to the IP address of the other party? > >Is there a site where I can find the explanations of all this stuff? _____________________________________________________________ List Archives: (http://listserv.pulver.com/archives/fwd.html) Unsubscribe: (http://tinyurl.com/mg1m) ------=_NextPart_000_025D_01C42860.B369BFC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [FWD] STUN server, when should I use it?

STUN is necessary when there is no other means of = traversing a NAT. Without it no one would be able to send inbound calls = your way, and potentially no calls would work.

There is a downside to STUN from the provider = perspective in relation to the keepalive mechanism used to keep the = NAT/FW bindings fresh. This is why session border controllers are used, = such as the Jasomi outbound proxy listed on the FWD website. Outbound = proxies provide a lot more scalability for the VoIP provider.

Chris

-----Original Message-----
From: Free World Dialup - The Future of Dialing [mailto:FWD@LISTSERV.PULVER.COM] On Behalf Of boatman
Sent: Wednesday, April 07, 2004 9:24 PM
To: FWD@LISTSERV.PULVER.COM
Subject: Re: [FWD] STUN server, when should I use = it?

Will I have less latency if I use the non-NAT = configuration whenever possible?  By non-NAT I mean setting the = voice terminal as one would do if it had it's own IP address and was not = behind something, or behind one of the SIP aware routers you = mentioned.

When should one use the STUN settings?  Is STUN a = work-around for being behind a router?


At 04:59 PM 4/7/04, you wrote:
>"whenever you are behind a NAT = router/firewall" is a bit too general. Some
>NAT systems are "SIP aware" and poke = around in the data stream dynamically
>to change the embedded IP addresses.
>
>So if you have a SIP-aware NAT box/software, you = can probably get away
>without doing anything = "special".
>
>Don
>
>
>-----Original Message-----
>From: Free World Dialup - The Future of = Dialing
>[mailto:FWD@LISTSERV.PULVER.COM]On Behalf Of boatman
>Sent: Wednesday, April 07, 2004 2:54 PM
>To: FWD@LISTSERV.PULVER.COM
>Subject: [FWD] STUN server, when should I use = it?
>
>
>Referring to
>http://www.freeworlddialup.com/support/configuration_guide/c= onfigure_your_fw
>d_certified_phone/sipura_spa_2000
>
>I have a Sipura SPA-2000.
>
>I understand that I should use the Outbound Proxy = settings whenever I am
>behind a NAT firewall.  When should I or = shouldn't I use the settings for
>STUN?
>
>What is a STUN server?
>
>When I use the outbound proxy settings do my = voice packets always go through
>the proxy during conversation?  Wouldn't = there be less latency if the
>packets were routed directly to the IP address of = the other party?
>
>Is there a site where I can find the explanations = of all this stuff?

_____________________________________________________________
List Archives: (http://listserv.pul= ver.com/archives/fwd.html)
Unsubscribe:   (http://tinyurl.com/mg1m)

------=_NextPart_000_025D_01C42860.B369BFC0-- ------=_NextPart_000_0266_01C42860.B36C09B0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Reply-To: From: "Christopher A. Martin" To: "'Free World Dialup - The Future of Dialing'" Subject: RE: [FWD] STUN server, when should I use it? Date: Wed, 7 Apr 2004 23:32:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0261_01C42860.B36C09B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: This is a multi-part message in MIME format. ------=_NextPart_000_0261_01C42860.B36C09B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What about the issue of keepalives hitting the sip proxy, has that been a problem? For a couple of users I wouldn't think there is an issue, but for multiple users over say 100, there must be some degradation using the stun server? Chris -----Original Message----- From: Free World Dialup - The Future of Dialing [mailto:FWD@LISTSERV.PULVER.COM] On Behalf Of Don Sent: Wednesday, April 07, 2004 7:00 PM To: FWD@LISTSERV.PULVER.COM Subject: Re: [FWD] STUN server, when should I use it? "whenever you are behind a NAT router/firewall" is a bit too general. Some NAT systems are "SIP aware" and poke around in the data stream dynamically to change the embedded IP addresses. So if you have a SIP-aware NAT box/software, you can probably get away without doing anything "special". Don -----Original Message----- From: Free World Dialup - The Future of Dialing [mailto:FWD@LISTSERV.PULVER.COM]On Behalf Of boatman Sent: Wednesday, April 07, 2004 2:54 PM To: FWD@LISTSERV.PULVER.COM Subject: [FWD] STUN server, when should I use it? Referring to http://www.freeworlddialup.com/support/configuration_guide/configure_you r_fw d_certified_phone/sipura_spa_2000 I have a Sipura SPA-2000. I understand that I should use the Outbound Proxy settings whenever I am behind a NAT firewall. When should I or shouldn't I use the settings for STUN? What is a STUN server? When I use the outbound proxy settings do my voice packets always go through the proxy during conversation? Wouldn't there be less latency if the packets were routed directly to the IP address of the other party? Is there a site where I can find the explanations of all this stuff? _____________________________________________________________ List Archives: (http://listserv.pulver.com/archives/fwd.html) Unsubscribe: (http://tinyurl.com/mg1m) _____________________________________________________________ List Archives: (http://listserv.pulver.com/archives/fwd.html) Unsubscribe: (http://tinyurl.com/mg1m) ------=_NextPart_000_0261_01C42860.B36C09B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [FWD] STUN server, when should I use it?

What about the issue of keepalives hitting the sip = proxy, has that been a problem?

For a couple of users I wouldn’t think there is = an issue, but for multiple users over say 100, there must be some = degradation using the stun server?

Chris

-----Original Message-----
From: Free World Dialup - The Future of Dialing [mailto:FWD@LISTSERV.PULVER.COM] On Behalf Of Don
Sent: Wednesday, April 07, 2004 7:00 PM
To: FWD@LISTSERV.PULVER.COM
Subject: Re: [FWD] STUN server, when should I use = it?

"whenever you are behind a NAT = router/firewall" is a bit too general. Some
NAT systems are "SIP aware" and poke around = in the data stream dynamically
to change the embedded IP addresses.

So if you have a SIP-aware NAT box/software, you can = probably get away
without doing anything "special".

Don


-----Original Message-----
From: Free World Dialup - The Future of = Dialing
[mailto:FWD@LISTSERV.PULVER.COM]On Behalf Of boatman
Sent: Wednesday, April 07, 2004 2:54 PM
To: FWD@LISTSERV.PULVER.COM
Subject: [FWD] STUN server, when should I use = it?


Referring to
http://www.freeworlddialup.com/support/configuration_guide/c= onfigure_your_fw
d_certified_phone/sipura_spa_2000

I have a Sipura SPA-2000.

I understand that I should use the Outbound Proxy = settings whenever I am
behind a NAT firewall.  When should I or = shouldn't I use the settings for
STUN?

What is a STUN server?

When I use the outbound proxy settings do my voice = packets always go through
the proxy during conversation?  Wouldn't there = be less latency if the
packets were routed directly to the IP address of the = other party?

Is there a site where I can find the explanations of = all this stuff?

_____________________________________________________________
List Archives: (http://listserv.pul= ver.com/archives/fwd.html)
Unsubscribe:   (http://tinyurl.com/mg1m)

_____________________________________________________________
List Archives: (http://listserv.pul= ver.com/archives/fwd.html)
Unsubscribe:   (http://tinyurl.com/mg1m)

------=_NextPart_000_0261_01C42860.B36C09B0-- ------=_NextPart_000_0266_01C42860.B36C09B0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Apr 22 17:06:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00448 for ; Thu, 22 Apr 2004 17:06:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkMl-0007Bx-Jh for midcom-archive@odin.ietf.org; Thu, 22 Apr 2004 16:00:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MK0B52027629 for midcom-archive@odin.ietf.org; Thu, 22 Apr 2004 16:00:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk86-0001yY-6a; Thu, 22 Apr 2004 15:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjXU-0006Xe-2f for midcom@optimus.ietf.org; Thu, 22 Apr 2004 15:07:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18706 for ; Thu, 22 Apr 2004 15:07:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjXO-00066c-Ur for midcom@ietf.org; Thu, 22 Apr 2004 15:07:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjWP-0005pp-00 for midcom@ietf.org; Thu, 22 Apr 2004 15:06:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGjVL-0005Jj-00 for midcom@ietf.org; Thu, 22 Apr 2004 15:04:59 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 11:15:16 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MJ4TW9002300; Thu, 22 Apr 2004 12:04:29 -0700 (PDT) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with SMTP id ATH23053; Thu, 22 Apr 2004 12:04:27 -0700 (PDT) Date: Thu, 22 Apr 2004 15:04:25 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: rdroms@cisco.com To: midcom@ietf.org From: Melinda Shore Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] Possible new work item Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As was discussed here several weeks ago, there's a proposal for midcom to add new deliverables - DHCP and DHCPv6 options to configure middlebox addresses into endpoints. If we were to undertake the work, we'd be working with the dhc working group (expert review) and ideally we'd be able to get a volunteer from that group to work with the editor of the deliverable. I've appended some proposed charter text. The two questions are: 1) do we want to take on the work, and 2) is the proposed charter paragraph okay? Thanks, Melinda The working group will also produce documents describing DHCP and DHCPv6 options for configuring middlebox addresses into endpoints. These are not a replacement for a more sophisticated routing or discovery mechanism, but may prove useful in simple network topologies where network endpoints are making requests directly of middleboxes rather than relying on third parties, such as call control servers, to make middlebox requests on their behalf. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Apr 23 15:21:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02402 for ; Fri, 23 Apr 2004 15:21:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH61c-0002Tt-Kk for midcom-archive@odin.ietf.org; Fri, 23 Apr 2004 15:07:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NJ7mRY009491 for midcom-archive@odin.ietf.org; Fri, 23 Apr 2004 15:07:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5lQ-00067j-4f; Fri, 23 Apr 2004 14:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5IY-0001sT-NH for midcom@optimus.ietf.org; Fri, 23 Apr 2004 14:21:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24861 for ; Fri, 23 Apr 2004 14:21:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5IW-0006Nf-5L for midcom@ietf.org; Fri, 23 Apr 2004 14:21:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5HY-00069B-00 for midcom@ietf.org; Fri, 23 Apr 2004 14:20:13 -0400 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 1BH5HE-0005ue-00 for midcom@ietf.org; Fri, 23 Apr 2004 14:19:52 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 23 Apr 2004 11:19:21 -0700 Message-ID: Thread-Topic: Port preservation Thread-Index: AcQpX37U9XM5Ab20Ss6rfFdN0kbryg== From: "Yutaka Takeda" To: "Midcom" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] Port preservation Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Does anyone know what the real motivation for NAT designers to implement the port preservation[1] is? Is there an actual service or application that depends on this behavior? I just realized that I know such NATs exist but why... [1] http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-00.txt Yutaka _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Apr 23 19:35:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22222 for ; Fri, 23 Apr 2004 19:35:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9zx-0004Yq-4k for midcom-archive@odin.ietf.org; Fri, 23 Apr 2004 19:22:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NNMLef017509 for midcom-archive@odin.ietf.org; Fri, 23 Apr 2004 19:22:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9tp-0002yQ-Ka; Fri, 23 Apr 2004 19:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9kW-000875-0J for midcom@optimus.ietf.org; Fri, 23 Apr 2004 19:06:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20932 for ; Fri, 23 Apr 2004 19:06:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH9kS-0002EU-Mi for midcom@ietf.org; Fri, 23 Apr 2004 19:06:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH9jV-000204-00 for midcom@ietf.org; Fri, 23 Apr 2004 19:05:21 -0400 Received: from web40409.mail.yahoo.com ([66.218.78.106]) by ietf-mx with smtp (Exim 4.12) id 1BH9ia-0001Xg-00 for midcom@ietf.org; Fri, 23 Apr 2004 19:04:24 -0400 Message-ID: <20040423230352.18703.qmail@web40409.mail.yahoo.com> Received: from [66.224.113.194] by web40409.mail.yahoo.com via HTTP; Fri, 23 Apr 2004 16:03:52 PDT Date: Fri, 23 Apr 2004 16:03:52 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Port preservation To: Yutaka Takeda , Midcom , stun@www.vovida.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Port preservation is desirable in some limited cases where applications and protocols require a certain number to be used for source and/or destination. ex: IKE-v1 assumes UDP port 500 on both src and dest. cheers, suresh --- Yutaka Takeda wrote: > > Does anyone know what the real motivation for NAT designers to > implement the port preservation[1] is? Is there an actual service > or application that depends on this behavior? I just realized that > I know such NATs exist but why... > > [1] > http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-00.txt > > Yutaka > > _______________________________________________ > 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 exim@www1.ietf.org Fri Apr 23 20:27:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24926 for ; Fri, 23 Apr 2004 20:27:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAoS-0003bz-Rm for midcom-archive@odin.ietf.org; Fri, 23 Apr 2004 20:14:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O0EWQU013860 for midcom-archive@odin.ietf.org; Fri, 23 Apr 2004 20:14:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAjE-0002CH-M4; Fri, 23 Apr 2004 20:09:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAcw-00089b-Lp for midcom@optimus.ietf.org; Fri, 23 Apr 2004 20:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23873 for ; Fri, 23 Apr 2004 20:02:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHAcu-0001Eo-OI for midcom@ietf.org; Fri, 23 Apr 2004 20:02:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHAc2-0000yY-00 for midcom@ietf.org; Fri, 23 Apr 2004 20:01:43 -0400 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 1BHAbV-0000cg-00 for midcom@ietf.org; Fri, 23 Apr 2004 20:01:09 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] Port preservation x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 23 Apr 2004 17:00:38 -0700 Message-ID: Thread-Topic: [midcom] Port preservation Thread-Index: AcQph0E+s1u4TWDDQ9C7T5Z7UvgXTAAAo7Qg From: "Yutaka Takeda" To: "Pyda Srisuresh" , "Midcom" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I see. There is one more question. Looking at the Cullen's STUN test result, all the port preservation=20 NATs are of a cone NAT as primary behavior. Do you think there is a reason for that? I mean, if it is 'desirable' to have a certain port number on the NAT, and a host can talk to *multiple* hosts on=20 the port number...? Thanks, Yutaka > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Friday, April 23, 2004 4:04 PM > To: Yutaka Takeda; Midcom; stun@www.vovida.org > Subject: Re: [midcom] Port preservation >=20 >=20 > Port preservation is desirable in some limited cases where=20 > applications and > protocols require a certain number to be used for source=20 > and/or destination. > ex: IKE-v1 assumes UDP port 500 on both src and dest. >=20 > cheers, > suresh > =20 > --- Yutaka Takeda wrote: > >=20 > > Does anyone know what the real motivation for NAT designers to=20 > > implement the port preservation[1] is? Is there an actual service=20 > > or application that depends on this behavior? I just realized that=20 > > I know such NATs exist but why... > >=20 > > [1] > >=20 > http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun > -results-00.txt > >=20 > > Yutaka > >=20 > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom >=20 >=20 > =3D=3D=3D=3D=3D >=20 >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Apr 26 08:17:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14471 for ; Mon, 26 Apr 2004 08:17:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI50F-00089A-3t for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 08:14:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QCERVP031297 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 08:14:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4u2-0006yZ-H6; Mon, 26 Apr 2004 08:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4p8-0005RL-Sd for midcom@optimus.ietf.org; Mon, 26 Apr 2004 08:02:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13757 for ; Mon, 26 Apr 2004 08:02:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI4p7-0003Vr-T0 for midcom@ietf.org; Mon, 26 Apr 2004 08:02:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI4oD-0003JQ-00 for midcom@ietf.org; Mon, 26 Apr 2004 08:02:02 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BI4nZ-00035j-00 for midcom@ietf.org; Mon, 26 Apr 2004 08:01:21 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2004 04:12:19 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3QC0nSu000768 for ; Mon, 26 Apr 2004 05:00:49 -0700 (PDT) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with SMTP id ATJ60362; Mon, 26 Apr 2004 05:00:48 -0700 (PDT) Date: Mon, 26 Apr 2004 08:00:46 -0400 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <5A236B7C-9779-11D8-9F75-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] More on new work item Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There's been no feedback on the proposed charter change, which concerns me. I hope that people will speak up regardless of whether they think the proposed work item is a good idea or a bad idea. I don't think getting the work done would be an issue - there are always people willing to author documents. However, getting people to *review* documents is far more difficult, and I don't think we can allow work to go forward if we don't have a reasonable expectation that people with subject area expertise - in this case, the midcom working group - are willing to take the time to provide expert review as the document is progressed. I don't want to make any assumptions about what the lack of feedback means, so even a simple "yes" or "no" on the proposed work item would be much appreciated. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Apr 26 11:17:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26407 for ; Mon, 26 Apr 2004 11:17:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7kp-0003Xe-DN for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 11:10:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QFAh1G013614 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 11:10:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7bV-00019h-2B; Mon, 26 Apr 2004 11:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7XX-0008Gz-Af for midcom@optimus.ietf.org; Mon, 26 Apr 2004 10:56:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25506 for ; Mon, 26 Apr 2004 10:56:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7XU-0004KV-Ml for midcom@ietf.org; Mon, 26 Apr 2004 10:56:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7WX-0004Hj-00 for midcom@ietf.org; Mon, 26 Apr 2004 10:55:58 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BI7Vi-0004CQ-00 for midcom@ietf.org; Mon, 26 Apr 2004 10:55:06 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i3QEsYri048248 for ; Mon, 26 Apr 2004 16:54:34 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i3QEqddg048016 for ; Mon, 26 Apr 2004 16:52:39 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i3QEqcri048015; Mon, 26 Apr 2004 16:52:39 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BA31B12921B; Mon, 26 Apr 2004 16:52:37 +0200 (CEST) Date: Mon, 26 Apr 2004 16:52:30 +0200 From: Martin Stiemerling To: Melinda Shore , midcom@ietf.org Cc: rdroms@cisco.com Subject: Re: [midcom] Possible new work item Message-ID: <2147483647.1082998350@[10.1.1.109]> In-Reply-To: References: X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Melinda, I'm fine with the new item and support it. The text for proposed charter is OK for me. Martin --On Donnerstag, 22. April 2004 15:04 Uhr -0400 Melinda Shore wrote: | As was discussed here several weeks ago, there's a proposal for midcom | to add new deliverables - DHCP and DHCPv6 options to configure middlebox | addresses into endpoints. If we were to undertake the work, we'd be | working with the dhc working group (expert review) and ideally we'd | be able to get a volunteer from that group to work with the editor of the | deliverable. I've appended some proposed charter text. The two | questions are: | | 1) do we want to take on the work, and | 2) is the proposed charter paragraph okay? | | Thanks, | | Melinda | | | The working group will also produce documents describing DHCP and | DHCPv6 options for configuring middlebox addresses into endpoints. | These are not a replacement for a more sophisticated routing or | discovery mechanism, but may prove useful in simple network topologies | where network endpoints are making requests directly of middleboxes | rather than relying on third parties, such as call control servers, to | make middlebox requests on their behalf. | | | _______________________________________________ | 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 exim@www1.ietf.org Mon Apr 26 11:30:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27329 for ; Mon, 26 Apr 2004 11:30:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI82K-0000to-VK for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 11:28:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QFSmAC003432 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 11:28:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7q2-0005DP-JY; Mon, 26 Apr 2004 11:16:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7gE-00027G-SY for midcom@optimus.ietf.org; Mon, 26 Apr 2004 11:05:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25886 for ; Mon, 26 Apr 2004 11:05:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7gC-0004qQ-03 for midcom@ietf.org; Mon, 26 Apr 2004 11:05:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7fL-0004oe-00 for midcom@ietf.org; Mon, 26 Apr 2004 11:05:03 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1BI7et-0004lg-00 for midcom@ietf.org; Mon, 26 Apr 2004 11:04:35 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3QF3pY08249; Mon, 26 Apr 2004 11:03:51 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Apr 2004 11:03:52 -0400 Message-ID: From: "Mary Barnes" To: "'Melinda Shore'" , midcom@ietf.org Cc: rdroms@cisco.com Subject: RE: [midcom] Possible new work item Date: Mon, 26 Apr 2004 10:45:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42B9D.195DACE0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C42B9D.195DACE0 Content-Type: text/plain My responses embedded below [MB]. Regards, Mary H. Barnes mary.barnes@nortelnetworks.com -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Thursday, April 22, 2004 2:04 PM To: midcom@ietf.org Cc: rdroms@cisco.com Subject: [midcom] Possible new work item As was discussed here several weeks ago, there's a proposal for midcom to add new deliverables - DHCP and DHCPv6 options to configure middlebox addresses into endpoints. If we were to undertake the work, we'd be working with the dhc working group (expert review) and ideally we'd be able to get a volunteer from that group to work with the editor of the deliverable. I've appended some proposed charter text. The two questions are: 1) do we want to take on the work, and [MB] I think it's reasonable for MIDCOM to take this on. 2) is the proposed charter paragraph okay? [MB] Looks good. Thanks, Melinda The working group will also produce documents describing DHCP and DHCPv6 options for configuring middlebox addresses into endpoints. These are not a replacement for a more sophisticated routing or discovery mechanism, but may prove useful in simple network topologies where network endpoints are making requests directly of middleboxes rather than relying on third parties, such as call control servers, to make middlebox requests on their behalf. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C42B9D.195DACE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] Possible new work item

My responses embedded below [MB].

Regards,
Mary H. Barnes
mary.barnes@nortelnetworks.com

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Thursday, April 22, 2004 2:04 PM
To: midcom@ietf.org
Cc: rdroms@cisco.com
Subject: [midcom] Possible new work item


As was discussed here several weeks ago, there's a = proposal for midcom to add new deliverables - DHCP and DHCPv6 options = to configure middlebox addresses into endpoints.  If we were to = undertake the work, we'd be working with the dhc working group (expert = review) and ideally we'd be able to get a volunteer from that group to = work with the editor of

the
deliverable.  I've appended some proposed = charter text.  The two questions are:

1) do we want to take on the work, and
[MB] I think it's reasonable for MIDCOM to take this = on.

2) is the proposed charter paragraph okay?
[MB] Looks good.

Thanks,

Melinda


The working group will also produce documents = describing DHCP and DHCPv6 options for configuring middlebox addresses = into endpoints. These are not a replacement for a more sophisticated = routing or discovery mechanism, but may prove useful in simple network = topologies where network endpoints are making requests directly of = middleboxes rather than relying on third parties, such as call control = servers, to make middlebox requests on their behalf.


_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C42B9D.195DACE0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Apr 26 15:18:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12634 for ; Mon, 26 Apr 2004 15:18:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBYI-0005Ej-AJ for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 15:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QJE2kZ020128 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 15:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBKn-00035G-Pl; Mon, 26 Apr 2004 15:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBBC-0001Ti-VA for midcom@optimus.ietf.org; Mon, 26 Apr 2004 14:50:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09800 for ; Mon, 26 Apr 2004 14:50:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIBBA-0006hb-5l for midcom@ietf.org; Mon, 26 Apr 2004 14:50:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIBAI-0006eB-00 for midcom@ietf.org; Mon, 26 Apr 2004 14:49:15 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIB9m-0006ZY-00 for midcom@ietf.org; Mon, 26 Apr 2004 14:48:42 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2004 10:59:44 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QImAW9006463; Mon, 26 Apr 2004 11:48:10 -0700 (PDT) Received: from [10.0.0.107] (sjc-vpn1-480.cisco.com [10.21.97.224]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOK45559; Mon, 26 Apr 2004 11:48:09 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 26 Apr 2004 10:41:30 -1000 Subject: Re: [midcom] Port preservation From: Cullen Jennings To: Yutaka Takeda , Midcom , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There may be many but the two reasons I have heard are below - neither of which make much sense to me. Makes debugging easier by not switching the port traffic is on. This allows network sniffers and such guess the type of traffic from the port. (Personally I find this argument a little hard to buy given it is the source port that is being preserved and using ports for traffic type determination is usually based on the destination port) Higher odds of interoperability for protocols. The argument goes that A sends though a NAT to B. B may reply expecting to go to a certain port number so if that does not change life will be better. I suspect that most applications that reply to the correct IP, are likely to also reply to port the packet came from but who knows. The most common answer I get to this questions and the one that seems most believable ... "Because vendor X's NAT worked that way so we made ours do the same" I don't know - it is a good questions. Can others provide any insight into this? On 4/23/04 11:19 AM, "Yutaka Takeda" wrote: > > Does anyone know what the real motivation for NAT designers to > implement the port preservation[1] is? Is there an actual service > or application that depends on this behavior? I just realized that > I know such NATs exist but why... > > [1] > http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-00.txt > > Yutaka > > _______________________________________________ > 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 exim@www1.ietf.org Mon Apr 26 17:22:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24065 for ; Mon, 26 Apr 2004 17:22:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDKq-0005Ze-T6 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 17:08:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QL8GFU021421 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 17:08:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDBN-0001qK-H2; Mon, 26 Apr 2004 16:58:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BICy5-0005wL-LC for midcom@optimus.ietf.org; Mon, 26 Apr 2004 16:44:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17809 for ; Mon, 26 Apr 2004 16:44:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BICy3-0007VZ-Dh for midcom@ietf.org; Mon, 26 Apr 2004 16:44:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICmy-0005Wj-00 for midcom@ietf.org; Mon, 26 Apr 2004 16:33:17 -0400 Received: from web40414.mail.yahoo.com ([66.218.78.111]) by ietf-mx with smtp (Exim 4.12) id 1BICT7-0004TP-00 for midcom@ietf.org; Mon, 26 Apr 2004 16:12:45 -0400 Message-ID: <20040426201211.19836.qmail@web40414.mail.yahoo.com> Received: from [66.224.113.194] by web40414.mail.yahoo.com via HTTP; Mon, 26 Apr 2004 13:12:11 PDT Date: Mon, 26 Apr 2004 13:12:11 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] Port preservation To: Yutaka Takeda , Midcom , stun@www.vovida.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The following text from draft-ford-midcom-p2p-02.txt might be a good way to answer this. cheers, suresh 5.3.1. Preserving port numbers Some NATs, when establishing a new UDP session, attempt to assign the same public port number as the corresponding private port number, if that port number happens to be available. For example, if client A at address 10.0.0.1 initiates an outgoing UDP session with a datagram from port number 1234, and the NAT's public port number 1234 happens to be available, then the NAT uses port number 1234 at the NAT's public IP address as the translated endpoint address for the session. This behavior might be beneficial to some legacy UDP applications that expect to communicate only using specific UDP port numbers, but it is not recommended that applications depend on this behavior since it is only possible for a NAT to preserve the port number if at most one node on the internal network is using that port number. In addition, a NAT should NOT try to preserve the port number in a new session if doing so would conflict with an existing port binding. For example, suppose client A at internal port 1234 has established a session with external server S, and NAT A has created a port binding to public port 62000, because public port number 1234 on the NAT was not available at the time. Now, suppose port number 1234 on the NAT subsequently becomes available, and while the session between A and S is still active, client A initiates a new session from the same internal port (1234) to a different external node B. In this case, because a port binding has already been established between client A's port 1234 and the NAT's public port 62000, this binding should be preserved and the new session should reuse the port binding (to port 62000). The NAT should not assign public port 1234 to this new session just because port 1234 has become available. Such a behavior would not be likely to benefit the application in any way since the application has already been operating with a translated port number, and it would break any attempts the application might make to establish peer-to-peer connections using the UDP hole punching technique. --- Yutaka Takeda wrote: > I see. > > There is one more question. > Looking at the Cullen's STUN test result, all the port preservation > NATs are of a cone NAT as primary behavior. Do you think there is > a reason for that? I mean, if it is 'desirable' to have a certain > port number on the NAT, and a host can talk to *multiple* hosts on > the port number...? > > Thanks, > Yutaka > > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > > Sent: Friday, April 23, 2004 4:04 PM > > To: Yutaka Takeda; Midcom; stun@www.vovida.org > > Subject: Re: [midcom] Port preservation > > > > > > Port preservation is desirable in some limited cases where > > applications and > > protocols require a certain number to be used for source > > and/or destination. > > ex: IKE-v1 assumes UDP port 500 on both src and dest. > > > > cheers, > > suresh > > > > --- Yutaka Takeda wrote: > > > > > > Does anyone know what the real motivation for NAT designers to > > > implement the port preservation[1] is? Is there an actual service > > > or application that depends on this behavior? I just realized that > > > I know such NATs exist but why... > > > > > > [1] > > > > > http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun > > -results-00.txt > > > > > > Yutaka > > > > > > _______________________________________________ > > > 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 ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Apr 26 17:29:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25149 for ; Mon, 26 Apr 2004 17:29:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDWX-0007tM-FN for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 17:20:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLKLQM030330 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 17:20:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDDD-0002zW-Kz; Mon, 26 Apr 2004 17:00:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BID5k-0008Er-Lh for midcom@optimus.ietf.org; Mon, 26 Apr 2004 16:52:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20065 for ; Mon, 26 Apr 2004 16:52:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BID5i-0001EE-KR for midcom@ietf.org; Mon, 26 Apr 2004 16:52:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICvL-0006wc-00 for midcom@ietf.org; Mon, 26 Apr 2004 16:41:56 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by ietf-mx with esmtp (Exim 4.12) id 1BICj9-0004rz-00 for midcom@ietf.org; Mon, 26 Apr 2004 16:29:20 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i3QLYbw9007420; Mon, 26 Apr 2004 16:34:37 -0500 Reply-To: From: "Christopher A. Martin" To: "'Cullen Jennings'" , "'Yutaka Takeda'" , "'Midcom'" , Subject: RE: [midcom] Port preservation Date: Mon, 26 Apr 2004 15:28:42 -0500 Organization: SIP1 Information Services Message-ID: <008501c42bcd$11c94670$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, The only reason that I can think of, that may be a good reason, is to provide the appearance that a client is communicating directly with a server on a standard server port (for that professional, I'm a big organization look and feel). Some applications do check for this for paranoid security reasons, but they are less common. We typically call this a static port translation, irregardless of vendor, and it can be configured on many of the popular enterprise class firewalls. The other common type of configuration used for the same reason would be a static IP NAT translation, which provides the server with a whole range of ports that it can be listening on. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Cullen Jennings Sent: Monday, April 26, 2004 3:42 PM To: Yutaka Takeda; Midcom; stun@www.vovida.org Subject: Re: [midcom] Port preservation There may be many but the two reasons I have heard are below - neither of which make much sense to me. Makes debugging easier by not switching the port traffic is on. This allows network sniffers and such guess the type of traffic from the port. (Personally I find this argument a little hard to buy given it is the source port that is being preserved and using ports for traffic type determination is usually based on the destination port) Higher odds of interoperability for protocols. The argument goes that A sends though a NAT to B. B may reply expecting to go to a certain port number so if that does not change life will be better. I suspect that most applications that reply to the correct IP, are likely to also reply to port the packet came from but who knows. The most common answer I get to this questions and the one that seems most believable ... "Because vendor X's NAT worked that way so we made ours do the same" I don't know - it is a good questions. Can others provide any insight into this? On 4/23/04 11:19 AM, "Yutaka Takeda" wrote: > > Does anyone know what the real motivation for NAT designers to > implement the port preservation[1] is? Is there an actual service > or application that depends on this behavior? I just realized that > I know such NATs exist but why... > > [1] > http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-0 0.txt > > Yutaka > > _______________________________________________ > 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Apr 26 17:45:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26064 for ; Mon, 26 Apr 2004 17:45:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDg6-0002gf-PN for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 17:30:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLUEvA010324 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 17:30:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDYV-0000lr-Sj; Mon, 26 Apr 2004 17:22:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDG7-0003cU-Px for midcom@optimus.ietf.org; Mon, 26 Apr 2004 17:03:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21965 for ; Mon, 26 Apr 2004 17:03:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDG5-000314-LY for midcom@ietf.org; Mon, 26 Apr 2004 17:03:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BID9s-0001uX-00 for midcom@ietf.org; Mon, 26 Apr 2004 16:56:58 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BID11-0000EU-00 for midcom@ietf.org; Mon, 26 Apr 2004 16:47:47 -0400 Received: from dynamicsoft.com ([63.113.46.158]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3QKlQus018816; Mon, 26 Apr 2004 16:47:26 -0400 (EDT) Message-ID: <408D754C.5080708@dynamicsoft.com> Date: Mon, 26 Apr 2004 16:47:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore CC: midcom@ietf.org Subject: Re: [midcom] More on new work item References: <5A236B7C-9779-11D8-9F75-000A95E35274@cisco.com> In-Reply-To: <5A236B7C-9779-11D8-9F75-000A95E35274@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm not sure we should take on these work items. My concerns are mostly practical. I think we agree that DHCP applicability is only in very, very limited topologies - only in simple stub networks where an end user client would normally directly talk to a nat. This would really be limited to consumers with home nats, or to enterprises. I think its unlikely that an enterprise would actually allow end clients to control the nat, due to the serious potential for abuse (imagine a virus infecting a PC, causing it to ask the middlebox to open all ports to all addresses). As such, I dont think this is workable in enterprise. That leaves home NAT. However, do we think that manufacturers of such devices are likely to support midcom? I'd like to hear from one on this list. If not, this work item would be useful only in theory. Even if they did, how would we expect the clients to be configured with the security credentials needed to exercise midcom control over their nat? If such information is manually configured into the client, why can't you manually configure the IP of the home NAT as well? Thanks, Jonathan R. Melinda Shore wrote: > There's been no feedback on the proposed charter change, which concerns > me. I hope that people will speak up regardless of whether they think > the proposed work item is a good idea or a bad idea. > > I don't think getting the work done would be an issue - there are > always people willing to author documents. However, getting people > to *review* documents is far more difficult, and I don't think we can > allow work to go forward if we don't have a reasonable expectation > that people with subject area expertise - in this case, the midcom > working group - are willing to take the time to provide expert review > as the document is progressed. I don't want to make any assumptions > about what the lack of feedback means, so even a simple "yes" or "no" > on the proposed work item would be much appreciated. > > Thanks, > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Apr 26 18:47:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01251 for ; Mon, 26 Apr 2004 18:47:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEo6-00078J-6t for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 18:42:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QMgYAx027408 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 18:42:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEhk-0005xy-Q0; Mon, 26 Apr 2004 18:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEbH-0004lG-Jt for midcom@optimus.ietf.org; Mon, 26 Apr 2004 18:29:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00208 for ; Mon, 26 Apr 2004 18:29:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEbE-0002iz-IU for midcom@ietf.org; Mon, 26 Apr 2004 18:29:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEaK-0002ft-00 for midcom@ietf.org; Mon, 26 Apr 2004 18:28:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIEZa-0002cq-00 for midcom@ietf.org; Mon, 26 Apr 2004 18:27:34 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIEZb-0002gZ-E7 for midcom@ietf.org; Mon, 26 Apr 2004 18:27:35 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i3QNWdw9007638; Mon, 26 Apr 2004 18:32:40 -0500 Reply-To: From: "Christopher A. Martin" To: "'Jonathan Rosenberg'" , "'Melinda Shore'" Cc: Subject: RE: [midcom] More on new work item Date: Mon, 26 Apr 2004 17:26:44 -0500 Organization: SIP1 Information Services Message-ID: <009901c42bdd$8ea7b9a0$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <408D754C.5080708@dynamicsoft.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I totally agree with Jonathan's position on the scope of DHCP as outlined below. Either way though, IMHO, MIDCOM does not appear to be useful for anything other than a carrier deployment or in a large enterprise deployment that controls all aspects of a MIDCOM deployment, just from a business/security policy perspective. I say this due to the very points brought up in Jonathans last sentence WRT configuring the NAT IP. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Monday, April 26, 2004 3:47 PM To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] More on new work item I'm not sure we should take on these work items. My concerns are mostly practical. I think we agree that DHCP applicability is only in very, very limited topologies - only in simple stub networks where an end user client would normally directly talk to a nat. This would really be limited to consumers with home nats, or to enterprises. I think its unlikely that an enterprise would actually allow end clients to control the nat, due to the serious potential for abuse (imagine a virus infecting a PC, causing it to ask the middlebox to open all ports to all addresses). As such, I dont think this is workable in enterprise. That leaves home NAT. However, do we think that manufacturers of such devices are likely to support midcom? I'd like to hear from one on this list. If not, this work item would be useful only in theory. Even if they did, how would we expect the clients to be configured with the security credentials needed to exercise midcom control over their nat? If such information is manually configured into the client, why can't you manually configure the IP of the home NAT as well? Thanks, Jonathan R. Melinda Shore wrote: > There's been no feedback on the proposed charter change, which concerns > me. I hope that people will speak up regardless of whether they think > the proposed work item is a good idea or a bad idea. > > I don't think getting the work done would be an issue - there are > always people willing to author documents. However, getting people > to *review* documents is far more difficult, and I don't think we can > allow work to go forward if we don't have a reasonable expectation > that people with subject area expertise - in this case, the midcom > working group - are willing to take the time to provide expert review > as the document is progressed. I don't want to make any assumptions > about what the lack of feedback means, so even a simple "yes" or "no" > on the proposed work item would be much appreciated. > > Thanks, > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 exim@www1.ietf.org Tue Apr 27 00:56:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19424 for ; Tue, 27 Apr 2004 00:56:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKcL-0004KC-FB for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 00:54:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R4sns0016601 for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 00:54:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKWj-0003lh-TT; Tue, 27 Apr 2004 00:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKUN-0003YP-MW for midcom@optimus.ietf.org; Tue, 27 Apr 2004 00:46:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19095 for ; Tue, 27 Apr 2004 00:46:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIKUL-0004yB-0M for midcom@ietf.org; Tue, 27 Apr 2004 00:46:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIKTN-0004pn-00 for midcom@ietf.org; Tue, 27 Apr 2004 00:45:34 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BIKSI-0004ZV-00 for midcom@ietf.org; Tue, 27 Apr 2004 00:44:26 -0400 Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3R4hwus018973; Tue, 27 Apr 2004 00:43:58 -0400 (EDT) Message-ID: <408DE4FD.1090209@dynamicsoft.com> Date: Tue, 27 Apr 2004 00:43:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris@sip1.com CC: "'Cullen Jennings'" , "'Yutaka Takeda'" , "'Midcom'" , stun@www.vovida.org Subject: Re: [midcom] Port preservation References: <008501c42bcd$11c94670$6402a8c0@HOME2> In-Reply-To: <008501c42bcd$11c94670$6402a8c0@HOME2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christopher A. Martin wrote: > Hi all, > The only reason that I can think of, that may be a good reason, is to > provide the appearance that a client is communicating directly with a > server on a standard server port (for that professional, I'm a big > organization look and feel). Some applications do check for this for > paranoid security reasons, but they are less common. For what application does the protocol expect the SOURCE port to be a standard server port? None that I can think of. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Apr 27 01:19:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20569 for ; Tue, 27 Apr 2004 01:19:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKw4-0007Jk-Ex for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 01:15:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R5FCTI028124 for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 01:15:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKoC-0005fi-QI; Tue, 27 Apr 2004 01:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKjq-0004nR-Rh for midcom@optimus.ietf.org; Tue, 27 Apr 2004 01:02:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19779 for ; Tue, 27 Apr 2004 01:02:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIKjn-00074m-Sy for midcom@ietf.org; Tue, 27 Apr 2004 01:02:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIKit-0006xX-00 for midcom@ietf.org; Tue, 27 Apr 2004 01:01:36 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by ietf-mx with esmtp (Exim 4.12) id 1BIKi9-0006j8-00 for midcom@ietf.org; Tue, 27 Apr 2004 01:00:50 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i3R663w9008333; Tue, 27 Apr 2004 01:06:03 -0500 Reply-To: From: "Christopher A. Martin" To: "'Jonathan Rosenberg'" Cc: "'Cullen Jennings'" , "'Yutaka Takeda'" , "'Midcom'" , Subject: RE: [midcom] Port preservation Date: Tue, 27 Apr 2004 00:00:05 -0500 Organization: SIP1 Information Services Message-ID: <000e01c42c14$81eedea0$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <408DE4FD.1090209@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan, This was merely an example. For clarity, common server ports in this example would be HTTP, SMTP, FTP, etc. This is a common enterprise deployment use for static translations that I was describing earlier. Most developers of well behaved protocols will implement the capability to listen on the same port they send on, or provide the capability to configure this. Firewall/NAT vendors typically provide the capability to configure the static IP/PORT NAT translations for these types of services, which is why I used this as a possible reason, to answer the question raised below. The use described is in no way definitive, but it does provide a practical use scenario that you will see quite often in the real world. The capability to perform this type of configuration is essential to providing secure access policies, a feature that I wish VoIP and other peer-to-peer protocol developers would have modeled (Some do, but the standard doesn't require this, which doesn't help security). Chris -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, April 26, 2004 11:44 PM To: Chris@sip1.com Cc: 'Cullen Jennings'; 'Yutaka Takeda'; 'Midcom'; stun@www.vovida.org Subject: Re: [midcom] Port preservation Christopher A. Martin wrote: > Hi all, > The only reason that I can think of, that may be a good reason, is to > provide the appearance that a client is communicating directly with a > server on a standard server port (for that professional, I'm a big > organization look and feel). Some applications do check for this for > paranoid security reasons, but they are less common. For what application does the protocol expect the SOURCE port to be a standard server port? None that I can think of. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Apr 27 01:20:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20656 for ; Tue, 27 Apr 2004 01:20:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKz8-0007uH-Ik for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 01:18:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R5IMjV030387 for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 01:18:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKr3-00069j-Ps; Tue, 27 Apr 2004 01:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIKnr-0005ac-83 for midcom@optimus.ietf.org; Tue, 27 Apr 2004 01:06:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19903 for ; Tue, 27 Apr 2004 01:06:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIKno-0007fe-DO for midcom@ietf.org; Tue, 27 Apr 2004 01:06:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIKmt-0007W7-00 for midcom@ietf.org; Tue, 27 Apr 2004 01:05:43 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by ietf-mx with esmtp (Exim 4.12) id 1BIKm8-0007FY-00 for midcom@ietf.org; Tue, 27 Apr 2004 01:04:56 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i3R68lw9008339; Tue, 27 Apr 2004 01:08:47 -0500 Reply-To: From: "Christopher A. Martin" To: "'Jonathan Rosenberg'" Cc: "'Cullen Jennings'" , "'Yutaka Takeda'" , "'Midcom'" , Subject: RE: [midcom] Port preservation Date: Tue, 27 Apr 2004 00:02:49 -0500 Organization: SIP1 Information Services Message-ID: <000f01c42c14$e3e10700$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <408DE4FD.1090209@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I was only providing an example, for the sake of answering a posted question, of why a static one-to-one port mapping might be desired in a NAT, not to justify why an application might expect a source port to be a standard server port. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Monday, April 26, 2004 11:44 PM To: Chris@sip1.com Cc: 'Cullen Jennings'; 'Yutaka Takeda'; 'Midcom'; stun@www.vovida.org Subject: Re: [midcom] Port preservation Christopher A. Martin wrote: > Hi all, > The only reason that I can think of, that may be a good reason, is to > provide the appearance that a client is communicating directly with a > server on a standard server port (for that professional, I'm a big > organization look and feel). Some applications do check for this for > paranoid security reasons, but they are less common. For what application does the protocol expect the SOURCE port to be a standard server port? None that I can think of. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 exim@www1.ietf.org Tue Apr 27 01:57:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22371 for ; Tue, 27 Apr 2004 01:57:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILWM-0004Pq-2i for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 01:52:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R5qgiT016953 for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 01:52:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILRp-0003q0-Ob; Tue, 27 Apr 2004 01:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILIx-0002Ne-Fd for midcom@optimus.ietf.org; Tue, 27 Apr 2004 01:38:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21496 for ; Tue, 27 Apr 2004 01:38:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BILIu-0004oa-BI for midcom@ietf.org; Tue, 27 Apr 2004 01:38:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BILI3-0004f5-00 for midcom@ietf.org; Tue, 27 Apr 2004 01:37:56 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BILHY-0004Ua-00 for midcom@ietf.org; Tue, 27 Apr 2004 01:37:24 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 21:49:45 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3R5aqW9003476; Mon, 26 Apr 2004 22:36:53 -0700 (PDT) Received: from [10.0.0.107] (rtp-vpn2-122.cisco.com [10.82.240.122]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOK93642; Mon, 26 Apr 2004 22:36:50 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 26 Apr 2004 19:36:49 -1000 Subject: Re: [midcom] Port preservation From: Cullen Jennings To: , Jonathan Rosenberg CC: "'Yutaka Takeda'" , Midcom , Message-ID: In-Reply-To: <000e01c42c14$81eedea0$6402a8c0@HOME2> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 4/26/04 7:00 PM, "Christopher A. Martin" wrote: > For clarity, common server ports in this example would be HTTP, SMTP, > FTP, etc. Well for TCP, the NATs don't muck with ports at all. The clients I have for HTTP, SMTP, FTP, also use source ports different than the destination ports so that the clients don't have to open a port under 1024 which would require them to be running as root. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Apr 27 02:09:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02517 for ; Tue, 27 Apr 2004 02:09:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILiS-0008FQ-5B for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 02:05:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R65CM0031677 for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 02:05:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILeQ-0005kG-Iv; Tue, 27 Apr 2004 02:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BILaL-0004ll-Dy for midcom@optimus.ietf.org; Tue, 27 Apr 2004 01:56:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22364 for ; Tue, 27 Apr 2004 01:56:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BILaI-0007fF-4R for midcom@ietf.org; Tue, 27 Apr 2004 01:56:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BILZN-0007Vv-00 for midcom@ietf.org; Tue, 27 Apr 2004 01:55:50 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BILYr-0007LC-00 for midcom@ietf.org; Tue, 27 Apr 2004 01:55:17 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 22:07:38 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3R5sk0Q024088; Mon, 26 Apr 2004 22:54:46 -0700 (PDT) Received: from [10.0.0.107] (rtp-vpn2-122.cisco.com [10.82.240.122]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOK94334; Mon, 26 Apr 2004 22:54:44 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 26 Apr 2004 19:54:43 -1000 Subject: Re: [stun] Re: [midcom] Port preservation From: Cullen Jennings To: Pyda Srisuresh , Yutaka Takeda , Midcom , Message-ID: In-Reply-To: <20040423230352.18703.qmail@web40409.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks for the concrete example of IKE. On 4/23/04 1:03 PM, "Pyda Srisuresh" wrote: > Port preservation is desirable in some limited cases where applications and > protocols require a certain number to be used for source and/or destination. > ex: IKE-v1 assumes UDP port 500 on both src and dest. > > cheers, > suresh > > --- Yutaka Takeda wrote: >> >> Does anyone know what the real motivation for NAT designers to >> implement the port preservation[1] is? Is there an actual service >> or application that depends on this behavior? I just realized that >> I know such NATs exist but why... >> >> [1] >> http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-00.txt >> >> Yutaka >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom > > > ===== > > _______________________________________________ > stun mailing list > stun@www.vovida.org > To unsubscribe, please go to http://www.vovida.org/mailman/listinfo/stun > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Apr 27 09:34:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00201 for ; Tue, 27 Apr 2004 09:34:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIScY-0001YK-LQ for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 09:27:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RDRYrt005945 for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 09:27:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISZ8-0000tH-5X; Tue, 27 Apr 2004 09:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISQP-0007uy-Ow for midcom@optimus.ietf.org; Tue, 27 Apr 2004 09:15:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29232 for ; Tue, 27 Apr 2004 09:14:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISQK-0003tv-Ap for midcom@ietf.org; Tue, 27 Apr 2004 09:14:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISPT-0003gp-00 for midcom@ietf.org; Tue, 27 Apr 2004 09:14:03 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by ietf-mx with esmtp (Exim 4.12) id 1BISOi-0003FK-00 for midcom@ietf.org; Tue, 27 Apr 2004 09:13:16 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i3REFIw9009469; Tue, 27 Apr 2004 09:15:18 -0500 Reply-To: From: "Christopher A. Martin" To: "'Cullen Jennings'" , "'Jonathan Rosenberg'" Cc: "'Yutaka Takeda'" , "'Midcom'" , Subject: RE: [midcom] Port preservation Date: Tue, 27 Apr 2004 08:09:17 -0500 Organization: SIP1 Information Services Message-ID: <004601c42c58$d9d95660$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ya, clients typically do use random ports, I am only speaking from a server standpoint (Enterprises don't typically static nat a client). :) Chris -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Tuesday, April 27, 2004 12:37 AM To: Chris@sip1.com; Jonathan Rosenberg Cc: 'Yutaka Takeda'; Midcom; stun@www.vovida.org Subject: Re: [midcom] Port preservation On 4/26/04 7:00 PM, "Christopher A. Martin" wrote: > For clarity, common server ports in this example would be HTTP, SMTP, > FTP, etc. Well for TCP, the NATs don't muck with ports at all. The clients I have for HTTP, SMTP, FTP, also use source ports different than the destination ports so that the clients don't have to open a port under 1024 which would require them to be running as root. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Apr 27 10:02:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01649 for ; Tue, 27 Apr 2004 10:02:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIT0w-0005lv-Qy for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 09:52:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RDqkv5022183 for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 09:52:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISvM-0004wc-Lq; Tue, 27 Apr 2004 09:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISqd-0003iL-4C for midcom@optimus.ietf.org; Tue, 27 Apr 2004 09:42:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00655 for ; Tue, 27 Apr 2004 09:42:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISqX-0000BN-C1 for midcom@ietf.org; Tue, 27 Apr 2004 09:42:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISpb-00009N-00 for midcom@ietf.org; Tue, 27 Apr 2004 09:41:04 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by ietf-mx with esmtp (Exim 4.12) id 1BISoz-00005d-00 for midcom@ietf.org; Tue, 27 Apr 2004 09:40:25 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i3REjhw9009534; Tue, 27 Apr 2004 09:45:43 -0500 Reply-To: From: "Christopher A. Martin" To: , "'Cullen Jennings'" , "'Jonathan Rosenberg'" Cc: "'Yutaka Takeda'" , "'Midcom'" , Subject: RE: [midcom] Port preservation Date: Tue, 27 Apr 2004 08:39:42 -0500 Organization: SIP1 Information Services Message-ID: <004e01c42c5d$191c4400$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <004601c42c58$d9d95660$6402a8c0@HOME2> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I guess I should also state the port that I am describing is a listening port (which is often also the source port) of the server being NATted, while I am at it. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Christopher A. Martin Sent: Tuesday, April 27, 2004 8:09 AM To: 'Cullen Jennings'; 'Jonathan Rosenberg' Cc: 'Yutaka Takeda'; 'Midcom'; stun@www.vovida.org Subject: RE: [midcom] Port preservation Ya, clients typically do use random ports, I am only speaking from a server standpoint (Enterprises don't typically static nat a client). :) Chris -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Tuesday, April 27, 2004 12:37 AM To: Chris@sip1.com; Jonathan Rosenberg Cc: 'Yutaka Takeda'; Midcom; stun@www.vovida.org Subject: Re: [midcom] Port preservation On 4/26/04 7:00 PM, "Christopher A. Martin" wrote: > For clarity, common server ports in this example would be HTTP, SMTP, > FTP, etc. Well for TCP, the NATs don't muck with ports at all. The clients I have for HTTP, SMTP, FTP, also use source ports different than the destination ports so that the clients don't have to open a port under 1024 which would require them to be running as root. _______________________________________________ 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 exim@www1.ietf.org Tue Apr 27 12:28:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10456 for ; Tue, 27 Apr 2004 12:28:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVMK-0000iF-07 for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 12:23:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RGMxQ9002734 for midcom-archive@odin.ietf.org; Tue, 27 Apr 2004 12:22:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV21-0003wT-Be; Tue, 27 Apr 2004 12:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUrI-0000nO-HH for midcom@optimus.ietf.org; Tue, 27 Apr 2004 11:50:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08419 for ; Tue, 27 Apr 2004 11:50:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUrE-0007LR-VE for midcom@ietf.org; Tue, 27 Apr 2004 11:50:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUqJ-0007J2-00 for midcom@ietf.org; Tue, 27 Apr 2004 11:49:55 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BIUpc-0007EL-00 for midcom@ietf.org; Tue, 27 Apr 2004 11:49:12 -0400 Received: from dynamicsoft.com ([63.113.46.158]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3RFmnus019250; Tue, 27 Apr 2004 11:48:49 -0400 (EDT) Message-ID: <408E80CF.5080909@dynamicsoft.com> Date: Tue, 27 Apr 2004 11:48:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris@sip1.com CC: "'Cullen Jennings'" , "'Yutaka Takeda'" , "'Midcom'" , stun@www.vovida.org Subject: Re: [midcom] Port preservation References: <004e01c42c5d$191c4400$6402a8c0@HOME2> In-Reply-To: <004e01c42c5d$191c4400$6402a8c0@HOME2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think you are confusing two things. One is a client behind a nat speaking to a server on the public side. There, I think there are very, very few cases where the source port means anything (IKE is the only identified one there). The other case is a server running behind the NAT (i.e., on the private side), which is what you are talking about below. In such a case, I think you would use port forwarding configuration on the nat, and so port preservation on dynamically created bindings isnt applicable. -Jonathan R. Christopher A. Martin wrote: > I guess I should also state the port that I am describing is a listening > port (which is often also the source port) of the server being NATted, > while I am at it. > > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of > Christopher A. Martin > Sent: Tuesday, April 27, 2004 8:09 AM > To: 'Cullen Jennings'; 'Jonathan Rosenberg' > Cc: 'Yutaka Takeda'; 'Midcom'; stun@www.vovida.org > Subject: RE: [midcom] Port preservation > > Ya, clients typically do use random ports, I am only speaking from a > server standpoint (Enterprises don't typically static nat a client). > > :) > > Chris > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, April 27, 2004 12:37 AM > To: Chris@sip1.com; Jonathan Rosenberg > Cc: 'Yutaka Takeda'; Midcom; stun@www.vovida.org > Subject: Re: [midcom] Port preservation > > On 4/26/04 7:00 PM, "Christopher A. Martin" wrote: > > >>For clarity, common server ports in this example would be HTTP, SMTP, >>FTP, etc. > > > Well for TCP, the NATs don't muck with ports at all. The clients I have > for > HTTP, SMTP, FTP, also use source ports different than the destination > ports > so that the clients don't have to open a port under 1024 which would > require > them to be running as root. > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Apr 28 00:08:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22670 for ; Wed, 28 Apr 2004 00:08:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIgKO-0007b8-D1 for midcom-archive@odin.ietf.org; Wed, 28 Apr 2004 00:05:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S45iiB029206 for midcom-archive@odin.ietf.org; Wed, 28 Apr 2004 00:05:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIgCE-0006MI-LG; Tue, 27 Apr 2004 23:57:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIg1t-0005Pc-Qe for midcom@optimus.ietf.org; Tue, 27 Apr 2004 23:46:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21816 for ; Tue, 27 Apr 2004 23:46:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIg1p-0007NN-JJ for midcom@ietf.org; Tue, 27 Apr 2004 23:46:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIg0q-0007Co-00 for midcom@ietf.org; Tue, 27 Apr 2004 23:45:33 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by ietf-mx with esmtp (Exim 4.12) id 1BIg0T-00072P-00 for midcom@ietf.org; Tue, 27 Apr 2004 23:45:09 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i3S4oYw9010942; Tue, 27 Apr 2004 23:50:34 -0500 Reply-To: From: "Christopher A. Martin" To: "'Jonathan Rosenberg'" Cc: "'Cullen Jennings'" , "'Yutaka Takeda'" , "'Midcom'" , Subject: RE: [midcom] Port preservation Date: Tue, 27 Apr 2004 22:44:28 -0500 Organization: SIP1 Information Services Message-ID: <00c901c42cd3$1c478fb0$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <408E80CF.5080909@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yep, I was only using an example where a static nat might be relevant, and it didn't include clients...it was a server example....I gave both a port and an ip translation example...for comparison purposes only. Chris -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, April 27, 2004 10:49 AM To: Chris@sip1.com Cc: 'Cullen Jennings'; 'Yutaka Takeda'; 'Midcom'; stun@www.vovida.org Subject: Re: [midcom] Port preservation I think you are confusing two things. One is a client behind a nat speaking to a server on the public side. There, I think there are very, very few cases where the source port means anything (IKE is the only identified one there). The other case is a server running behind the NAT (i.e., on the private side), which is what you are talking about below. In such a case, I think you would use port forwarding configuration on the nat, and so port preservation on dynamically created bindings isnt applicable. -Jonathan R. Christopher A. Martin wrote: > I guess I should also state the port that I am describing is a listening > port (which is often also the source port) of the server being NATted, > while I am at it. > > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of > Christopher A. Martin > Sent: Tuesday, April 27, 2004 8:09 AM > To: 'Cullen Jennings'; 'Jonathan Rosenberg' > Cc: 'Yutaka Takeda'; 'Midcom'; stun@www.vovida.org > Subject: RE: [midcom] Port preservation > > Ya, clients typically do use random ports, I am only speaking from a > server standpoint (Enterprises don't typically static nat a client). > > :) > > Chris > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, April 27, 2004 12:37 AM > To: Chris@sip1.com; Jonathan Rosenberg > Cc: 'Yutaka Takeda'; Midcom; stun@www.vovida.org > Subject: Re: [midcom] Port preservation > > On 4/26/04 7:00 PM, "Christopher A. Martin" wrote: > > >>For clarity, common server ports in this example would be HTTP, SMTP, >>FTP, etc. > > > Well for TCP, the NATs don't muck with ports at all. The clients I have > for > HTTP, SMTP, FTP, also use source ports different than the destination > ports > so that the clients don't have to open a port under 1024 which would > require > them to be running as root. > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Apr 28 00:09:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22691 for ; Wed, 28 Apr 2004 00:09:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIgKx-0007hU-NO for midcom-archive@odin.ietf.org; Wed, 28 Apr 2004 00:06:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S46Jxn029590 for midcom-archive@odin.ietf.org; Wed, 28 Apr 2004 00:06:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIgCG-0006Mo-BK; Tue, 27 Apr 2004 23:57:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIg3m-0005ah-Q9 for midcom@optimus.ietf.org; Tue, 27 Apr 2004 23:48:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21927 for ; Tue, 27 Apr 2004 23:48:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIg3i-0007jE-Hg for midcom@ietf.org; Tue, 27 Apr 2004 23:48:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIg2n-0007YT-00 for midcom@ietf.org; Tue, 27 Apr 2004 23:47:33 -0400 Received: from adsl-64-219-190-5.dsl.rcsntx.swbell.net ([64.219.190.5] helo=voyager.sip1.com) by ietf-mx with esmtp (Exim 4.12) id 1BIg1s-0007DC-00 for midcom@ietf.org; Tue, 27 Apr 2004 23:46:36 -0400 Received: from HOME2 (adsl-64-219-190-1.dsl.rcsntx.swbell.net [64.219.190.1]) by voyager.sip1.com (8.12.8/8.12.8) with ESMTP id i3S4q3w9010946; Tue, 27 Apr 2004 23:52:03 -0500 Reply-To: From: "Christopher A. Martin" To: "'Jonathan Rosenberg'" Cc: "'Cullen Jennings'" , "'Yutaka Takeda'" , "'Midcom'" , Subject: RE: [midcom] Port preservation Date: Tue, 27 Apr 2004 22:45:57 -0500 Organization: SIP1 Information Services Message-ID: <00ca01c42cd3$50fb8900$6402a8c0@HOME2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <408E80CF.5080909@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I was offering another example, IKE is also an example... This isn't hard...someone asked why the solution might be used, there are a dozen reasons why, servers, ike are common ones... Why dig so hard here...???? There is no confusion, just offered another example... -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, April 27, 2004 10:49 AM To: Chris@sip1.com Cc: 'Cullen Jennings'; 'Yutaka Takeda'; 'Midcom'; stun@www.vovida.org Subject: Re: [midcom] Port preservation I think you are confusing two things. One is a client behind a nat speaking to a server on the public side. There, I think there are very, very few cases where the source port means anything (IKE is the only identified one there). The other case is a server running behind the NAT (i.e., on the private side), which is what you are talking about below. In such a case, I think you would use port forwarding configuration on the nat, and so port preservation on dynamically created bindings isnt applicable. -Jonathan R. Christopher A. Martin wrote: > I guess I should also state the port that I am describing is a listening > port (which is often also the source port) of the server being NATted, > while I am at it. > > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of > Christopher A. Martin > Sent: Tuesday, April 27, 2004 8:09 AM > To: 'Cullen Jennings'; 'Jonathan Rosenberg' > Cc: 'Yutaka Takeda'; 'Midcom'; stun@www.vovida.org > Subject: RE: [midcom] Port preservation > > Ya, clients typically do use random ports, I am only speaking from a > server standpoint (Enterprises don't typically static nat a client). > > :) > > Chris > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, April 27, 2004 12:37 AM > To: Chris@sip1.com; Jonathan Rosenberg > Cc: 'Yutaka Takeda'; Midcom; stun@www.vovida.org > Subject: Re: [midcom] Port preservation > > On 4/26/04 7:00 PM, "Christopher A. Martin" wrote: > > >>For clarity, common server ports in this example would be HTTP, SMTP, >>FTP, etc. > > > Well for TCP, the NATs don't muck with ports at all. The clients I have > for > HTTP, SMTP, FTP, also use source ports different than the destination > ports > so that the clients don't have to open a port under 1024 which would > require > them to be running as root. > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Apr 28 20:23:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06791 for ; Wed, 28 Apr 2004 20:23:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzBl-0006r1-30 for midcom-archive@odin.ietf.org; Wed, 28 Apr 2004 20:14:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T0E5Je026326 for midcom-archive@odin.ietf.org; Wed, 28 Apr 2004 20:14:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIz5t-0005Vx-VS; Wed, 28 Apr 2004 20:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyzf-0003AX-BH for midcom@optimus.ietf.org; Wed, 28 Apr 2004 20:01:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05700 for ; Wed, 28 Apr 2004 20:01:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyzc-00073d-5d for midcom@ietf.org; Wed, 28 Apr 2004 20:01:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyyd-0006wK-00 for midcom@ietf.org; Wed, 28 Apr 2004 20:00:31 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIyxd-0006nV-00 for midcom@ietf.org; Wed, 28 Apr 2004 19:59:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Apr 2004 16:12:11 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3SNwpSu023805 for ; Wed, 28 Apr 2004 16:58:55 -0700 (PDT) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with SMTP id ATM87702; Wed, 28 Apr 2004 16:58:47 -0700 (PDT) Date: Wed, 28 Apr 2004 19:58:44 -0400 Subject: Re: [midcom] More on new work item Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <408D754C.5080708@dynamicsoft.com> Message-Id: X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Here's what I'd like to do: Jonathan raised some good questions. I'm not sure I agree with some of his assumptions, but the question remains: is there an expectation that someone would actually want to use DHCP to configure middlebox addresses into endpoints, or is this an apparently reasonable idea that won't be used in practice? If we can't foresee a reasonable expectation that the work would have real-world utility we should probably let it drop, and do so quickly. If we do think the work is useful we should move it along as rapidly as would be reasonable. The main thing is that I'd like to avoid dinking around with this, and I hope we can reach resolution quickly. So, if anybody wants to argue in favor of the applicability of the work, now's the time. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Apr 28 21:06:46 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08520 for ; Wed, 28 Apr 2004 21:06:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzwt-00085w-8R for midcom-archive@odin.ietf.org; Wed, 28 Apr 2004 21:02:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T12ltE031103 for midcom-archive@odin.ietf.org; Wed, 28 Apr 2004 21:02:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzpP-0006Tl-CG; Wed, 28 Apr 2004 20:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIzcP-0004So-5M for midcom@optimus.ietf.org; Wed, 28 Apr 2004 20:41:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07673 for ; Wed, 28 Apr 2004 20:41:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIzcL-0002yi-HE for midcom@ietf.org; Wed, 28 Apr 2004 20:41:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIzbM-0002sa-00 for midcom@ietf.org; Wed, 28 Apr 2004 20:40:33 -0400 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 1BIzaO-0002jM-00 for midcom@ietf.org; Wed, 28 Apr 2004 20:39:32 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] Port preservation x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 28 Apr 2004 17:39:00 -0700 Message-ID: Thread-Topic: [midcom] Port preservation Thread-Index: AcQrvwiDW/KQ05mdSoyi86NZv+0RigBuhJDQ From: "Yutaka Takeda" To: "Cullen Jennings" , "Midcom" , , "Pyda Srisuresh" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks everyone for the comments. After reading the comments and observing the actual NATs behavior, and considering the amount of deployment of NATs that operates port=20 preservation, my conclusion is that there is no solid and practical situation where the port preservation (on dynamically created=20 bindings, not the static port mapping) is 'desired' in the real network environment. IKE-v1 might get a benefit from the port preservation behavior (thanks to Suresh for letting me know), however, since majority of NATs do=20 not preserve the port number, I believe network admins do not depend=20 on this behavior, or they do not even know about port preservation. For NAT developers, they might feel like picking the same port number for a new binding if available rather than generating a=20 different one, might be considering retaining a 'service' associated to the port number at best but not knowing how an application=20 would use it. This seems to be convincing me why we have it today. Thanks, Yutaka > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, April 26, 2004 1:41 PM > To: Yutaka Takeda; Midcom; stun@www.vovida.org > Subject: Re: [midcom] Port preservation >=20 >=20 >=20 > There may be many but the two reasons I have heard are below=20 > - neither of > which make much sense to me. >=20 > Makes debugging easier by not switching the port traffic is=20 > on. This allows > network sniffers and such guess the type of traffic from the port. > (Personally I find this argument a little hard to buy given=20 > it is the source > port that is being preserved and using ports for traffic type=20 > determination > is usually based on the destination port) >=20 > Higher odds of interoperability for protocols. The argument=20 > goes that A > sends though a NAT to B. B may reply expecting to go to a certain port > number so if that does not change life will be better. I=20 > suspect that most > applications that reply to the correct IP, are likely to also=20 > reply to port > the packet came from but who knows. >=20 > The most common answer I get to this questions and the one=20 > that seems most > believable ... "Because vendor X's NAT worked that way so we=20 > made ours do > the same" >=20 > I don't know - it is a good questions. Can others provide any=20 > insight into > this? >=20 >=20 >=20 > On 4/23/04 11:19 AM, "Yutaka Takeda" wrote: >=20 > >=20 > > Does anyone know what the real motivation for NAT designers to > > implement the port preservation[1] is? Is there an actual service > > or application that depends on this behavior? I just realized that > > I know such NATs exist but why... > >=20 > > [1]=20 > >=20 http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-00= .txt >=20 > Yutaka >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Apr 29 11:47:01 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10080 for ; Thu, 29 Apr 2004 11:47:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDaG-00013l-HG for midcom-archive@odin.ietf.org; Thu, 29 Apr 2004 11:36:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TFaKvN004073 for midcom-archive@odin.ietf.org; Thu, 29 Apr 2004 11:36:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDMU-00062u-JZ; Thu, 29 Apr 2004 11:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDEQ-00045a-UA for midcom@optimus.ietf.org; Thu, 29 Apr 2004 11:13:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08468 for ; Thu, 29 Apr 2004 11:13:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDEM-00033z-Pd for midcom@ietf.org; Thu, 29 Apr 2004 11:13:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDDM-0002mL-00 for midcom@ietf.org; Thu, 29 Apr 2004 11:12:41 -0400 Received: from smtpi1.usherbrooke.ca ([132.210.244.92]) by ietf-mx with esmtp (Exim 4.12) id 1BJDCa-0002RX-00 for midcom@ietf.org; Thu, 29 Apr 2004 11:11:52 -0400 Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178]) by smtpi1.usherbrooke.ca (8.12.10/8.12.10) with ESMTP id i3TF5b8R012587; Thu, 29 Apr 2004 11:05:37 -0400 From: "Joel Tran" To: "'Jonathan Rosenberg'" , "'Melinda Shore'" Cc: Subject: RE : [midcom] More on new work item Date: Thu, 29 Apr 2004 11:05:21 -0400 Message-ID: <000601c42dfb$648eae10$b248d284@kamel> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <408D754C.5080708@dynamicsoft.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-UdeS-i-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-i-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: joel.tran@usherbrooke.ca X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Jonathan Rosenberg, you raised a good point. There are however some ISPs that are deploying NAT/Firewall (i.e. China, Europe, Africa). In such case, DHCP might be useful. The ISP might do some load balancing. Thus, DHCP method will provide a mean for the ISP to configure dynamically third-end party devices. As for the security information, this might be entered by the user to the third-end party device (ex: same id/password as for the ADSL authentication). ...J > -----Message d'origine----- > De : midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] De > la part de Jonathan Rosenberg > Envoyé : 26 avril, 2004 16:47 > À : Melinda Shore > Cc : midcom@ietf.org > Objet : Re: [midcom] More on new work item > > > I'm not sure we should take on these work items. My concerns > are mostly > practical. > > I think we agree that DHCP applicability is only in very, > very limited > topologies - only in simple stub networks where an end user > client would > normally directly talk to a nat. This would really be limited to > consumers with home nats, or to enterprises. I think its > unlikely that > an enterprise would actually allow end clients to control the > nat, due > to the serious potential for abuse (imagine a virus infecting a PC, > causing it to ask the middlebox to open all ports to all > addresses). As > such, I dont think this is workable in enterprise. > > That leaves home NAT. However, do we think that manufacturers of such > devices are likely to support midcom? I'd like to hear from > one on this > list. If not, this work item would be useful only in theory. Even if > they did, how would we expect the clients to be configured with the > security credentials needed to exercise midcom control over > their nat? > If such information is manually configured into the client, why can't > you manually configure the IP of the home NAT as well? > > Thanks, > Jonathan R. > > Melinda Shore wrote: > > > There's been no feedback on the proposed charter change, which > > concerns me. I hope that people will speak up regardless > of whether > > they think the proposed work item is a good idea or a bad idea. > > > > I don't think getting the work done would be an issue - there are > > always people willing to author documents. However, > getting people to > > *review* documents is far more difficult, and I don't think we can > > allow work to go forward if we don't have a reasonable expectation > > that people with subject area expertise - in this case, the midcom > > working group - are willing to take the time to provide > expert review > > as the document is progressed. I don't want to make any > assumptions > > about what the lack of feedback means, so even a simple > "yes" or "no" > > on the proposed work item would be much appreciated. > > > > Thanks, > > > > Melinda > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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 exim@www1.ietf.org Thu Apr 29 18:14:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06777 for ; Thu, 29 Apr 2004 18:14:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJkT-0008Ts-Nw for midcom-archive@odin.ietf.org; Thu, 29 Apr 2004 18:11:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TMBHTZ032579 for midcom-archive@odin.ietf.org; Thu, 29 Apr 2004 18:11:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJgL-0005sp-In; Thu, 29 Apr 2004 18:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJX8-0000ti-17 for midcom@optimus.ietf.org; Thu, 29 Apr 2004 17:57:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04748 for ; Thu, 29 Apr 2004 17:57:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJJX0-0001cR-6q for midcom@ietf.org; Thu, 29 Apr 2004 17:57:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJW2-0001aP-00 for midcom@ietf.org; Thu, 29 Apr 2004 17:56:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJJVB-0001Xa-00 for midcom@ietf.org; Thu, 29 Apr 2004 17:55:30 -0400 Received: from dynamicsoft.com ([63.113.46.97]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3TLsGus021058; Thu, 29 Apr 2004 17:54:17 -0400 (EDT) Message-ID: <40917970.4050604@dynamicsoft.com> Date: Thu, 29 Apr 2004 17:53:52 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Tran CC: "'Melinda Shore'" , midcom@ietf.org Subject: Re: RE : [midcom] More on new work item References: <000601c42dfb$648eae10$b248d284@kamel> In-Reply-To: <000601c42dfb$648eae10$b248d284@kamel> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Joel Tran wrote: > Jonathan Rosenberg, you raised a good point. > > There are however some ISPs that are deploying NAT/Firewall (i.e. China, > Europe, Africa). In such case, DHCP might be useful. The ISP might do some > load balancing. Thus, DHCP method will provide a mean for the ISP to > configure dynamically third-end party devices. As for the security > information, this might be entered by the user to the third-end party device > (ex: same id/password as for the ADSL authentication). There is a serious trust issue here. Is the ISP really going to issue a username and password to every user of their network, entrusting them with permissions to use midcom to manage port bindings on their network wide NAT?? I certainly hope not. Thats an open invitation for substantial denial of service attacks. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Apr 30 11:20:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07829 for ; Fri, 30 Apr 2004 11:20:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZXW-0005d2-8g for midcom-archive@odin.ietf.org; Fri, 30 Apr 2004 11:02:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UF2wWf021637 for midcom-archive@odin.ietf.org; Fri, 30 Apr 2004 11:02:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZNw-0003ad-IG; Fri, 30 Apr 2004 10:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZD5-0001hV-VW for midcom@optimus.ietf.org; Fri, 30 Apr 2004 10:41:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05197 for ; Fri, 30 Apr 2004 10:41:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZD3-00061R-JV for midcom@ietf.org; Fri, 30 Apr 2004 10:41:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZC5-0005uK-00 for midcom@ietf.org; Fri, 30 Apr 2004 10:40:49 -0400 Received: from smtpi1.usherbrooke.ca ([132.210.244.92]) by ietf-mx with esmtp (Exim 4.12) id 1BJZAt-0005iv-00 for midcom@ietf.org; Fri, 30 Apr 2004 10:39:35 -0400 Received: from www03.usherbrooke.ca (www03.USherbrooke.ca [132.210.244.10]) by smtpi1.usherbrooke.ca (8.12.10/8.12.10) with ESMTP id i3UEcNTx024230; Fri, 30 Apr 2004 10:38:23 -0400 Received: (from apache@localhost) by www03.usherbrooke.ca (8.11.6/8.11.6) id i3UEcKx20647; Fri, 30 Apr 2004 10:38:20 -0400 Received: from cherkaoui4.gel.usherb.ca (cherkaoui4.gel.usherb.ca [132.210.72.39]) by www.usherbrooke.ca (IMP) with HTTP for ; Fri, 30 Apr 2004 10:38:20 -0400 Message-ID: <1083335900.409264dc864e3@www.usherbrooke.ca> Date: Fri, 30 Apr 2004 10:38:20 -0400 From: Joel Tran To: Jonathan Rosenberg Cc: "'Melinda Shore'" , midcom@ietf.org Subject: Re: RE : [midcom] More on new work item References: <000601c42dfb$648eae10$b248d284@kamel> <40917970.4050604@dynamicsoft.com> In-Reply-To: <40917970.4050604@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 132.210.72.39 X-UdeS-i-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-i-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: joel.tran@usherbrooke.ca X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Selon Jonathan Rosenberg : > > > Joel Tran wrote: > > > Jonathan Rosenberg, you raised a good point. > > > > There are however some ISPs that are deploying NAT/Firewall (i.e. China, > > Europe, Africa). In such case, DHCP might be useful. The ISP might do > some > > load balancing. Thus, DHCP method will provide a mean for the ISP to > > configure dynamically third-end party devices. As for the security > > information, this might be entered by the user to the third-end party > device > > (ex: same id/password as for the ADSL authentication). > > There is a serious trust issue here. Is the ISP really going to issue a > username and password to every user of their network, entrusting them > with permissions to use midcom to manage port bindings on their network > wide NAT?? I certainly hope not. Thats an open invitation for > substantial denial of service attacks. > > -Jonathan R. Correct me if I'm wrong. I don't think it is an open invitation for DOS attack if there is a proper Access Control List/Policy Rule in the Midcom device which may limit the use of the port bindings for each user. ...J _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Apr 30 12:22:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12433 for ; Fri, 30 Apr 2004 12:22:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaTF-0008OZ-7i for midcom-archive@odin.ietf.org; Fri, 30 Apr 2004 12:02:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UG2bn9032272 for midcom-archive@odin.ietf.org; Fri, 30 Apr 2004 12:02:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaLy-0007Az-Mt; Fri, 30 Apr 2004 11:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaCR-0005VP-At for midcom@optimus.ietf.org; Fri, 30 Apr 2004 11:45:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10171 for ; Fri, 30 Apr 2004 11:45:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJaCQ-00032e-5u for midcom@ietf.org; Fri, 30 Apr 2004 11:45:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaBW-0002zp-00 for midcom@ietf.org; Fri, 30 Apr 2004 11:44:19 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BJaAz-0002w9-00 for midcom@ietf.org; Fri, 30 Apr 2004 11:43:45 -0400 Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i3UFgkus021582; Fri, 30 Apr 2004 11:42:47 -0400 (EDT) Message-ID: <409273DB.3000007@dynamicsoft.com> Date: Fri, 30 Apr 2004 11:42:19 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Tran CC: "'Melinda Shore'" , midcom@ietf.org Subject: Re: RE : [midcom] More on new work item References: <000601c42dfb$648eae10$b248d284@kamel> <40917970.4050604@dynamicsoft.com> <1083335900.409264dc864e3@www.usherbrooke.ca> In-Reply-To: <1083335900.409264dc864e3@www.usherbrooke.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Joel Tran wrote: >>There is a serious trust issue here. Is the ISP really going to issue a >>username and password to every user of their network, entrusting them >>with permissions to use midcom to manage port bindings on their network >>wide NAT?? I certainly hope not. Thats an open invitation for >>substantial denial of service attacks. >> >>-Jonathan R. > > > Correct me if I'm wrong. I don't think it is an open invitation for DOS attack > if there is a proper Access Control List/Policy Rule in the Midcom device which > may limit the use of the port bindings for each user. I don't think this can work easily. How would the ACL be structured? Presumably, you'd want to say something like, "user joe is allowed to open up pinholes directed to his currently allocated IP address". There are several major problems here: * if there is any other NAT intervening the user and the ISP's nat (very common here in the US at least, due to residential NAT devices like those made by linksys), this of course won't help even if you work out the ACL issues * assuming no other nats between the user and the ISP NAT, there is a correlation that needs to be made somewhere between the username/password and the IP address thats allocated to them. This would require some really convoluted coupling between DHCP (which can tell you the MAC/IP binding) and customer provisioning systems (which *might* be able to tell you the MAC used by a customers cable modem) and the ISP firewall, to make sure that a user can only make changes for their own IP. This seems pretty complicated to me. * Its also not clear to me that there aren't security holes in the whole thing that might enable someone to learn the passwords and usernames needed to control bindings for other IP addresses. * I dont know whether the MIBs include sufficient ACLs for the above to work (have not looked) IMHO, the topological issues with midcom, which we have long been aware of, combined with the CONTROL nature of the relationship between the agent and the client, really point to applicability limited to a trusted device that controls a neighboring firewall or NAT, thus useful for carrier edge or large enterprise edge applications. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Apr 30 13:23:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16126 for ; Fri, 30 Apr 2004 13:23:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbez-00082V-J5 for midcom-archive@odin.ietf.org; Fri, 30 Apr 2004 13:18:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UHIncY030903 for midcom-archive@odin.ietf.org; Fri, 30 Apr 2004 13:18:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbXS-0006et-GU; Fri, 30 Apr 2004 13:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbN0-0004Kp-2B for midcom@optimus.ietf.org; Fri, 30 Apr 2004 13:00:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14553 for ; Fri, 30 Apr 2004 13:00:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbMy-0000b4-9L for midcom@ietf.org; Fri, 30 Apr 2004 13:00:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbM4-0000VE-00 for midcom@ietf.org; Fri, 30 Apr 2004 12:59:17 -0400 Received: from smtp.usherbrooke.ca ([132.210.244.17] helo=courrier3.usherbrooke.ca) by ietf-mx with esmtp (Exim 4.12) id 1BJbL9-0000Np-00 for midcom@ietf.org; Fri, 30 Apr 2004 12:58:19 -0400 Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178]) by courrier3.usherbrooke.ca (8.11.6/8.11.6) with ESMTP id i3UGvbg26673; Fri, 30 Apr 2004 12:57:37 -0400 From: "Joel Tran" To: Cc: , "'Melinda Shore'" Subject: Re: RE : [midcom] More on new work item Date: Fri, 30 Apr 2004 12:57:07 -0400 Message-ID: <000701c42ed4$2ec76360$b248d284@kamel> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: joel.tran@usherbrooke.ca X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > -----Message d'origine----- > De : Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Envoyé : 30 avril, 2004 11:42 > À : Joel Tran > Cc : 'Melinda Shore'; midcom@ietf.org > Objet : Re: RE : [midcom] More on new work item > > > > > Joel Tran wrote: > > > >>There is a serious trust issue here. Is the ISP really > going to issue > >>a > >>username and password to every user of their network, > entrusting them > >>with permissions to use midcom to manage port bindings on > their network > >>wide NAT?? I certainly hope not. Thats an open invitation for > >>substantial denial of service attacks. > >> > >>-Jonathan R. > > > > > > Correct me if I'm wrong. I don't think it is an open invitation for > > DOS attack > > if there is a proper Access Control List/Policy Rule in the > Midcom device which > > may limit the use of the port bindings for each user. > > I don't think this can work easily. > > How would the ACL be structured? Presumably, you'd want to > say something > like, "user joe is allowed to open up pinholes directed to > his currently > allocated IP address". There are several major problems here: Yes I ment something like this. Something like the 1st Tuple of the Midcom entry has to be the IP adresse of the client/IP address from where the message is originating. > > * if there is any other NAT intervening the user and the > ISP's nat (very > common here in the US at least, due to residential NAT devices like > those made by linksys), this of course won't help even if you > work out > the ACL issues Yes traversing the home NAT is a problem. Just a quick question, is there a solution avaible for traversing both home and ISP NAT (excluding relaying) when two peers are under such topology? If yes, we could probably learn form them how they solve the situtation. > * assuming no other nats between the user and the ISP NAT, there is a > correlation that needs to be made somewhere between the > username/password and the IP address thats allocated to them. > This would > require some really convoluted coupling between DHCP (which > can tell you > the MAC/IP binding) and customer provisioning systems (which > *might* be > able to tell you the MAC used by a customers cable modem) and the ISP > firewall, to make sure that a user can only make changes for > their own > IP. This seems pretty complicated to me. I don't think we require a big correlation (User/PWD/IP) in order to provide a security mechanism. For example, the rules can be : 1 - Pinholes can only be created for the source address. 2 - User joe can only create 10 pinholes or IP source can only create 10 pinholes. 3 - ... > * Its also not clear to me that there aren't security holes > in the whole > thing that might enable someone to learn the passwords and usernames > needed to control bindings for other IP addresses. I'm not an SNMPv3 expert but I think that the security mechanism (USM/encryption) provided by SNMPv3 is strong enough so that it will be hard for someone to break trough and discover the user name/password or try to get unrestricted access. > * I dont know whether the MIBs include sufficient ACLs for > the above to > work (have not looked) In my understanding (from the mailing list), Midcom MIB document is not finished yet. Probably we will have to wait to see if the MIB will have sufficient ACLs. > IMHO, the topological issues with midcom, which we have long > been aware > of, combined with the CONTROL nature of the relationship between the > agent and the client, really point to applicability limited > to a trusted > device that controls a neighboring firewall or NAT, thus useful for > carrier edge or large enterprise edge applications. In general, I do agree with you. However, in this case I was only trying to find a solution in order to provide a full peer to peer solution (not only for SIP where a server can be the trusted control certer) for various kind of topology. ...J _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Apr 30 13:57:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18295 for ; Fri, 30 Apr 2004 13:57:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcF6-0005E9-40 for midcom-archive@odin.ietf.org; Fri, 30 Apr 2004 13:56:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UHu7f1019988 for midcom-archive@odin.ietf.org; Fri, 30 Apr 2004 13:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJc3M-0003uf-SU; Fri, 30 Apr 2004 13:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbxj-0002mu-43 for midcom@optimus.ietf.org; Fri, 30 Apr 2004 13:38:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17485 for ; Fri, 30 Apr 2004 13:38:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbxg-0003gW-Ra for midcom@ietf.org; Fri, 30 Apr 2004 13:38:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbwn-0003dv-00 for midcom@ietf.org; Fri, 30 Apr 2004 13:37:14 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJbwS-0003aq-00 for midcom@ietf.org; Fri, 30 Apr 2004 13:36:52 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2004 09:48:40 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3UHaKW9027397; Fri, 30 Apr 2004 10:36:20 -0700 (PDT) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with SMTP id ATO81431; Fri, 30 Apr 2004 10:36:18 -0700 (PDT) Date: Fri, 30 Apr 2004 13:36:15 -0400 Subject: Re: RE : [midcom] More on new work item Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: Joel Tran , midcom@ietf.org To: Jonathan Rosenberg From: Melinda Shore In-Reply-To: <409273DB.3000007@dynamicsoft.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday, April 30, 2004, at 11:42 AM, Jonathan Rosenberg wrote: > IMHO, the topological issues with midcom, which we have long been > aware of, combined with the CONTROL nature of the relationship between > the agent and the client, really point to applicability limited to a > trusted device that controls a neighboring firewall or NAT, thus > useful for carrier edge or large enterprise edge applications. I think incrementalism in design (not in deployment) is causing some problems here. Network administrators, and a growing number of people in the industry, are increasingly aware that the current model for mediating access isn't very effective (and that ties quite directly to the question of what the trust bases are). That means a couple of things, including that there are now at least two models for provisioning trust: 1) profile, and 2) credentials. In the former case a "profile" might mean something like "is running version whatever of anti-virus software blah". "Credentials" is obvious and is more directly relevant to what we're talking about. It's a shame that the distributed firewalls stuff never took off, because that, at least, could provide a workable framework for talking about endpoint trust and access issues. I think we're being a bit short-sighted but I'm not sure I see a way to avoid that under the circumstances. It may be sufficient to allow industry to drive this one and bring work to the IETF when it's already mature. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom