From daemon@optimus.ietf.org Mon Jul 1 14:17:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23711 for ; Mon, 1 Jul 2002 14:17:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27298 for midcom-archive@odin.ietf.org; Mon, 1 Jul 2002 14:18:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27037; Mon, 1 Jul 2002 14:14:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26994 for ; Mon, 1 Jul 2002 14:14:16 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23511 for ; Mon, 1 Jul 2002 14:13:26 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g61IDuH09491 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 1 Jul 2002 11:13:56 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g61IDrj12717 for ; Mon, 1 Jul 2002 11:13:53 -0700 (PDT) To: midcom@ietf.org Date: Mon, 1 Jul 2002 13:13:22 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] FWD: I-D ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org All, Sorry for the delay in noticing this. This I-D was supposed to be announced to the midcom mailing list as well as the general ietf-announce mailing list, but it wasn't. Note that this I-D recommends that the midcom protocol requirements be extended to require support in the midcom protocol for tunnels between hosts and middleboxes. It's not that the use of tunnels would be required, but that they would be supported by midcom if used. In our experience, using tunnels is an extremely attractive alternative to modifying applications or creating ALGs or agents to allow existing applications to work correctly with NAT boxes. The I-D also shows how traditional NAT can be supported in a host as a tunnel would, and thus accrue the advantages of tunnels: no changes to applications; no need for ALG or agent. The NAT function in the middlebox remains unchanged, but a midcom server would need to be added to the middlebox. But we were planning on doing that anyhow. :-) Comments welcome and expected. Jim ---------------------- Forwarded by James Renkel/MW/US/3Com on 07/01/2002 01:02 PM --------------------------- Internet-Drafts@ietf.org@cnri.reston.va.us on 06/21/2002 06:37:01 AM Please respond to Internet-Drafts@ietf.org Sent by: nsyracus@cnri.reston.va.us To: IETF-Announce: ; cc: Subject: I-D ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT and Middlebox Tunnels Author(s) : J. Renkel Filename : draft-renkel-middlebox-tunnels-00.txt,.ps Pages : 12 Date : 20-Jun-02 This Internet Draft compares Network Address Translation (NAT) and Realm Specific IP (RSIP) tunnels, and the advantages and disadvantages of each. It then shows how the advantages can be combined by implementing NAT as a tunnel in hosts, while minimizing the disadvantages. Based on the advantages of middlebox tunnels in general and implementing NAT as a middlebox tunnel in particular, it then recommends that the Middlebox Communications architecture protocol (MIDCOM) be amended to support tunnels between hosts and middleboxes. This .txt version of this internet draft is identical to the PostScript version (draft-renkel-middlebox-tunnels-00.ps) except that the figures from the PostScript version have been deleted. Please refer to the PostScript version for these figures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-renkel-middlebox-tunnels-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-renkel-middlebox-tunnels-00.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-renkel-middlebox-tunnels-00.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. mailto:mailserv@ietf.org ftp://ftp.ietf.org/internet-drafts/draft-renkel-middlebox-tunnels-00.txt _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jul 1 15:18:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27623 for ; Mon, 1 Jul 2002 15:18:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03676 for midcom-archive@odin.ietf.org; Mon, 1 Jul 2002 15:19:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03454; Mon, 1 Jul 2002 15:16:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03421 for ; Mon, 1 Jul 2002 15:16:21 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27453 for ; Mon, 1 Jul 2002 15:15:32 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g61JGJ226554; Mon, 1 Jul 2002 15:16:19 -0400 (EDT) Message-Id: <200207011916.g61JGJ226554@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: James_Renkel@3com.com cc: midcom@ietf.org Subject: Re: [midcom] FWD: I-D ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps In-reply-to: (Your message of "Mon, 01 Jul 2002 13:13:22 CDT.") Date: Mon, 01 Jul 2002 15:16:19 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org The idea that tunnels can solve the NAT problem without changes to applications is critically flawed - the technique only works if the application somehow has a tunnel to a location in the network that is simultaneously accessible by all of that application's peers, and if the application knows to use the interface/address associated with that tunnel in preference to all other interface/address pairs available to it. It's certainly better than nothing, and probably better than other things that Midcom has produced. but it's not a general solution. Keith _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jul 1 15:48:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29259 for ; Mon, 1 Jul 2002 15:48:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06611 for midcom-archive@odin.ietf.org; Mon, 1 Jul 2002 15:48:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06300; Mon, 1 Jul 2002 15:46:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06261 for ; Mon, 1 Jul 2002 15:46:44 -0400 (EDT) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29160 for ; Mon, 1 Jul 2002 15:45:57 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837) id <0GYL00D015IS2M@firewall.wcom.com> for midcom@ietf.org; Mon, 1 Jul 2002 19:44:52 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GYL00C655IRD8@firewall.wcom.com>; Mon, 01 Jul 2002 19:44:52 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0GYL00A015ICO2@dgismtp04.wcomnet.com>; Mon, 01 Jul 2002 19:44:51 +0000 (GMT) Received: from rccc6131 ([166.35.225.32]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0GYL00A405GK6H@dgismtp04.wcomnet.com>; Mon, 01 Jul 2002 19:43:33 +0000 (GMT) Date: Mon, 01 Jul 2002 14:43:29 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] FWD: I-D ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps In-reply-to: <200207011916.g61JGJ226554@astro.cs.utk.edu> To: "'Keith Moore'" , James_Renkel@3com.com Cc: midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <001301c22137$93dac0a0$20e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Tunneling also limitted to non-overlapping address space generally (at the midcom side of the tunnel), and is not easily scaled....for multiple overlapping address space even if individual MIDCOM solutions are implemented to address this shortcoming...unless NAT or proxying is implemented at the MIDCOM end to address this which means that we move the problem closer to the agregate end. I am rambling again... lets see what comes of it..I think it is a viable alternative that has these limitations. :^) -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Keith Moore Sent: Monday, July 01, 2002 2:16 PM To: James_Renkel@3com.com Cc: midcom@ietf.org Subject: Re: [midcom] FWD: I-D ACTION:draft-renkel-middlebox-tunnels-00.txt,.ps The idea that tunnels can solve the NAT problem without changes to applications is critically flawed - the technique only works if the application somehow has a tunnel to a location in the network that is simultaneously accessible by all of that application's peers, and if the application knows to use the interface/address associated with that tunnel in preference to all other interface/address pairs available to it. It's certainly better than nothing, and probably better than other things that Midcom has produced. but it's not a general solution. Keith _______________________________________________ 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 daemon@optimus.ietf.org Tue Jul 2 06:35:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01870 for ; Tue, 2 Jul 2002 06:35:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA00503 for midcom-archive@odin.ietf.org; Tue, 2 Jul 2002 06:36:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00132; Tue, 2 Jul 2002 06:34:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00101 for ; Tue, 2 Jul 2002 06:34:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01536; Tue, 2 Jul 2002 06:33:37 -0400 (EDT) Message-Id: <200207021033.GAA01536@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 02 Jul 2002 06:33:37 -0400 Subject: [midcom] I-D ACTION:draft-stiemerling-midcom-simco-01.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Middlebox Configuration (SIMCO) Protocol Version 1.0 Author(s) : M. Stiemerling, J. Quittek Filename : draft-stiemerling-midcom-simco-01.txt Pages : 28 Date : 01-Jul-02 This memo specifies the Simple Middlebox Configuration (SIMCO) protocol for configuring Network Address Translators (NATs) and firewalls dynamically to create address bindings and open pinholes. NATs and firewalls are a problem for applications using voice and video streaming, such as IP telephony, because they need to establish voice or video channels dynamically. The SIMCO protocol allows clients to send requests for this purpose to serving NATs and/or firewalls. The protocol is designed to provide a simple and basic solution that can easily be implemented and used, while still meeting almost all requirements defined by the MIDCOM working group (see [4]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-01.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-01.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: <20020701152454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stiemerling-midcom-simco-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-stiemerling-midcom-simco-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701152454.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 2 14:42:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07447 for ; Tue, 2 Jul 2002 14:42:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16505 for midcom-archive@odin.ietf.org; Tue, 2 Jul 2002 14:42:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15904; Tue, 2 Jul 2002 14:34:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15876 for ; Tue, 2 Jul 2002 14:34:43 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06927 for ; Tue, 2 Jul 2002 14:33:53 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g62IY5K10553 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 2 Jul 2002 11:34:06 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g62IY2C27552; Tue, 2 Jul 2002 11:34:02 -0700 (PDT) Subject: Re: [midcom] Draft agenda To: Melinda Shore Cc: midcom@ietf.org Date: Tue, 2 Jul 2002 13:33:29 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Melinda, Please add the I-D "draft-renkel-middlebox-tunnels-00.txt" to the agenda. I will limit the presentation to 5 minutes. Hopefully, we can limit the discussion to another 5 or 10 minutes. Thanks, Jim Melinda Shore @ietf.org on 06/25/2002 11:07:29 AM Sent by: midcom-admin@ietf.org To: midcom@ietf.org cc: Subject: [midcom] Draft agenda I've appended a draft agenda. Please let me know if I've missed any agenda items, missed any relevant drafts, or have gotten the revision numbers on drafts incorrect. Note also that the Cordell SPAN draft hasn't yet been posted. Thanks, Melinda Middlebox Communication WG (midcom) Tuesday, July 15 at 13:00-15:15 =============================== CHAIR: Melinda Shore AGENDA: Agenda-bashing Status update midcom protocol evaluation midcom protocol semantics Pre-midcom STUN SPAN Documents: draft-ietf-midcom-protocol-eval-01.txt draft-stiemerling-midcom-semantics-00.txt draft-taylor-midcom-semantics-00.txt draft-ietf-midcom-stun-00.txt draft-cordell-midcom-span-a-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 From daemon@optimus.ietf.org Tue Jul 2 14:59:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08428 for ; Tue, 2 Jul 2002 14:59:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17228 for midcom-archive@odin.ietf.org; Tue, 2 Jul 2002 14:59:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16805; Tue, 2 Jul 2002 14:51:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16770 for ; Tue, 2 Jul 2002 14:51:25 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07937 for ; Tue, 2 Jul 2002 14:50:35 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g62Iorpj021464; Tue, 2 Jul 2002 11:50:53 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEI02725; Tue, 2 Jul 2002 11:47:56 -0700 (PDT) Message-Id: <5.1.0.14.0.20020702143740.03aadbd0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Jul 2002 14:50:28 -0400 To: From: Melinda Shore Subject: Re: [midcom] Draft agenda Cc: midcom@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 01:33 PM 7/2/02 -0500, James_Renkel@3com.com wrote: >Please add the I-D "draft-renkel-middlebox-tunnels-00.txt" to the agenda. >I will limit the presentation to 5 minutes. Hopefully, we can limit the >discussion to another 5 or 10 minutes. We don't do presentations. Some process things: 1) The work of the IETF is accomplished on mailing lists. Every four months or so we try to meet face-to-face in order to resolve things that could benefit from "lively" discussion and in order to stress ourselves with insufficient sleep and too much heavy food 2) Meeting time is for discussion only - we don't do presentations 3) Nobody gets meeting time unless they've got specific issues requiring resolution or for very short status updates (those updates belong on the mailing list, too). 4) The requirements document has been approved by the working group and the IESG, and is now sitting in the RFC editor's queue. We can't go back and revisit it without changing the WG charter 5) We work by rough consensus and dashed hopes, which means that there has to be *substantial* agreement among working group participants to move something along, and even then it faces the possibility of being rejected by the IESG and most of all, 6) The work of the IETF is accomplished on mailing lists. It's my understanding that what you'd like to see happen is for the requirements and framework documents to be extended to include RSIP tunnels. You've proposed this several times and there doesn't seem to be agreement from others. The process of developing both documents took over a year and Mike Borella participated in the first BOF that kicked off this effort; I don't see support for using RSIP tunneling let alone for going back and revving our foundation documents despite there having been plenty of opportunity for your ideas to have been heard. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 2 15:14:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09588 for ; Tue, 2 Jul 2002 15:14:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18321 for midcom-archive@odin.ietf.org; Tue, 2 Jul 2002 15:15:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18092; Tue, 2 Jul 2002 15:06:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18063 for ; Tue, 2 Jul 2002 15:06:58 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08871 for ; Tue, 2 Jul 2002 15:06:08 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g62J6Qvb023514 for ; Tue, 2 Jul 2002 12:06:26 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEI03354; Tue, 2 Jul 2002 12:03:33 -0700 (PDT) Message-Id: <5.1.0.14.0.20020702145339.03aaee30@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Jul 2002 15:06:07 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Status update Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Here's where we are right now: 1) Pre-midcom: A) STUN: the next rev of the STUN draft should be appearing on the ietf-announce mailing list any time now and will be going into WG last call shortly after being posted B) SPAN-A: the design team is stalled due to a number of factors mostly related to participants' extra-midcom lives. As a result Pete Cordell's SPAN-A draft doesn't reflect the views of the design team - nevertheless, please consider it a jumping-off point for further discussion, on the mailing list and possibly in Yokohama 2) Midcom: A) Protocol evaluation document: I think one more revision should do it. Please review the document with a particular eye towards what needs to be done to get it into and through WG last call B) Semantics: We have two semantics proposals, neither of which has received much discussion. I've asked the authors whether or not they'll be able to resolve differences between the documents and come up with a single proposal; there are some substantial differences between the documents and it may not be a realistic approach. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 2 15:26:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10303 for ; Tue, 2 Jul 2002 15:25:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18675 for midcom-archive@odin.ietf.org; Tue, 2 Jul 2002 15:26:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18460; Tue, 2 Jul 2002 15:18:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18431 for ; Tue, 2 Jul 2002 15:18:57 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09762 for ; Tue, 2 Jul 2002 15:18:07 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g62JIvK17666 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 2 Jul 2002 12:18:58 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g62JIsC05019; Tue, 2 Jul 2002 12:18:54 -0700 (PDT) Subject: Re: [midcom] Draft agenda To: Melinda Shore Cc: midcom@ietf.org Date: Tue, 2 Jul 2002 14:18:19 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Melinda, I fully appreciate that the overwhelming majority of the work of IETF working groups is done via mailing lists. I participate in them as much as my time permits. I requested presentation time because that seemed to be the way that other working groups that I participate in work. Their meeting agendas give specific amounts of time to presentation of issues that were raised in e-mail discussion of I-Ds. I did not intend to completely represent the tunneling idea, but simply to summarize the admittedly scant e-mail discussion that there has been and try to resolve the issue of whether or not the MIDCOM protocol should include support for tunnels. I agree that there has not been much discussion of this, but my reading of what discussion there has been is that it's split pro and con. I thought this justified a few minutes of meeting time, but I will defer to your opinion that it does not. Jim Melinda Shore @ietf.org on 07/02/2002 01:50:28 PM Sent by: midcom-admin@ietf.org To: James Renkel/MW/US/3Com cc: midcom@ietf.org Subject: Re: [midcom] Draft agenda At 01:33 PM 7/2/02 -0500, James_Renkel@3com.com wrote: >Please add the I-D "draft-renkel-middlebox-tunnels-00.txt" to the agenda. >I will limit the presentation to 5 minutes. Hopefully, we can limit the >discussion to another 5 or 10 minutes. We don't do presentations. Some process things: 1) The work of the IETF is accomplished on mailing lists. Every four months or so we try to meet face-to-face in order to resolve things that could benefit from "lively" discussion and in order to stress ourselves with insufficient sleep and too much heavy food 2) Meeting time is for discussion only - we don't do presentations 3) Nobody gets meeting time unless they've got specific issues requiring resolution or for very short status updates (those updates belong on the mailing list, too). 4) The requirements document has been approved by the working group and the IESG, and is now sitting in the RFC editor's queue. We can't go back and revisit it without changing the WG charter 5) We work by rough consensus and dashed hopes, which means that there has to be *substantial* agreement among working group participants to move something along, and even then it faces the possibility of being rejected by the IESG and most of all, 6) The work of the IETF is accomplished on mailing lists. It's my understanding that what you'd like to see happen is for the requirements and framework documents to be extended to include RSIP tunnels. You've proposed this several times and there doesn't seem to be agreement from others. The process of developing both documents took over a year and Mike Borella participated in the first BOF that kicked off this effort; I don't see support for using RSIP tunneling let alone for going back and revving our foundation documents despite there having been plenty of opportunity for your ideas to have been heard. 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 daemon@optimus.ietf.org Wed Jul 3 06:32:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04208 for ; Wed, 3 Jul 2002 06:32:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27941 for midcom-archive@odin.ietf.org; Wed, 3 Jul 2002 06:33:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27216; Wed, 3 Jul 2002 06:31:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27175 for ; Wed, 3 Jul 2002 06:31:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03896; Wed, 3 Jul 2002 06:30:55 -0400 (EDT) Message-Id: <200207031030.GAA03896@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Jul 2002 06:30:55 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-protocol-eval-02.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communications (MIDCOM) Protocol Evaluation Author(s) : M. Barnes Filename : draft-ietf-midcom-protocol-eval-02.txt Pages : 33 Date : 02-Jul-02 This document provides an evaluation of the applicability of SNMP, RSIP, MEGACO, DIAMETER and COPS as the MIDCOM protocol. A summary of each of the proposed protocols against the MIDCOM requirements and MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-midcom-protocol-eval-02.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-ietf-midcom-protocol-eval-02.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: <20020702151627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-protocol-eval-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-protocol-eval-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151627.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jul 5 14:29:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08940 for ; Fri, 5 Jul 2002 14:29:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18229 for midcom-archive@odin.ietf.org; Fri, 5 Jul 2002 14:30:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18014; Fri, 5 Jul 2002 14:28:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17983 for ; Fri, 5 Jul 2002 14:28:07 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08805 for ; Fri, 5 Jul 2002 14:27:17 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g65IRbYH028409 for ; Fri, 5 Jul 2002 14:27:37 -0400 (EDT) Message-ID: <3D25E517.6080505@dynamicsoft.com> Date: Fri, 05 Jul 2002 14:27:35 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] update to STUN posted Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Folks, I managed to get an update to STUN in before the I-D deadline. It should appear in the archives shortly. Until it does, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-midcom-stun-01.txt The biggest change is the security stuff, which is now based on a one-time-password exchange over TLS. It does request and response integrity checks with an HMAC-SHA1 using that password. Comments welcome. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jul 8 10:13:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15674 for ; Mon, 8 Jul 2002 10:13:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19063 for midcom-archive@odin.ietf.org; Mon, 8 Jul 2002 10:14:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18783; Mon, 8 Jul 2002 10:08:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12137 for ; Sun, 7 Jul 2002 12:11:10 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24340; Sun, 7 Jul 2002 12:10:16 -0400 (EDT) Message-Id: <200207071610.MAA24340@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Sun, 07 Jul 2002 12:10:15 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-01.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : STUN - Simple Traversal of UDP Through Network Address Translators Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy Filename : draft-ietf-midcom-stun-01.txt Pages : 42 Date : 05-Jul-02 Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol that allows applications to discover the presence and types of Network Address Translators (NATs) and firewalls between them and the public Internet. It also provides the ability for applications to determine the public IP addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. The STUN protocol is simple, being almost identical to echo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-midcom-stun-01.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-ietf-midcom-stun-01.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: <20020705142202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-stun-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-stun-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705142202.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jul 8 10:21:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16150 for ; Mon, 8 Jul 2002 10:21:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19616 for midcom-archive@odin.ietf.org; Mon, 8 Jul 2002 10:22:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19393; Mon, 8 Jul 2002 10:19:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19365 for ; Mon, 8 Jul 2002 10:19:47 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15991 for ; Mon, 8 Jul 2002 10:18:55 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g68EJEGs013296 for ; Mon, 8 Jul 2002 07:19:14 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEI79510; Mon, 8 Jul 2002 07:16:22 -0700 (PDT) Message-Id: <5.1.0.14.0.20020708101726.00ac4290@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Jul 2002 10:19:19 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] STUN last call Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We are starting working group last call on STUN, ending 22 July 2002. Please send any comments to the midcom mailing list, along with an indication of whether or not you feel the issue is serious enough to stop last call. Thanks, Melinda >To: IETF-Announce: ; >Cc: midcom@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Date: Sun, 07 Jul 2002 12:10:15 -0400 >Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-01.txt >Sender: midcom-admin@ietf.org >X-Mailman-Version: 1.0 >List-Id: >X-BeenThere: midcom@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Middlebox Communication Working Group of the IETF. > > Title : STUN - Simple Traversal of UDP Through Network Address > Translators > Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy > Filename : draft-ietf-midcom-stun-01.txt > Pages : 42 > Date : 05-Jul-02 > >Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol >that allows applications to discover the presence and types of >Network Address Translators (NATs) and firewalls between them and the >public Internet. It also provides the ability for applications to >determine the public IP addresses allocated to them by the NAT. STUN >works with many existing NATs, and does not require any special >behavior from them. As a result, it allows a wide variety of >applications to work through existing NAT infrastructure. The STUN >protocol is simple, being almost identical to echo. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-ietf-midcom-stun-01.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-ietf-midcom-stun-01.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. >Content-Type: text/plain >Content-ID: <20020705142202.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-midcom-stun-01.txt > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jul 11 11:21:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20820 for ; Thu, 11 Jul 2002 11:21:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15198 for midcom-archive@odin.ietf.org; Thu, 11 Jul 2002 11:22:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15089; Thu, 11 Jul 2002 11:20:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15058 for ; Thu, 11 Jul 2002 11:20:07 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20718 for ; Thu, 11 Jul 2002 11:19:14 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6BFJb39001737 for ; Thu, 11 Jul 2002 08:19:37 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEJ75894; Thu, 11 Jul 2002 08:16:44 -0700 (PDT) Message-Id: <5.1.0.14.0.20020711111751.00abf0f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 11 Jul 2002 11:19:40 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] STUN last call Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org It's been pointed out to me that since so many people will be travelling long distances during the time that the STUN document is in last call, it would be helpful to add a few extra days for review. It's a good point, so STUN last call will end on Wednesday, 24 July. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jul 15 07:02:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23891 for ; Mon, 15 Jul 2002 07:02:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA17001 for midcom-archive@odin.ietf.org; Mon, 15 Jul 2002 07:02:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16757; Mon, 15 Jul 2002 07:00:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16723 for ; Mon, 15 Jul 2002 07:00:54 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23831 for ; Mon, 15 Jul 2002 06:59:56 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g6FB0LU76715 for ; Mon, 15 Jul 2002 13:00:21 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA08570 for ; Mon, 15 Jul 2002 13:00:21 +0200 Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 311472D941; Mon, 15 Jul 2002 13:00:20 +0200 (CEST) X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen From: "Juergen Quittek" MIME-Version: 1.0 To: midcom@ietf.org Organization: NEC Europe Ltd. Content-type: text/plain; charset= "iso-8859-1" Date: Mon, 15 Jul 2002 13:00:20 +0200 Content-transfer-encoding: 7bit Message-Id: <20020715110020.311472D941@imap.heidelberg.ccrle.nec.de> Content-Transfer-Encoding: 7bit Subject: [midcom] semantics discussion Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi all, For preparing a semantics discussion at the session tomorrow, we just discussed with Tom difference between his and our semantics I-D. Tom's I-D lists a lot of issues that were raised on the list, while our I-D already contains (explicitly or implicitly) our answers to most of these questions. Now we want to find out tomorrow, what is the position of the working group. Therefore, we list our answers to several of the discussion points below. (Please note, that not all answers does exactly match our current version of the draft.) Martin and Juergen - Session/Policy handover: Is there a handover mechanism required? our position: yes On what basis is handover of policies organized: per session or per policy? suggestion: policies are tied to authenticated users, not to sessions. A user takes over policies created or modified in a different session by authenticating properly. - Combining policies Is there a need to combine policies by AND in a single request (atomic operation, framework says "multiple filters in a rule")? suggestion: no, but use grouping of policies for joint actions on them (extend, terminate) - Deterministic result To what degree or with respect to which observer does the middlebox have to operate deterministically? Our view: I only has to operate deterministically to the middlebox administrator. And the administrator is not necessarily involved into the midcom protocol at all. At any time the administrator may modify the access control configuration policy. So, an agent might be able to configure a policy once, but at the second time the administrator changed admission policies and this time the same request fails. - Meaning of end of session What happens to existing policies if the session is terminated? Suggestion: In general all policies remain in place until they expire if the agent has not explicitly requested termination and the middlebox has not signaled termination. However, the middlebox may terminate any policy at any time. - Should policiess be persistent (survive middlebox reboot) Suggestion: Yes, as an option. The middlebox may inform the agent by capability exchange whether the middlebox offers persistent or non-persistent policies. - How should timers be supported by the protocol? Our suggestion: The agent request lifetimes for each policy and each group. The middlebox decides on what lifetime is granted. The agent may request extension of lifetimes. - When are policies assigned to a group? Suggestion: At the time they are installed policies are tied to a group The group cannot be changed during lifetime of the policy. - Is there a need for deny actions in a policy? Our view: No, we do not see any use of it. -- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 16 16:18:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28864 for ; Tue, 16 Jul 2002 16:18:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19317 for midcom-archive@odin.ietf.org; Tue, 16 Jul 2002 16:19:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19211; Tue, 16 Jul 2002 16:15:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19180 for ; Tue, 16 Jul 2002 16:15:26 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28808 for ; Tue, 16 Jul 2002 16:14:27 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AEDC69A0032; Tue, 16 Jul 2002 16:15:24 -0400 Message-ID: <000b01c22d04$d5bf5340$2300000a@acmepacket.com> From: "Bob Penfield" To: References: <20020715110020.311472D941@imap.heidelberg.ccrle.nec.de> Date: Tue, 16 Jul 2002 16:10:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [midcom] Only Traditional NAT/NAPT supported in semantics drafts Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit The proposed representation of the filter part of the Policy Rule in section 2.3 of draft-taylor-midcom-semantics-00.txt supports only Traditional NAT/NAPT. Does MIDCOM need to support Twice-NAT (see RFC 2663) where both the source and destination addresses&ports are modified? The Taylor draft includes only a single mapped-address in the Policy Rule. The Stiemerling draft (draft-stiemerling-midcom-semantics-01.txt) has the same limitation in that the Resource Reservation reserves only one mapped address and only one resource can be specified (by its rule identifier) in a Policy Rule Configuration. BTW, in the Stiemerling draft, if the mapped address is pre-determined (already known by the MIDCOM Agent), there does not appear to be a way to specify that known mapped address to the middlebox. Aside from the historical uses of Twice-NAT, consider a scenario where there are multiple parallel NAT middleboxes to get out of a private network (maybe to different service providers). The only way to get the packets for a given RTP stream to go out a specific middlebox is to allocate a port on the internal interface of the middlebox to be used as the destination address by an internal/private endpoint. Thus when the packet traverses the middlebox, both the source and destination addresses need to be changed. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 16 17:33:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00152 for ; Tue, 16 Jul 2002 17:33:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23313 for midcom-archive@odin.ietf.org; Tue, 16 Jul 2002 17:34:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23258; Tue, 16 Jul 2002 17:33:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23231 for ; Tue, 16 Jul 2002 17:33:14 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00102 for ; Tue, 16 Jul 2002 17:32:18 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A119FD71005A; Tue, 16 Jul 2002 17:33:13 -0400 Message-ID: <000d01c22d0f$a3d379a0$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom" Date: Tue, 16 Jul 2002 17:27:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [midcom] Semantics: CHOOSE the destination? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit In sec 2.3 of draft-taylor-midcom-semantics-00.txt, it indicates that the MIDCOM Agent can request an address+port for the mapped address. If the source and destination of a packet are matched against the source and destination of a Policy Rule Filter, the destination address for operation d) & e) of scenario [3:7-2] (NAPT control) would need to "CHOOSE" the destination address. The mapped address would be the internal endpoint address + port. If the middlebox is suppose to match the received packet's destination with the mapped address of the filter, the usage of the components of the filter would be inconsistent between a firewall pinhole and a NAT translation. For an inbound NAT, a packet match would be: src=, dest= For an inbound pinhole, outbound pinhole, and outbound NAT, a packet match would be: src=, dest= There seems to be the same inconsistency in the Stiemerling draft. Or is there not suppose to be a direct relationship between the filter fields and what the middlebox uses to match packets to rules? Forgive me if I am being dense. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 16 20:32:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04950 for ; Tue, 16 Jul 2002 20:32:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA02682 for midcom-archive@odin.ietf.org; Tue, 16 Jul 2002 20:33:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02565; Tue, 16 Jul 2002 20:31:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02532 for ; Tue, 16 Jul 2002 20:31:48 -0400 (EDT) Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04854 for ; Tue, 16 Jul 2002 20:30:49 -0400 (EDT) Received: from ccrle.nec.de (ietf-wireless-dhcp-71-126.dyn.ietf54.wide.ad.jp [133.93.71.126]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6H0Vgu12340; Wed, 17 Jul 2002 09:31:43 +0900 (JST) Message-ID: <3D34BAED.2070205@ccrle.nec.de> Date: Wed, 17 Jul 2002 02:31:41 +0200 From: Martin Stiemerling Organization: NEC User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield CC: midcom@ietf.org Subject: Re: [midcom] Only Traditional NAT/NAPT supported in semantics drafts References: <20020715110020.311472D941@imap.heidelberg.ccrle.nec.de> <000b01c22d04$d5bf5340$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi Bob, thanks for comments and please find my answers in the text. I hope I've gotten the points, since I'm lacking at least three cups of coffee... :-) Cheers Martin Bob Penfield wrote: > The proposed representation of the filter part of the Policy Rule in section > 2.3 of draft-taylor-midcom-semantics-00.txt supports only Traditional > NAT/NAPT. Does MIDCOM need to support Twice-NAT (see RFC 2663) where both > the source and destination addresses&ports are modified? > > The Taylor draft includes only a single mapped-address in the Policy Rule. > The Stiemerling draft (draft-stiemerling-midcom-semantics-01.txt) has the > same limitation in that the Resource Reservation reserves only one mapped > address and only one resource can be specified (by its rule identifier) in a > Policy Rule Configuration. We have the support for modified source and destination address in the current simco draft (draft-stiemerling-midcom-simco-01.txt), but we dropped it in the semantics, because we haven't seen any reason, since now :-( . So we should put this into the semantics. > > BTW, in the Stiemerling draft, if the mapped address is pre-determined > (already known by the MIDCOM Agent), there does not appear to be a way to > specify that known mapped address to the middlebox. When the agent does know the mapped address, he has learned the address from the middlebox, isn't it? So the middlebox knows the address already and I see no need to tell the address to the middlebox. May be I'm wrong, so can give me an example if there is a special case for this scenario? > > Aside from the historical uses of Twice-NAT, consider a scenario where there > are multiple parallel NAT middleboxes to get out of a private network (maybe > to different service providers). The only way to get the packets for a given > RTP stream to go out a specific middlebox is to allocate a port on the > internal interface of the middlebox to be used as the destination address by > an internal/private endpoint. Thus when the packet traverses the middlebox, > both the source and destination addresses need to be changed. Supported by simco. Thanks again for the comments. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.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 daemon@optimus.ietf.org Tue Jul 16 20:50:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05422 for ; Tue, 16 Jul 2002 20:50:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA03423 for midcom-archive@odin.ietf.org; Tue, 16 Jul 2002 20:51:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03317; Tue, 16 Jul 2002 20:50:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03286 for ; Tue, 16 Jul 2002 20:50:16 -0400 (EDT) Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05394 for ; Tue, 16 Jul 2002 20:49:18 -0400 (EDT) Received: from ccrle.nec.de (ietf-wireless-dhcp-71-126.dyn.ietf54.wide.ad.jp [133.93.71.126]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6H0oDu12380; Wed, 17 Jul 2002 09:50:13 +0900 (JST) Message-ID: <3D34BF3E.2010603@ccrle.nec.de> Date: Wed, 17 Jul 2002 02:50:06 +0200 From: Martin Stiemerling Organization: NEC User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield CC: midcom Subject: Re: [midcom] Semantics: CHOOSE the destination? References: <000d01c22d0f$a3d379a0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Bob Penfield wrote: > In sec 2.3 of draft-taylor-midcom-semantics-00.txt, it indicates that the > MIDCOM Agent can request an address+port for the mapped address. If the > source and destination of a packet are matched against the source and > destination of a Policy Rule Filter, the destination address for operation > d) & e) of scenario [3:7-2] (NAPT control) would need to "CHOOSE" the > destination address. The mapped address would be the internal endpoint > address + port. > > If the middlebox is suppose to match the received packet's destination with > the mapped address of the filter, the usage of the components of the filter > would be inconsistent between a firewall pinhole and a NAT translation. > > For an inbound NAT, a packet match would be: > src=, dest= > > For an inbound pinhole, outbound pinhole, and outbound NAT, > a packet match would be: > src=, dest= > > There seems to be the same inconsistency in the Stiemerling draft. > > Or is there not suppose to be a direct relationship between the filter > fields and what the middlebox uses to match packets to rules? With the filter of the policy rule you can specify the parameter, like "I want packets from x to y". How the actual pin hole/NAT binding is set inside the middelbox shouldn't care the agent. Since the configuration might differ and involve multiple rules inside the box, like: packet filter: src= dest= allow NAT: binding packet filter: src= dest= allow or NAT: binding packet filter: src= dest= allow > > Forgive me if I am being dense. Questions are mostly welcome. Cheers Martin > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.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 daemon@optimus.ietf.org Tue Jul 16 22:14:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08413 for ; Tue, 16 Jul 2002 22:14:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA09486 for midcom-archive@odin.ietf.org; Tue, 16 Jul 2002 22:15:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09338; Tue, 16 Jul 2002 22:13:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09297 for ; Tue, 16 Jul 2002 22:13:40 -0400 (EDT) Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08374 for ; Tue, 16 Jul 2002 22:12:41 -0400 (EDT) Received: from ccrle.nec.de (ietf-wireless-dhcp-71-126.dyn.ietf54.wide.ad.jp [133.93.71.126]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6H2Dcu12868 for ; Wed, 17 Jul 2002 11:13:38 +0900 (JST) Message-ID: <3D34D2D2.8030009@ccrle.nec.de> Date: Wed, 17 Jul 2002 04:13:38 +0200 From: Martin Stiemerling Organization: NEC User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Questins about grouping functionality Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi, with respect to yesterday's MIDCOM session I have the following question about the grouping functionality. The requirements say this: 2.2.3. The protocol must support the concept of a ruleset group comprising a multiple of individual rulesets to be treated as an aggregate. Applications using more than one data stream may find it more con- venient and more efficient to be able to use single messages to tear down, extend, and manipulate all middlebox rulesets being used by one instance of the application. But Christian has mentioned that this is not required and nobody has objected during the session. So I think grouping is required. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 16 22:34:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09134 for ; Tue, 16 Jul 2002 22:34:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA10779 for midcom-archive@odin.ietf.org; Tue, 16 Jul 2002 22:35:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10609; Tue, 16 Jul 2002 22:31:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10582 for ; Tue, 16 Jul 2002 22:31:48 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08937 for ; Tue, 16 Jul 2002 22:30:49 -0400 (EDT) From: mshore@cisco.com Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6H2VAM2008136; Tue, 16 Jul 2002 19:31:10 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEN04419; Tue, 16 Jul 2002 19:27:10 -0700 (PDT) Message-Id: <200207170227.AEN04419@mira-sjc5-4.cisco.com> To: Martin Stiemerling cc: midcom@ietf.org Subject: Re: [midcom] Questins about grouping functionality In-Reply-To: Message from Martin Stiemerling of "Wed, 17 Jul 2002 04:13:38 +0200." <3D34D2D2.8030009@ccrle.nec.de> Date: Tue, 16 Jul 2002 22:29:44 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > But Christian has mentioned that this is not required and nobody has > objected during the session. > So I think grouping is required. I think what you're asking is whether or not it should be possible to tear down a group of rulesets by referring to them using a single handle. The requirements are actually somewhat open on this, since it would be possible to tear down a set of rulesets by using a group identifier *or* by using a single teardown command with a list of rulesets. Either would be allowed. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 16 22:41:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09593 for ; Tue, 16 Jul 2002 22:41:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA11198 for midcom-archive@odin.ietf.org; Tue, 16 Jul 2002 22:42:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11118; Tue, 16 Jul 2002 22:40:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11086 for ; Tue, 16 Jul 2002 22:40:54 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09550 for ; Tue, 16 Jul 2002 22:39:55 -0400 (EDT) Received: from airborne.cisco.com (IDENT:mirapoint@airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6H2eMM2012701 for ; Tue, 16 Jul 2002 19:40:22 -0700 (PDT) Received: from localhost.localdomain (ssh-sjc-1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ABM30880; Tue, 16 Jul 2002 19:40:08 -0700 (PDT) Received: by localhost.localdomain (Postfix, from userid 500) id BDA50E678A; Wed, 17 Jul 2002 11:39:08 +0900 (JST) Date: Wed, 17 Jul 2002 11:39:08 +0900 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Questins about grouping functionality Message-ID: <20020717113908.A1544@localhost.localdomain> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3D34D2D2.8030009@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D34D2D2.8030009@ccrle.nec.de>; from Martin.Stiemerling@ccrle.nec.de on Wed, Jul 17, 2002 at 04:13:38AM +0200 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Wed, Jul 17, 2002 04:13:38AM +0200, Martin Stiemerling allegedly wrote: > Hi, > > with respect to yesterday's MIDCOM session I have the following question > about the grouping functionality. > The requirements say this: > 2.2.3. > > The protocol must support the concept of a ruleset group comprising > a multiple of individual rulesets to be treated as an aggregate. > > Applications using more than one data stream may find it more con- > venient and more efficient to be able to use single messages to > tear down, extend, and manipulate all middlebox rulesets being used > by one instance of the application. > > But Christian has mentioned that this is not required and nobody has > objected during the session. > So I think grouping is required. I observe two things. - Since we're discarding 'deny' rules, we don't need AND/OR syntax in a single request, and in fact we don't need to support bundling of multiple filters in a single ruleset. - So the only need for this kind of grouping is for convenience of management. It's not absolutely necessary, it's just convenient. It can be done with an arbitrary cookie field. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 17 02:47:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07502 for ; Wed, 17 Jul 2002 02:47:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA15967 for midcom-archive@odin.ietf.org; Wed, 17 Jul 2002 02:47:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15904; Wed, 17 Jul 2002 02:46:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15869 for ; Wed, 17 Jul 2002 02:46:07 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07377 for ; Wed, 17 Jul 2002 02:45:10 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6H6jZU06880; Wed, 17 Jul 2002 02:45:36 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 02:45:35 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A68B@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Bob Penfield'" , midcom Subject: RE: [midcom] Semantics: CHOOSE the destination? Date: Wed, 17 Jul 2002 02:45:25 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org You definitely describe the behaviour I assumed. In my mind, the apparent inconsistency lies in my use of the term "destination address" for the third address in the tuple. I thought of "destination" as the ultimate destination of the packet, rather than what appears in the destination field of the packet at its origin. I'll think about whther I should redefine/reorder the fields of the filter tuple to produce more consistent behaviour. -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Tuesday, July 16, 2002 5:28 PM To: midcom Subject: [midcom] Semantics: CHOOSE the destination? In sec 2.3 of draft-taylor-midcom-semantics-00.txt, it indicates that the MIDCOM Agent can request an address+port for the mapped address. If the source and destination of a packet are matched against the source and destination of a Policy Rule Filter, the destination address for operation d) & e) of scenario [3:7-2] (NAPT control) would need to "CHOOSE" the destination address. The mapped address would be the internal endpoint address + port. If the middlebox is suppose to match the received packet's destination with the mapped address of the filter, the usage of the components of the filter would be inconsistent between a firewall pinhole and a NAT translation. For an inbound NAT, a packet match would be: src=, dest= For an inbound pinhole, outbound pinhole, and outbound NAT, a packet match would be: src=, dest= There seems to be the same inconsistency in the Stiemerling draft. Or is there not suppose to be a direct relationship between the filter fields and what the middlebox uses to match packets to rules? Forgive me if I am being dense. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.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 daemon@optimus.ietf.org Wed Jul 17 03:36:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08530 for ; Wed, 17 Jul 2002 03:36:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18927 for midcom-archive@odin.ietf.org; Wed, 17 Jul 2002 03:37:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18832; Wed, 17 Jul 2002 03:32:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18805 for ; Wed, 17 Jul 2002 03:32:51 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08469 for ; Wed, 17 Jul 2002 03:31:53 -0400 (EDT) Received: from airborne.cisco.com (IDENT:mirapoint@airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6H7WLqI019706 for ; Wed, 17 Jul 2002 00:32:21 -0700 (PDT) Received: from ietf-wireless-dhcp-74-157.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id ABM33593; Wed, 17 Jul 2002 00:32:06 -0700 (PDT) Received: by ietf-wireless-dhcp-74-157.cisco.com (Postfix, from userid 500) id 7DCF7E678A; Wed, 17 Jul 2002 16:31:09 +0900 (JST) Date: Wed, 17 Jul 2002 16:31:09 +0900 From: Scott Brim To: midcom Subject: Re: [midcom] Semantics: CHOOSE the destination? Message-ID: <20020717163109.D1527@ietf-wireless-dhcp-74-157.ietf54.wide.ad.jp> Mail-Followup-To: Scott Brim , midcom References: <4D79C746863DD51197690002A52CDA0001E8A68B@zcard0kc.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A68B@zcard0kc.ca.nortel.com>; from taylor@nortelnetworks.com on Wed, Jul 17, 2002 at 02:45:25AM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Wed, Jul 17, 2002 02:45:25AM -0400, Tom-PT Taylor allegedly wrote: > > You definitely describe the behaviour I assumed. In my mind, the apparent > inconsistency lies in my use of the term "destination address" for the third > address in the tuple. I thought of "destination" as the ultimate > destination of the packet, rather than what appears in the destination field > of the packet at its origin. I'll think about whther I should > redefine/reorder the fields of the filter tuple to produce more consistent > behaviour. You have no idea what was in the packet at its origin. You mean, when it arrives at the middlebox? > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Tuesday, July 16, 2002 5:28 PM > To: midcom > Subject: [midcom] Semantics: CHOOSE the destination? > > > In sec 2.3 of draft-taylor-midcom-semantics-00.txt, it indicates that the > MIDCOM Agent can request an address+port for the mapped address. If the > source and destination of a packet are matched against the source and > destination of a Policy Rule Filter, the destination address for operation > d) & e) of scenario [3:7-2] (NAPT control) would need to "CHOOSE" the > destination address. The mapped address would be the internal endpoint > address + port. > > If the middlebox is suppose to match the received packet's destination with > the mapped address of the filter, the usage of the components of the filter > would be inconsistent between a firewall pinhole and a NAT translation. > > For an inbound NAT, a packet match would be: > src=, dest= > > For an inbound pinhole, outbound pinhole, and outbound NAT, > a packet match would be: > src=, dest= > > There seems to be the same inconsistency in the Stiemerling draft. > > Or is there not suppose to be a direct relationship between the filter > fields and what the middlebox uses to match packets to rules? > > Forgive me if I am being dense. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 17 03:52:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09012 for ; Wed, 17 Jul 2002 03:52:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA19415 for midcom-archive@odin.ietf.org; Wed, 17 Jul 2002 03:53:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19311; Wed, 17 Jul 2002 03:48:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19280 for ; Wed, 17 Jul 2002 03:48:17 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08910 for ; Wed, 17 Jul 2002 03:47:19 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6H7lUQ08726; Wed, 17 Jul 2002 03:47:30 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 03:47:30 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A691@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Scott Brim'" , midcom Subject: RE: [midcom] Semantics: CHOOSE the destination? Date: Wed, 17 Jul 2002 03:47:26 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Yes. -----Original Message----- From: Scott Brim [mailto:swb@employees.org] Sent: Wednesday, July 17, 2002 3:31 AM To: midcom Subject: Re: [midcom] Semantics: CHOOSE the destination? On Wed, Jul 17, 2002 02:45:25AM -0400, Tom-PT Taylor allegedly wrote: > > You definitely describe the behaviour I assumed. In my mind, the apparent > inconsistency lies in my use of the term "destination address" for the third > address in the tuple. I thought of "destination" as the ultimate > destination of the packet, rather than what appears in the destination field > of the packet at its origin. I'll think about whther I should > redefine/reorder the fields of the filter tuple to produce more consistent > behaviour. You have no idea what was in the packet at its origin. You mean, when it arrives at the middlebox? > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Tuesday, July 16, 2002 5:28 PM > To: midcom > Subject: [midcom] Semantics: CHOOSE the destination? > > > In sec 2.3 of draft-taylor-midcom-semantics-00.txt, it indicates that the > MIDCOM Agent can request an address+port for the mapped address. If the > source and destination of a packet are matched against the source and > destination of a Policy Rule Filter, the destination address for operation > d) & e) of scenario [3:7-2] (NAPT control) would need to "CHOOSE" the > destination address. The mapped address would be the internal endpoint > address + port. > > If the middlebox is suppose to match the received packet's destination with > the mapped address of the filter, the usage of the components of the filter > would be inconsistent between a firewall pinhole and a NAT translation. > > For an inbound NAT, a packet match would be: > src=, dest= > > For an inbound pinhole, outbound pinhole, and outbound NAT, > a packet match would be: > src=, dest= > > There seems to be the same inconsistency in the Stiemerling draft. > > Or is there not suppose to be a direct relationship between the filter > fields and what the middlebox uses to match packets to rules? > > Forgive me if I am being dense. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.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 _______________________________________________ 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 daemon@optimus.ietf.org Wed Jul 17 06:27:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11618 for ; Wed, 17 Jul 2002 06:27:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27373 for midcom-archive@odin.ietf.org; Wed, 17 Jul 2002 06:28:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27341; Wed, 17 Jul 2002 06:26:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27299 for ; Wed, 17 Jul 2002 06:26:42 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11609 for ; Wed, 17 Jul 2002 06:25:45 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6HAQBM2006179; Wed, 17 Jul 2002 03:26:11 -0700 (PDT) Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADL77181; Wed, 17 Jul 2002 03:26:26 -0700 (PDT) From: "Cullen Jennings" To: "Midcom" , Cc: "Alan Hawrylyshen" Date: Wed, 17 Jul 2002 03:26:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] Public stun servers Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit To help aid some of the STUN development along, the vovida.org site is going to try and keep some public STUN servers available for all to use. Right now it is running the code that Alan Hawrylyshen put out as open source. It is not up to the latest spec but we will work on getting it there. The IP address of the STUN servers are: 128.107.250.38 128.107.250.39 There is no SRV DNS entries for them yet but we are working on getting all the things we would need to bring this stuff up to the latest draft. As long as this does not become too difficult to manage, the vovida.org folks hope to keep these running permanently as an aid to the community. Cullen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 17 08:56:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15012 for ; Wed, 17 Jul 2002 08:56:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06148 for midcom-archive@odin.ietf.org; Wed, 17 Jul 2002 08:57:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05911; Wed, 17 Jul 2002 08:51:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05879 for ; Wed, 17 Jul 2002 08:51:41 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14910 for ; Wed, 17 Jul 2002 08:50:42 -0400 (EDT) Received: from jku2.fokus.gmd.de (jku2.dyn.ietf54.wide.ad.jp [133.93.72.184]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g6HCosC18907; Wed, 17 Jul 2002 14:50:54 +0200 Message-Id: <5.1.0.14.0.20020717144903.023552a0@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 17 Jul 2002 14:50:33 +0200 To: "Cullen Jennings" , "Midcom" , From: Jiri Kuthan Subject: Re: [midcom] Public stun servers Cc: "Alan Hawrylyshen" , sr@iptel.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org There is one instance of Alan's server running at iptel.org too: {195.37.77.101|195.37.77.100}:{10000|10001} -Jiri At 12:26 PM 7/17/2002, Cullen Jennings wrote: >To help aid some of the STUN development along, the vovida.org site is going >to try and keep some public STUN servers available for all to use. Right now >it is running the code that Alan Hawrylyshen put out as open source. It is >not up to the latest spec but we will work on getting it there. > >The IP address of the STUN servers are: > >128.107.250.38 >128.107.250.39 > >There is no SRV DNS entries for them yet but we are working on getting all >the things we would need to bring this stuff up to the latest draft. As long >as this does not become too difficult to manage, the vovida.org folks hope >to keep these running permanently as an aid to the community. > >Cullen > > > > >_______________________________________________ >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 daemon@optimus.ietf.org Wed Jul 17 09:32:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16082 for ; Wed, 17 Jul 2002 09:32:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09374 for midcom-archive@odin.ietf.org; Wed, 17 Jul 2002 09:33:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09256; Wed, 17 Jul 2002 09:31:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09225 for ; Wed, 17 Jul 2002 09:31:42 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16019 for ; Wed, 17 Jul 2002 09:30:43 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A1ADF09F0032; Wed, 17 Jul 2002 09:31:25 -0400 Message-ID: <00ef01c22d95$3da9a420$2300000a@acmepacket.com> From: "Bob Penfield" To: "Martin Stiemerling" Cc: "midcom" References: <000d01c22d0f$a3d379a0$2300000a@acmepacket.com> <3D34BF3E.2010603@ccrle.nec.de> Subject: Re: [midcom] Semantics: CHOOSE the destination? Date: Wed, 17 Jul 2002 09:24:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Martin Stiemerling" > Bob Penfield wrote: > > In sec 2.3 of draft-taylor-midcom-semantics-00.txt, it indicates that the > > MIDCOM Agent can request an address+port for the mapped address. If the > > source and destination of a packet are matched against the source and > > destination of a Policy Rule Filter, the destination address for operation > > d) & e) of scenario [3:7-2] (NAPT control) would need to "CHOOSE" the > > destination address. The mapped address would be the internal endpoint > > address + port. > > > > If the middlebox is suppose to match the received packet's destination with > > the mapped address of the filter, the usage of the components of the filter > > would be inconsistent between a firewall pinhole and a NAT translation. > > > > For an inbound NAT, a packet match would be: > > src=, dest= > > > > For an inbound pinhole, outbound pinhole, and outbound NAT, > > a packet match would be: > > src=, dest= > > > > There seems to be the same inconsistency in the Stiemerling draft. > > > > Or is there not suppose to be a direct relationship between the filter > > fields and what the middlebox uses to match packets to rules? > > With the filter of the policy rule you can specify the parameter, like > "I want packets from x to y". How the actual pin hole/NAT binding is set > inside the middelbox shouldn't care the agent. Since the configuration > might differ and involve multiple rules inside the box, like: > packet filter: src= dest= allow > NAT: binding > packet filter: src= dest= allow > > or > NAT: binding > packet filter: src= dest= allow I can agree that the agent should not care, my point was that the filter fields expressed in protocol have different meaning depending on whether the rule is for a NAT or Firewall pin-hole. I find this the be inconsistent and at odds with the statements "... it is possible to come up with a unified semantic representation which has the same form for all the applications intended for MIDCOM protocol" (from Taylor) and "We define the semantics of configuration requests an a way that covers FW and NAT configuration in a single request ..." (from Stiemerling). Let me dive down a bit. Somewhere in the middlebox is a table of "filters" that the middlebox compares received packets with. Each entry is this table is the famous 5-tuple (source address, source port, destination address, destination port, and transport protocol). If there is a one-to-one mapping of fields from the filter of the protocol to the fields of the 5-tuple, the procedures that middlebox uses to populate an entry are relatively trivial. With the proposed semantics, there is not a consistent one-to-one mapping. It depends on the middlebox function (NAT or Firewall). Granted this is not all that difficult to implement, but it is a bit more complex. Let me propose (again) what I believe is a straight forward semantic: The "filter" of a Policy Rule consists of the 5-tuple that is used by the middlebox to match received packets. All other data is part of the "action". These would include the action of changing the source and or destination address and port. In my mind, the filter should only contain packet matching criteria. Any manipulation of the packet is an action. Thus FW and NAT filters are represented the same way. The only difference is the actions/manipulations the middlebox performs on the packets. filter={source address, source port, destination address, destination port, transport protocol} action={permit/deny, mapped source address, mapped source port, mapped destination address, mapped destination port} Obviously these need to be extended to accommodate/represent types of addresses (IPv4/IPv6), address spaces (public/private/whatever), ranges/sequences of ports and parity, but this illustrates the general idea. cheers, (-:bob _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 17 09:48:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16435 for ; Wed, 17 Jul 2002 09:48:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10638 for midcom-archive@odin.ietf.org; Wed, 17 Jul 2002 09:49:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10457; Wed, 17 Jul 2002 09:47:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10359 for ; Wed, 17 Jul 2002 09:47:34 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16360 for ; Wed, 17 Jul 2002 09:46:34 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A5735C9005E; Wed, 17 Jul 2002 09:47:31 -0400 Message-ID: <00f701c22d97$7bd407c0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Martin Stiemerling" Cc: References: <20020715110020.311472D941@imap.heidelberg.ccrle.nec.de> <000b01c22d04$d5bf5340$2300000a@acmepacket.com> <3D34BAED.2070205@ccrle.nec.de> Subject: Re: [midcom] Only Traditional NAT/NAPT supported in semantics drafts Date: Wed, 17 Jul 2002 09:40:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > > > > > Aside from the historical uses of Twice-NAT, consider a scenario where there > > are multiple parallel NAT middleboxes to get out of a private network (maybe > > to different service providers). The only way to get the packets for a given > > RTP stream to go out a specific middlebox is to allocate a port on the > > internal interface of the middlebox to be used as the destination address by > > an internal/private endpoint. Thus when the packet traverses the middlebox, > > both the source and destination addresses need to be changed. > > Supported by simco. > I studied the SIMCO draft, but was unable to figure how you would do this. You could do 2 resource reservations to allocate the mapped addresses, but how would you bind both mapped addresses to the same rule identifier? In general I find the SIMCO draft lacks sufficient explanation of procedures for the middlebox for the various commands and explanation of the uses of the fields. cheers, (-:bob _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 17 16:45:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29602 for ; Wed, 17 Jul 2002 16:45:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00198 for midcom-archive@odin.ietf.org; Wed, 17 Jul 2002 16:46:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00081; Wed, 17 Jul 2002 16:41:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00049 for ; Wed, 17 Jul 2002 16:41:15 -0400 (EDT) Received: from mail.nucleus.com (mail.nucleus.com [207.34.93.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29490 for ; Wed, 17 Jul 2002 16:40:16 -0400 (EDT) Received: from Flux (unverified [207.34.112.222]) by mail.nucleus.com (Vircom SMTPRS 1.4.232) with ESMTP id for ; Wed, 17 Jul 2002 14:41:12 -0600 From: "Alan Hawrylyshen" To: Date: Wed, 17 Jul 2002 14:41:14 -0600 Message-ID: <000c01c22dd2$4ad8f5f0$1310a8c0@Flux> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] Public stun servers -- STUN code update pending... Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi Cullen and Jiri; Thanks for making this available. Before too many people get going on all this, I think that I will need to update the STUN code that I released. Upon closer inspection, one of my work colleagues discovered that there is an error in the length field computation in the code (the length included the header and the draft indicated that the header was not to be counted). I suspect that I will release an update to the STUN package later this week. This update will be incompatible with previous versions of the code, but will be more correct as far as the draft specification is concerned. Thanks for everyone's patience. Alan Hawrylyshen Jasomi Networks Inc. +1.403.269.2938 x 180 alan@jasomi.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 17 17:16:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29980 for ; Wed, 17 Jul 2002 17:16:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02164 for midcom-archive@odin.ietf.org; Wed, 17 Jul 2002 17:17:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02122; Wed, 17 Jul 2002 17:15:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16883 for ; Wed, 17 Jul 2002 13:52:10 -0400 (EDT) Received: from mail.nucleus.com (mail.nucleus.com [207.34.93.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24714 for ; Wed, 17 Jul 2002 13:51:10 -0400 (EDT) Received: from Flux (unverified [207.34.112.222]) by mail.nucleus.com (Vircom SMTPRS 1.4.232) with ESMTP id ; Wed, 17 Jul 2002 11:51:56 -0600 From: "Alan Hawrylyshen" To: "'Cullen Jennings'" , "'Jiri Kuthan'" Cc: "'Midcom'" , , Date: Wed, 17 Jul 2002 11:51:55 -0600 Organization: Jasomi Networks Message-ID: <000201c22dba$a3fa44d0$1310a8c0@Flux> 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.2600.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] RE: Public stun servers -- STUN code update pending... Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi Cullen and Jiri; Thanks for making this available. Before too many people get going on all this, I think that I will need to update the STUN code that I released. Upon closer inspection, one of my work colleagues discovered that there is an error in the length field computation in the code (the length included the header and the draft indicated that the header was not to be counted). I suspect that I will release an update to the STUN package later this week. This update will be incompatible with previous versions of the code, but will be more correct as far as the draft specification is concerned. Thanks for everyone's patience. Alan Hawrylyshen Jasomi Networks Inc. +1.403.269.2938 x 180 alan@jasomi.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed Jul 17 21:44:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06016 for ; Wed, 17 Jul 2002 21:44:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA16020 for midcom-archive@odin.ietf.org; Wed, 17 Jul 2002 21:45:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15817; Wed, 17 Jul 2002 21:39:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15784 for ; Wed, 17 Jul 2002 21:39:39 -0400 (EDT) Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05907 for ; Wed, 17 Jul 2002 21:38:40 -0400 (EDT) Received: from ccrle.nec.de (ietf-wireless-dhcp-71-126.dyn.ietf54.wide.ad.jp [133.93.71.126]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6I1dWu16343; Thu, 18 Jul 2002 10:39:32 +0900 (JST) Message-ID: <3D361C1D.9040300@ccrle.nec.de> Date: Thu, 18 Jul 2002 03:38:37 +0200 From: Martin Stiemerling Organization: NEC User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield CC: midcom@ietf.org Subject: Re: [midcom] Only Traditional NAT/NAPT supported in semantics drafts References: <20020715110020.311472D941@imap.heidelberg.ccrle.nec.de> <000b01c22d04$d5bf5340$2300000a@acmepacket.com> <3D34BAED.2070205@ccrle.nec.de> <00f701c22d97$7bd407c0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit [...] >> >>Supported by simco. >> > > I studied the SIMCO draft, but was unable to figure how you would do this. > You could do 2 resource reservations to allocate the mapped addresses, but > how would you bind both mapped addresses to the same rule identifier? Yes you're right, the current draft version (-01) has been already aligned to the semantics. I had still the first version (-00) in mind. In this version the `242' reply of the `bind_full' request, returns two addresses: the mapped internal address/port (if applicable) und the external mapped address/port. I think that's what you're looking for. > > In general I find the SIMCO draft lacks sufficient explanation of procedures > for the middlebox for the various commands and explanation of the uses of > the fields. Will take care about this in the next revision. Thanks for the hint. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Thu Jul 18 00:22:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10567 for ; Thu, 18 Jul 2002 00:22:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA24179 for midcom-archive@odin.ietf.org; Thu, 18 Jul 2002 00:23:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23906; Thu, 18 Jul 2002 00:17:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23874 for ; Thu, 18 Jul 2002 00:17:05 -0400 (EDT) Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10490 for ; Thu, 18 Jul 2002 00:16:07 -0400 (EDT) Received: from BETA (BETA.dyn.ietf54.wide.ad.jp [133.93.77.144]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6I4H3u16634 for ; Thu, 18 Jul 2002 13:17:03 +0900 (JST) Date: Thu, 18 Jul 2002 06:17:10 +0200 From: Juergen Quittek To: midcom@ietf.org Message-ID: <9708890.1026973030@BETA> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] RFC2119 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Does anyone know the reason why RFC 2119 is not referneced in the requirements I-D for clarifying the meaning of 'must', 'should' and 'may'? Juergen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Thu Jul 18 00:26:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10755 for ; Thu, 18 Jul 2002 00:26:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA24268 for midcom-archive@odin.ietf.org; Thu, 18 Jul 2002 00:27:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24159; Thu, 18 Jul 2002 00:23:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24134 for ; Thu, 18 Jul 2002 00:23:21 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10562 for ; Thu, 18 Jul 2002 00:22:23 -0400 (EDT) From: mshore@cisco.com Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6I4MXOu002364; Wed, 17 Jul 2002 21:22:33 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEN43700; Wed, 17 Jul 2002 21:18:37 -0700 (PDT) Message-Id: <200207180418.AEN43700@mira-sjc5-4.cisco.com> To: Juergen Quittek cc: midcom@ietf.org Subject: Re: [midcom] RFC2119 In-Reply-To: Message from Juergen Quittek of "Thu, 18 Jul 2002 06:17:10 +0200." <9708890.1026973030@BETA> Date: Thu, 18 Jul 2002 01:28:48 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org That would have been an oversight, not a deliberate decision. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jul 18 09:51:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02626 for ; Thu, 18 Jul 2002 09:51:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08104 for midcom-archive@odin.ietf.org; Thu, 18 Jul 2002 09:52:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07970; Thu, 18 Jul 2002 09:51:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07925 for ; Thu, 18 Jul 2002 09:51:11 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02596 for ; Thu, 18 Jul 2002 09:50:11 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IDoXp27972; Thu, 18 Jul 2002 09:50:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 09:50:32 -0400 Message-ID: <4D79C746863DD51197690002A52CDA000344908E@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: Bob Penfield Cc: midcom Subject: RE: [midcom] Semantics: CHOOSE the destination? Date: Thu, 18 Jul 2002 09:48:54 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Bob, I wonder if I could finesse your concerns with the following text. Basically I am proposing that we are effectively doing just one thing: enabling a packet flow. We do it in two ways: by installing filters and by installing bindings. I should say that by the time I on the one hand and Juergen and Martin on the other finish updating our respective drafts with the results of the meeting discussion, the basic difference between us will be that they show the installation of bindings as a separate step from the installation of filters. If my proposed combined representation is seen as merely confusing, I suppose I should give up on it. In the meantime, here's the proposed text: [3:2.15] defines a Policy Rule as a combination of one or more filters and an action. The basic idea is that packets matching the filter have the action applied to them. The canonical form of the filter in [3] is the 5-tuple: {source address, source port, destination address, destination port, protocol} Given the decision in the meeting (which is obviously subject to further testing on the Working Group list) that "deny" actions are out of scope, only two types of action remain: NAT "bind" and firewall "allow". It is possible to express either of these two actions individually or both combined in a single expression, having the semantics of "enable". This is done by expanding the five-tuple shown above by adding two more address/port pairs, representing addresses to which the enabled packet flow is bound on the two sides of the Middlebox. Before looking at the details, it is necessary to examine the implications of this expression of a Policy Rule. There are two such implications: · If the scope of the MIDCOM protocol expands beyond the initial framework, additional semantic expressions may be required to express new actions. It is for this reason that the general "Policy Rule Request" message shown in the the previous version of this document is now replaced by "Enable Request". · If both NAT and firewall operations are being applied, the combined expression is in itself ambiguous as to which is applied first. [3:7.3] makes the point that firewall operations are applied to packets as seen on the wire, and that as a result NAT bindings must be established before making firewall requests based on those bindings. The "Enable Request" described below is assumed to have the necessary semantics to make this happen. That said, the proposed representation of the "enable" Policy Rule has the form: {external address, external port, external mapped address, external mapped port, internal mapped address, internal mapped port, internal address, internal port, direction, protocol} The four address-port components mark the successive points through which the packets enabled by this Policy Rule will flow. In the absence of NAT, neither mapped address-port will appear in a packet header. For single NAT, the external mapped address-port will be bound, and for double NAT, both the internal and external mapped address-port will be bound. These considerations introduce a requirement to indicate whether a binding exists at a given interface on the Middlebox. The "ANY" wildcard is used to denote an unbound address-port. -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Wednesday, July 17, 2002 9:24 AM To: Martin Stiemerling Cc: midcom Subject: Re: [midcom] Semantics: CHOOSE the destination? ----- Original Message ----- From: "Martin Stiemerling" > Bob Penfield wrote: > > In sec 2.3 of draft-taylor-midcom-semantics-00.txt, it indicates that the > > MIDCOM Agent can request an address+port for the mapped address. If the > > source and destination of a packet are matched against the source and > > destination of a Policy Rule Filter, the destination address for operation > > d) & e) of scenario [3:7-2] (NAPT control) would need to "CHOOSE" the > > destination address. The mapped address would be the internal endpoint > > address + port. > > > > If the middlebox is suppose to match the received packet's destination with > > the mapped address of the filter, the usage of the components of the filter > > would be inconsistent between a firewall pinhole and a NAT translation. > > > > For an inbound NAT, a packet match would be: > > src=, dest= > > > > For an inbound pinhole, outbound pinhole, and outbound NAT, > > a packet match would be: > > src=, dest= > > > > There seems to be the same inconsistency in the Stiemerling draft. > > > > Or is there not suppose to be a direct relationship between the filter > > fields and what the middlebox uses to match packets to rules? > > With the filter of the policy rule you can specify the parameter, like > "I want packets from x to y". How the actual pin hole/NAT binding is set > inside the middelbox shouldn't care the agent. Since the configuration > might differ and involve multiple rules inside the box, like: > packet filter: src= dest= allow > NAT: binding > packet filter: src= dest= allow > > or > NAT: binding > packet filter: src= dest= allow I can agree that the agent should not care, my point was that the filter fields expressed in protocol have different meaning depending on whether the rule is for a NAT or Firewall pin-hole. I find this the be inconsistent and at odds with the statements "... it is possible to come up with a unified semantic representation which has the same form for all the applications intended for MIDCOM protocol" (from Taylor) and "We define the semantics of configuration requests an a way that covers FW and NAT configuration in a single request ..." (from Stiemerling). Let me dive down a bit. Somewhere in the middlebox is a table of "filters" that the middlebox compares received packets with. Each entry is this table is the famous 5-tuple (source address, source port, destination address, destination port, and transport protocol). If there is a one-to-one mapping of fields from the filter of the protocol to the fields of the 5-tuple, the procedures that middlebox uses to populate an entry are relatively trivial. With the proposed semantics, there is not a consistent one-to-one mapping. It depends on the middlebox function (NAT or Firewall). Granted this is not all that difficult to implement, but it is a bit more complex. Let me propose (again) what I believe is a straight forward semantic: The "filter" of a Policy Rule consists of the 5-tuple that is used by the middlebox to match received packets. All other data is part of the "action". These would include the action of changing the source and or destination address and port. In my mind, the filter should only contain packet matching criteria. Any manipulation of the packet is an action. Thus FW and NAT filters are represented the same way. The only difference is the actions/manipulations the middlebox performs on the packets. filter={source address, source port, destination address, destination port, transport protocol} action={permit/deny, mapped source address, mapped source port, mapped destination address, mapped destination port} Obviously these need to be extended to accommodate/represent types of addresses (IPv4/IPv6), address spaces (public/private/whatever), ranges/sequences of ports and parity, but this illustrates the general idea. cheers, (-:bob _______________________________________________ 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 daemon@optimus.ietf.org Thu Jul 18 10:20:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03197 for ; Thu, 18 Jul 2002 10:20:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09863 for midcom-archive@odin.ietf.org; Thu, 18 Jul 2002 10:21:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09766; Thu, 18 Jul 2002 10:18:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09735 for ; Thu, 18 Jul 2002 10:18:04 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03152 for ; Thu, 18 Jul 2002 10:17:06 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IEHXp00876 for ; Thu, 18 Jul 2002 10:17:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 10:17:33 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A6A0@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: midcom Date: Thu, 18 Jul 2002 10:17:30 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Semantics Discussion Points Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org The charts I presented on open issues in defining the semantics will undoubtedly appear at some point with the minutes. In the meantime, their contents are reproduced here. I should say that many of these points represent attempts to better understand the requirements. Comments on the various points are welcome. 1. Takeover Takeover = ability for one Agent to operate on rules established by another Is it really required? What granularity? Per rule? Per session? Should the protocol have a formal handoff procedure? Note that in the case of an Agent crash this can't be done but takeover capability is desirable anyway. 2. "Deterministic Outcome" It can be argued that Middlebox behaviour will be deterministic only in the eyes of the administrator. Is it agreed that this is the only condition the protocol must satisfy to meet requirement 2.1.12? 3. Meaning of End Of Session Do rules continue to survive to the end of their lifetime? 4. Groups Must it be possible to form groups on an ad hoc basis after the rules have been defined, or can rules be assigned to groups from the start? Will there ever be a requirement to move a rule from one group to another? Is destroy-create an adequate substitute if there is such a requirement? Group timeout needed? 5. Port Parity Would there ever be a case where you would want to map an odd port to an even one or vice versa? 6. Is Deny Required? Is there a real example where MIDCOM needs to install a blocking rule? 7. Multiple Filter Conditions A group of policy rules is equivalent to testing packets against Rule 1 OR Rule 2 OR ... Is AND capability required? Probably not -- can express the conjunction of filters as a simple filter itself. Conclusion: no point in multiple filter conditions in the same policy rule. 8. Query Capability Is the requirement for querying installed rules limited to the example in the framework or should it be more general? Audit for takeover? Taylor draft provides general capability against a wildcarded filter expression -- is this going too far? Scope issues: is what an Agent can discover by querying limited by local policy only? 9. Wildcards and Ranges Is there a need to support address ranges in filters? Port ranges? Open-ended pinholes (e.g. allow TCP from any source to this internal address/port)? 10. Grace Period and Pre-Notification Should there be notifications before rule lifetime expiry? 11. Atomicity A Requirement? Neither semantics document provides for installation of multiple rules in a single atomic transaction (i.e. to avoid deadlock). Is this a requirement? Is there a requirement to enable forcing of symmetric bidirectional mappings (i.e. source mapped address-port = destination mapped address-port)? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jul 18 12:05:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06460 for ; Thu, 18 Jul 2002 12:05:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22047 for midcom-archive@odin.ietf.org; Thu, 18 Jul 2002 12:06:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21760; Thu, 18 Jul 2002 12:04:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21700 for ; Thu, 18 Jul 2002 12:04:28 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06385 for ; Thu, 18 Jul 2002 12:03:31 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A70BF74E0128; Thu, 18 Jul 2002 12:04:27 -0400 Message-ID: <000f01c22e73$012df120$2300000a@acmepacket.com> From: "Bob Penfield" To: "Tom-PT Taylor" Cc: "midcom" References: <4D79C746863DD51197690002A52CDA000344908E@zcard0kc.ca.nortel.com> Subject: Re: [midcom] Semantics: CHOOSE the destination? Date: Thu, 18 Jul 2002 11:51:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Hi Tom, I was unable to make it to Japan, so I am not aware of how the discussions went. However, what you propose below I find to be complete, although I have a subtly different view which I describe below. ----- Original Message ----- From: "Tom-PT Taylor" > > Bob, I wonder if I could finesse your concerns with the following text. > Basically I am proposing that we are effectively doing just one thing: > enabling a packet flow. I strongly agree! > We do it in two ways: by installing filters and by > installing bindings. I should say that by the time I on the one hand and > Juergen and Martin on the other finish updating our respective drafts with > the results of the meeting discussion, the basic difference between us will > be that they show the installation of bindings as a separate step from the > installation of filters. If my proposed combined representation is seen as > merely confusing, I suppose I should give up on it. I strongly support a combined representation. I do not find that at all confusing. > In the meantime, here's > the proposed text: > > [3:2.15] defines a Policy Rule as a combination of one or more filters and > an action. The basic idea is that packets matching the filter have the > action applied to them. The canonical form of the filter in [3] is the > 5-tuple: > > {source address, source port, destination address, destination port, > protocol} > > Given the decision in the meeting (which is obviously subject to further > testing on the Working Group list) that "deny" actions are out of scope, > only two types of action remain: NAT "bind" and firewall "allow". It is > possible to express either of these two actions individually or both > combined in a single expression, having the semantics of "enable". This is > done by expanding the five-tuple shown above by adding two more address/port > pairs, representing addresses to which the enabled packet flow is bound on > the two sides of the Middlebox. Exactly! I would say the NAT action is actually "bind+allow", but I agree, the action for both is really just "enable". > > Before looking at the details, it is necessary to examine the implications > of this expression of a Policy Rule. There are two such implications: > > · If the scope of the MIDCOM protocol expands beyond the initial > framework, additional semantic expressions may be required to express new > actions. It is for this reason that the general "Policy Rule Request" > message shown in the the previous version of this document is now replaced > by "Enable Request". > > · If both NAT and firewall operations are being applied, the combined > expression is in itself ambiguous as to which is applied first. [3:7.3] > makes the point that firewall operations are applied to packets as seen on > the wire, and that as a result NAT bindings must be established before > making firewall requests based on those bindings. The "Enable Request" > described below is assumed to have the necessary semantics to make this > happen. > > That said, the proposed representation of the "enable" Policy Rule has the > form: > > {external address, external port, > external mapped address, external mapped port, > internal mapped address, internal mapped port, > internal address, internal port, > direction, > protocol} > > The four address-port components mark the successive points through which > the packets enabled by this Policy Rule will flow. In the absence of NAT, > neither mapped address-port will appear in a packet header. For single NAT, > the external mapped address-port will be bound, and for double NAT, both the > internal and external mapped address-port will be bound. These > considerations introduce a requirement to indicate whether a binding exists > at a given interface on the Middlebox. The "ANY" wildcard is used to denote > an unbound address-port. > I find this complete as far as all the necessary pieces are there. However, I have a slightly different view which is based on what I will admit are implementation details, but for us it has made implementation of a middlebox a bit more straight forward by having the protocol express the data in the same way as it would be keep in the lookup table used to match packets. {input source address, input source port, input destination address, input destination port, protocol, direction, output source address, output source port output destination address, output destination port} The "lookup key" for matching received packets in the middlebox is the first six fields. The "output" fields define the "changes" to be applied if it is a NAT. If there is no NAT, these fields are set to ANY. However, it is certainly easy enough to manipulate the data in the filter you propose into this form, and I have to admit that it makes keeping track of the binding a bit more complicated, so I will not object to keeping your proposal. I do have to note that semantics of "direction" does imply that only middlebox with one internal address space and one external address space are supported. Are we saying that support for middleboxes with more than two addresses spaces are out of scope? cheers, (-:bob _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jul 18 12:12:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06695 for ; Thu, 18 Jul 2002 12:12:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22638 for midcom-archive@odin.ietf.org; Thu, 18 Jul 2002 12:13:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22582; Thu, 18 Jul 2002 12:12:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22553 for ; Thu, 18 Jul 2002 12:12:20 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06663 for ; Thu, 18 Jul 2002 12:11:23 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IGBmW11307; Thu, 18 Jul 2002 12:11:48 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 12:11:47 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A6A2@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Bob Penfield'" Cc: midcom Subject: RE: [midcom] Semantics: CHOOSE the destination? Date: Thu, 18 Jul 2002 12:11:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E75.5F7CD7C6" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 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_01C22E75.5F7CD7C6 Content-Type: text/plain; charset="iso-8859-1" I misinterpreted something you said earlier, with the result that I thought the double mapping covered this. I've had a suggestion that we should add a realm-instance qualifier on the internal addresses to allow for multiple address spaces or load-sharing Middleboxes. Does that sound right? -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Thursday, July 18, 2002 11:52 AM To: Taylor, Tom-PT [CAR:B602:EXCH] Cc: midcom Subject: Re: [midcom] Semantics: CHOOSE the destination? [snip] I do have to note that semantics of "direction" does imply that only middlebox with one internal address space and one external address space are supported. Are we saying that support for middleboxes with more than two addresses spaces are out of scope? cheers, (-:bob ------_=_NextPart_001_01C22E75.5F7CD7C6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Semantics: CHOOSE the destination?

I misinterpreted something you said earlier, with the = result that I thought the double mapping covered this.  I've had a = suggestion that we should add a realm-instance qualifier on the = internal addresses to allow for multiple address spaces or load-sharing = Middleboxes.  Does that sound right?

-----Original Message-----
From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
Sent: Thursday, July 18, 2002 11:52 AM
To: Taylor, Tom-PT [CAR:B602:EXCH]
Cc: midcom
Subject: Re: [midcom] Semantics: CHOOSE the = destination?

[snip]

I do have to note that semantics of = "direction" does imply that only
middlebox with one internal address space and one = external address space are
supported. Are we saying that support for = middleboxes with more than two
addresses spaces are out of scope?

cheers,
(-:bob


------_=_NextPart_001_01C22E75.5F7CD7C6-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jul 22 08:30:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02348 for ; Mon, 22 Jul 2002 08:30:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA12936 for midcom-archive@odin.ietf.org; Mon, 22 Jul 2002 08:31:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12195; Mon, 22 Jul 2002 08:26:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12166 for ; Mon, 22 Jul 2002 08:26:10 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02254 for ; Mon, 22 Jul 2002 08:25:11 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6MCPnm15164 for ; Mon, 22 Jul 2002 07:25:49 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 07:25:34 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C784@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Mon, 22 Jul 2002 07:25:34 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Reminder: Please review updated Protocol evaluation draft Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi all, This is a reminder, particularly for individuals that weren't at the MIDCOM WG session last Tuesday, that the following is the scheduled for completing the protocol evaluation document: Friday, August 2nd - End of WG discussions of current open issues. Monday, August 12th - Updated draft based upon WG discussions/concensus; draft available for WGLC Monday, Sept. 2nd - WGLC ends Monday, Sept. 9th - Updated draft based upon WGLC comments available Ideally, comments this week would be extremely useful so that any WG discussion can complete prior to the deadline. The intent is for the next version be ready for WGLC, so any remaining issues need to brought forth now. During the WG session, the primary issues I discussed were with regards to the following: - Clarification that COPS evaluation requires COPS-PR (need to update COPS overview section) - Further detail on the COPS and MEGACO "implied directionality" issue wrt to the MIDCOM framework (to be included in the COPS and MEGACO overview sections) - Further detail on the SNMP overview section with regards to the implication that the MIDCOM PDP is in the Middlebox. - Clarification that SNMP requires v3 to meet the security requirements (need to update the SNMP overview). I will be posting proposed text changes to the list to address the concerns in separate emails. I will be correcting some of the grammatical and punctuation issues and some more minor wordsmithing for consistency (it still reads a bit choppy in areas where I've merged my text with that of the original authors) in the next version, but will not be posting any specific information about these changes to the list. I will also highlight that in re-reviewing the document, I've seen some additional inconsistencies in some of the evaluations wrt to P versus P+, etc. which will also be described in separate emails. I'm sure that there are more of these that can be identified by careful reading by other members of the WG. So, if you've not yet had the time to do a careful reading of this document, please take the opportunity now: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-02.txt Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jul 22 08:43:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02610 for ; Mon, 22 Jul 2002 08:43:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13417 for midcom-archive@odin.ietf.org; Mon, 22 Jul 2002 08:43:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13380; Mon, 22 Jul 2002 08:42:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13351 for ; Mon, 22 Jul 2002 08:42:40 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02595 for ; Mon, 22 Jul 2002 08:41:39 -0400 (EDT) From: mshore@cisco.com Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6MCg3Ou020219 for ; Mon, 22 Jul 2002 05:42:03 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEO24990; Mon, 22 Jul 2002 05:38:09 -0700 (PDT) Message-Id: <200207221238.AEO24990@mira-sjc5-4.cisco.com> To: midcom@ietf.org Date: Mon, 22 Jul 2002 08:40:40 -0400 Subject: [midcom] Last call reminder Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org The STUN draft is in WG last call, which closes on Wednesday the 24th. Speak now or forever hold your peace. http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jul 22 14:53:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27661 for ; Mon, 22 Jul 2002 14:53:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20428 for midcom-archive@odin.ietf.org; Mon, 22 Jul 2002 14:54:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18974; Mon, 22 Jul 2002 14:51:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18921 for ; Mon, 22 Jul 2002 14:51:32 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27379 for ; Mon, 22 Jul 2002 14:50:30 -0400 (EDT) Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6MIodhK028548 for ; Mon, 22 Jul 2002 11:51:00 -0700 (PDT) Received: from DWINGW2K4 (sjc-vpn1-202.cisco.com [10.21.96.202]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AFQ02284; Mon, 22 Jul 2002 11:39:38 -0700 (PDT) From: "Dan Wing" To: Subject: RE: [midcom] Last call reminder Date: Mon, 22 Jul 2002 11:37:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <200207221238.AEO24990@mira-sjc5-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > The STUN draft is in WG last call, which closes on Wednesday > the 24th. Speak now or forever hold your peace. > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt Two nits are that the I-D needs to have " nat" changed to " NAT", and " stun" to " STUN". Section 11.1, which defines the binary values of the various messages, should indicate which hex values are undefined and how they their use by an implementation should be correctly documented (via an IANA registration or via a new RFC, or both). I noticed several other 11.* sections also don't define how unused fields should be defined; perhaps 11.0 can say something regarding the entire section. -d _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Jul 22 15:42:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02256 for ; Mon, 22 Jul 2002 15:42:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14940 for midcom-archive@odin.ietf.org; Mon, 22 Jul 2002 15:43:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14105; Mon, 22 Jul 2002 15:41:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14037 for ; Mon, 22 Jul 2002 15:41:45 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02070 for ; Mon, 22 Jul 2002 15:40:43 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AFF0AD320128; Mon, 22 Jul 2002 15:41:36 -0400 Message-ID: <008101c231b7$b3f74c60$2300000a@acmepacket.com> From: "Bob Penfield" To: "Tom-PT Taylor" , "midcom" References: <4D79C746863DD51197690002A52CDA0001E8A6A0@zcard0kc.ca.nortel.com> Subject: Re: [midcom] Semantics Discussion Points Date: Mon, 22 Jul 2002 15:40:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Tom-PT Taylor" > > The charts I presented on open issues in defining the semantics will > undoubtedly appear at some point with the minutes. In the meantime, their > contents are reproduced here. I should say that many of these points > represent attempts to better understand the requirements. Comments on the > various points are welcome. > > 1. Takeover > > Takeover = ability for one Agent to operate on rules established by another > Is it really required? As one of those who supported/insisted on requirement 2.2.7, I say yes. Again, the motivation behind requirement 2.2.7 (which is unfortunately not present in the requirements), was to allow for redundancy in the application and to handle the case where one agent failed after a rule was added, another agent could remove the rule when the application session was completed. > What granularity? Per rule? Per session? It could even be per agent, as in "let agent A muck with any rule that agent B creates and vice versa". In that case it could simply be policy in the middlebox. > Should the protocol have a formal handoff procedure? No. I see no need for this. The redundant agents (there could be more than just 2) are established ahead of time. This could be done: a) by local policy in the middlebox. b) at session establishment where the agent indicates what other agents are allowed to operate in its rules. OR c) at rule creation, where the agent indicates what other agents can operate on this rule. OR, if multiple agents could establish sessions with the middlebox using the same agent identification, so they would be seen as the same entity even though there are multiple sessions. Its as if the "agent" is a logical entity that lives across multiple network hosts. Any notifications would be sent on all sessions with that agent identifier. > Note that in the case of an Agent crash this can't be done but takeover > capability is desirable anyway. > > 2. "Deterministic Outcome" > > It can be argued that Middlebox behaviour will be deterministic only in the > eyes of the administrator. > Is it agreed that this is the only condition the protocol must satisfy to > meet requirement 2.1.12? I don't think so. There needs to be precedence/ordering rules for the basic components of the filter (5-tuple), or a way to indicate or determine the precedence that is used by the middlebox. It may even depend on the hardware used in the middlebox. Some systems won't allow overlap at all, some may depend on the order the entries are added, others may depend on a weighting scheme, other may simply be longest match. There should probably be something in the session establishment that can indicate the precedence and any restrictions. > > 3. Meaning of End Of Session > > Do rules continue to survive to the end of their lifetime? This should probably be specified in protocol at rule or session establishment. In the case of redundant agents, where one agent might crash or restart, you do not want to stop the flows/sessions. If rule state is stored at the endpoints instead of at proxies which act as midcom agents, a failed/restarted agent would not mean that the rule state was lost to the application, and thus there is no need to delete the rule. > > 4. Groups > > Must it be possible to form groups on an ad hoc basis after the rules have > been defined, or can rules be assigned to groups from the start? > Will there ever be a requirement to move a rule from one group to another? > Is destroy-create an adequate substitute if there is such a requirement? > Group timeout needed? I have not yet encountered or thought of a case where you would need to add a rule to a group except when it is created. > > 5. Port Parity > > Would there ever be a case where you would want to map an odd port to an > even one or vice versa? > > 6. Is Deny Required? > > Is there a real example where MIDCOM needs to install a blocking rule? It is not so much "deny" as "disabled". In establishing things like SIP sessions, the agent does not have all the necesary information, but wants to "reserve" the resources in the middlebox. If the middlebox has a limited number of bindings it will give out or a limit on the number of pinholes, you would want to make sure that the needed resources for both the caller-to-callee and callee-to-caller flows are reserved in the first communication with the middlebox so that we don't have to reject a session after the called party has answered. To be specific, refer to section 7.2 in the framework doc. The request to "create consecutive port BINDs" occurs after the called party answers. If this request were to fail, the proxy (midcom agent) would have to tear down the session which the called party would see as more or less complete, but the calling party will see it as unanswered (this also runs into all sorts of messy SIP rules too). If the bindings could be reserved as the INVITE traverses the SIP Proxy (midcom agent), the half-answered call could be avoided. If the bindings/reservations could not be done, the INVITE would be rejected and not forwarded on to the called party. However, if the agent reserves the bindings at this earlier stage, it does not know the internal address to which the bindings map to. It needs to "reserve" a mapped address, but the rule is "disabled", until the rule is updated with the internal address when the 200-OK response comes from the internal SIP phone. > > 7. Multiple Filter Conditions > > A group of policy rules is equivalent to testing packets against Rule 1 OR > Rule 2 OR ... > Is AND capability required? > Probably not -- can express the conjunction of filters as a simple filter > itself. > Conclusion: no point in multiple filter conditions in the same policy rule. Agreed > 8. Query Capability > > Is the requirement for querying installed rules limited to the example in > the framework or should it be more general? > Audit for takeover? It could also be used for recovery when an agent restarts and re-establishes the session. > Taylor draft provides general capability against a wildcarded filter > expression -- is this going too far? > Scope issues: is what an Agent can discover by querying limited by local > policy only? It could be limited to just those rules installed by the same agent identifier in the same or a previous session. > > 9. Wildcards and Ranges > > Is there a need to support address ranges in filters? > Port ranges? > Open-ended pinholes (e.g. allow TCP from any source to this internal > address/port)? Allowing any source is required for a basic RTP flow. SDP used in SIP, MGCP, and Megaco does not identify the source address and port of the flow, only the destination. > > 10. Grace Period and Pre-Notification > > Should there be notifications before rule lifetime expiry? I'm inclined to think so. It does allow the agent to rely on the middlebox for the expiration timing. Otherwise, the agent would have to have timers too so it could extend the rule lifetime shortly before it expires. > > 11. Atomicity A Requirement? > > Neither semantics document provides for installation of multiple rules in a > single atomic transaction (i.e. to avoid deadlock). > Is this a requirement? There were a number of us who wanted this as an explicit requirement, but it is not in the doc, but the same principles in 2.2.3 of efficiency and minimizing the messages to and from the middlebox apply. It would be better if there was just one middlebox transaction between receiving the application request and forwarding it on. > Is there a requirement to enable forcing of symmetric bidirectional mappings > (i.e. source mapped address-port = destination mapped address-port)? It is not explicitly required, but would enable things like symetric RTP. > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > > > _______________________________________________ > 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 daemon@ns.ietf.org Mon Jul 22 22:05:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04504 for ; Mon, 22 Jul 2002 22:05:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA27679 for midcom-archive@odin.ietf.org; Mon, 22 Jul 2002 22:06:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26861; Mon, 22 Jul 2002 22:04:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26824 for ; Mon, 22 Jul 2002 22:04:26 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04348 for ; Mon, 22 Jul 2002 22:03:25 -0400 (EDT) Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6N23nOu016761 for ; Mon, 22 Jul 2002 19:03:49 -0700 (PDT) Received: from DWINGW2K4 (sjc-vpn2-774.cisco.com [10.21.115.6]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AFR05990; Mon, 22 Jul 2002 19:02:25 -0700 (PDT) From: "Dan Wing" To: Subject: RE: [midcom] Last call reminder Date: Mon, 22 Jul 2002 19:03:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <200207221238.AEO24990@mira-sjc5-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Section 10.2, "Binding Lifetime Discovery", doesn't explain what a client is supposed to do with this information. It's somewhat obvious that a client would use this information to decide when to send a keepalive packet (to keep the NAT binding active), but it would be useful to point out the reason a client would want to learn how long a binding remains active. What needs to be discussed -- either in 10.2 or 14.3 ("Brittleness Introduced by STUN") is that any learning of the binding lifetime is only valuable if the NAT device doesn't release the binding prematurely due to a reboot, exhaustion of UDP ports for new connections, or other actions. Premature loss of a binding must be detected by whatever keepalive mechanism is used by the client (thus, a keepalive that doesn't report a broken binding is insufficient). -d > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > mshore@cisco.com > Sent: Monday, July 22, 2002 5:41 AM > To: midcom@ietf.org > Subject: [midcom] Last call reminder > > > The STUN draft is in WG last call, which closes on Wednesday > the 24th. Speak now or forever hold your peace. > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt > > 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 daemon@ns.ietf.org Tue Jul 23 01:35:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21031 for ; Tue, 23 Jul 2002 01:35:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA13202 for midcom-archive@odin.ietf.org; Tue, 23 Jul 2002 01:36:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13116; Tue, 23 Jul 2002 01:33:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13088 for ; Tue, 23 Jul 2002 01:33:17 -0400 (EDT) Received: from oak.Research.Panasonic.COM (oak.Research.Panasonic.COM [150.169.1.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20971 for ; Tue, 23 Jul 2002 01:32:13 -0400 (EDT) Received: from mastodon.kmerl.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.Research.Panasonic.COM (8.11.6+Sun/8.10.2) with ESMTP id g6N5PTB04944 for ; Tue, 23 Jul 2002 01:25:29 -0400 (EDT) Received: from tornado.kmerl.com (firebox [150.169.11.2]) by mastodon.kmerl.research.panasonic.com (8.10.2+Sun/8.10.2) with ESMTP id g6N5Hgc03172 for ; Tue, 23 Jul 2002 01:17:43 -0400 (EDT) Subject: RE: [midcom] Last call reminder MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 22 Jul 2002 22:25:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Message-ID: Thread-Topic: [midcom] Last call reminder Thread-Index: AcIxffy/d/A4Blp8SbCHZZ67WGNrJgAhWXWA From: "Yutaka Takeda" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA13089 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Depending on the implementation, STUN client likely re-tries the discovery process to make sure the result was correct. In such a case, I have observed one problem when it was 'Restricted cone NAT'. In the first discovery process, it results in Restricted NAT. And then, STUN client re-tries the one from the same port. In Test II after knowing that it is natted with Test I, STUN client receives a response and ends up with wrong result of Full-cone NAT. This happens because STUN client has already sent a packet to the secondary IP (Ca) in Test I (to Ca) in the first discovery process. To prevent this, the following workaround can be taken. - Prepare more than one port for STUN discovery process. - Perform each process with different port number. This is an implementation issue, however, it is good to point out this and conduct implementers to take a workaround described above in case implementers want to re-try the process. ------------------------------ Yutaka Takeda - Project Leader Kyushu Matsushita Electric Research Laboratory of Panasonic Technologies Company A Division of Matsushita Electric Corporation of America Tel: 858-485-4692, Fax: 858-485-6647 E-mail: takeday@kmerl.com > -----Original Message----- > From: mshore@cisco.com [mailto:mshore@cisco.com] > Sent: Monday, July 22, 2002 5:41 AM > To: midcom@ietf.org > Subject: [midcom] Last call reminder > > > The STUN draft is in WG last call, which closes on Wednesday > the 24th. Speak now or forever hold your peace. > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt > > 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 daemon@optimus.ietf.org Tue Jul 23 09:01:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09767 for ; Tue, 23 Jul 2002 09:01:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08578 for midcom-archive@odin.ietf.org; Tue, 23 Jul 2002 09:02:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08218; Tue, 23 Jul 2002 09:00:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08177 for ; Tue, 23 Jul 2002 09:00:48 -0400 (EDT) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09704 for ; Tue, 23 Jul 2002 08:59:46 -0400 (EDT) Received: from host213-122-9-42.in-addr.btopenworld.com ([213.122.9.42] helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #8) id 17WzHR-0007fD-00; Tue, 23 Jul 2002 14:00:45 +0100 Message-ID: <000f01c23249$32a87f20$0200000a@tkw> From: "Pete Cordell" To: , "Melinda Shore" References: <5.1.0.14.0.20020708101726.00ac4290@localhost> Subject: Re: [midcom] STUN last call Date: Tue, 23 Jul 2002 14:01:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I've only scanned the new draft. I have some other editorial comments, but I wanted to present the following first..... My main concern is that the default security mechanisms require the server to be stateful. This is undesirable and I think it can be avoided with only minor changes. This would involve the server supplying the TARGET-TID instead of the client. The following sequence would result: 1. Client sends shared secret request over TLS. 2. Server returns TARGET-TID and corresponding TARGET-OTP to client. The server can generate these as: TARGET-TID = random; TARGET-OTP = HMAC_?( server_secret, TARGET-TID ); Being algorithmically related, a server does not need state. Because both are supplied by the server, an attacker can't request the TARGET-OTP corresponding to a particular TARGET-TID. These effectively act as a server supplied user-name and password. In that spirit I would recommend that the TARGET-TID be entered as a separate parameter in the Binding Request. That way the same TARGET-TID / TARGET-OTP pair can be used for a number of requests (possibly over a number of days). The Binding requests would then operate something like: 3. Message = TID + TARGET-TID + ???? + MESSAGE-INTEGRITY using TARGET-OTP. 4. The server can recompute TARGET-OTP from TARGET-TID and send back: Message = TID + ???? + MESSAGE-INTEGRITY using TARGET-OTP. This seems a minor change. It looks slightly more secure to me (attackers can't ask for TARGET-OTP), it's more efficient in that the TARGET-TID and TARGET-OTP can be used for multiple requests, and the server doesn't require per client state. So how about it? Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: "Melinda Shore" To: Sent: 08 July 2002 15:19 Subject: [midcom] STUN last call > We are starting working group last call on STUN, ending > 22 July 2002. Please send any comments to the midcom mailing > list, along with an indication of whether or not you feel the > issue is serious enough to stop last call. > > Thanks, > > Melinda > > >To: IETF-Announce: ; > >Cc: midcom@ietf.org > >From: Internet-Drafts@ietf.org > >Reply-to: Internet-Drafts@ietf.org > >Date: Sun, 07 Jul 2002 12:10:15 -0400 > >Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-01.txt > >Sender: midcom-admin@ietf.org > >X-Mailman-Version: 1.0 > >List-Id: > >X-BeenThere: midcom@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > >This draft is a work item of the Middlebox Communication Working Group of the IETF. > > > > Title : STUN - Simple Traversal of UDP Through Network Address > > Translators > > Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy > > Filename : draft-ietf-midcom-stun-01.txt > > Pages : 42 > > Date : 05-Jul-02 > > > >Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol > >that allows applications to discover the presence and types of > >Network Address Translators (NATs) and firewalls between them and the > >public Internet. It also provides the ability for applications to > >determine the public IP addresses allocated to them by the NAT. STUN > >works with many existing NATs, and does not require any special > >behavior from them. As a result, it allows a wide variety of > >applications to work through existing NAT infrastructure. The STUN > >protocol is simple, being almost identical to echo. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt > > > >To remove yourself from the IETF Announcement list, send a message to > >ietf-announce-request with the word unsubscribe in the body of the message. > > > >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-ietf-midcom-stun-01.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-ietf-midcom-stun-01.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. > >Content-Type: text/plain > >Content-ID: <20020705142202.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-ietf-midcom-stun-01.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 From daemon@optimus.ietf.org Tue Jul 23 12:45:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22553 for ; Tue, 23 Jul 2002 12:45:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27620 for midcom-archive@odin.ietf.org; Tue, 23 Jul 2002 12:46:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27412; Tue, 23 Jul 2002 12:44:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27382 for ; Tue, 23 Jul 2002 12:44:54 -0400 (EDT) Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22370 for ; Tue, 23 Jul 2002 12:43:52 -0400 (EDT) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id MAA11675; Tue, 23 Jul 2002 12:41:59 -0400 (EDT) Subject: RE: [midcom] Last call reminder To: "Yutaka Takeda" Cc: midcom@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Tue, 23 Jul 2002 12:40:48 -0400 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 07/23/2002 12:42:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We experianced the same issue using our implementation (http://www.columbia.edu/~pt81/cs6901-08/cs6901-08.html) After the initial STUN discover (requests/responses) the NAT device maintains state of the connection for a predifined period of time. For example fpr a Linux firewall configured as NAT the UDP connections are maintained for about 3 minutes. The TCP conections are maintained for much longer, a little over 10 minutes or so. Indeed this can be an issue, but I believe that the assumption is that the discovery algorithm provides all the steps to identify correctly your NAT configuration the first time. If you like to verify the results you can send your STUN requests to a new STUN server with different IP address _AND_ different port. But since the port is most likely to be standardized down the road by IANA, sending your STUN requests to a new STUN server will help resolve this issue. Peter Thermos "Yutaka Takeda" on 07/23/2002 01:25:27 AM To: midcom@ietf.org cc: (bcc: Panayiotis A. Thermos/Telcordia) Subject: RE: [midcom] Last call reminder Depending on the implementation, STUN client likely re-tries the discovery process to make sure the result was correct. In such a case, I have observed one problem when it was 'Restricted cone NAT'. In the first discovery process, it results in Restricted NAT. And then, STUN client re-tries the one from the same port. In Test II after knowing that it is natted with Test I, STUN client receives a response and ends up with wrong result of Full-cone NAT. This happens because STUN client has already sent a packet to the secondary IP (Ca) in Test I (to Ca) in the first discovery process. To prevent this, the following workaround can be taken. - Prepare more than one port for STUN discovery process. - Perform each process with different port number. This is an implementation issue, however, it is good to point out this and conduct implementers to take a workaround described above in case implementers want to re-try the process. ------------------------------ Yutaka Takeda - Project Leader Kyushu Matsushita Electric Research Laboratory of Panasonic Technologies Company A Division of Matsushita Electric Corporation of America Tel: 858-485-4692, Fax: 858-485-6647 E-mail: takeday@kmerl.com > -----Original Message----- > From: mshore@cisco.com [mailto:mshore@cisco.com] > Sent: Monday, July 22, 2002 5:41 AM > To: midcom@ietf.org > Subject: [midcom] Last call reminder > > > The STUN draft is in WG last call, which closes on Wednesday > the 24th. Speak now or forever hold your peace. > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt > > 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 daemon@optimus.ietf.org Tue Jul 23 12:50:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22847 for ; Tue, 23 Jul 2002 12:50:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27869 for midcom-archive@odin.ietf.org; Tue, 23 Jul 2002 12:51:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27814; Tue, 23 Jul 2002 12:50:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27768 for ; Tue, 23 Jul 2002 12:50:42 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22764 for ; Tue, 23 Jul 2002 12:49:39 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 09:50:11 -0700 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Jul 2002 09:50:11 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 23 Jul 2002 09:50:10 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 09:50:10 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 23 Jul 2002 09:49:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN last call Date: Tue, 23 Jul 2002 09:49:28 -0700 Message-ID: Thread-Topic: [midcom] STUN last call Thread-Index: AcIySP+3A1Q0zIPmREqSjLhmIvIYrwAHkNGA From: "Christian Huitema" To: "Pete Cordell" , , "Melinda Shore" X-OriginalArrivalTime: 23 Jul 2002 16:49:29.0031 (UTC) FILETIME=[E9346D70:01C23268] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA27782 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Pete's idea makes sense, but there are a few issues. It really is a trade-off between security and ease of operation. > My main concern is that the default security mechanisms > require the server > to be stateful. This is undesirable and I think it can be > avoided with only > minor changes. This would involve the server supplying the TARGET-TID > instead of the client. The following sequence would result: > > 1. Client sends shared secret request over TLS. > > 2. Server returns TARGET-TID and corresponding TARGET-OTP to client. > The server can generate these as: > > TARGET-TID = random; > TARGET-OTP = HMAC_?( server_secret, TARGET-TID ); > > Being algorithmically related, a server does not need state. > Because both > are supplied by the server, an attacker can't request the TARGET-OTP > corresponding to a particular TARGET-TID. This is one possible implementation. In fact, the current spec links the "target-otp" to the client supplied transaction-id, TARGET-TID, which means that you can implement the server exactly the same way: target-otp = one-way-hash(server_secret, TARGET-TID) This means that the server does not have to be stateful. The difference between the current draft and Pete's proposal is really the lifetime of the "target-otp": in the draft, we make it one transaction; in Pete's proposal, there would be some long lasting "server supplied user-name", and the secret would remain valid that long. Pete's proposal also have the advantage of using server supplied TID, while the draft's proposal might open the way for some clever attacks in which the client chooses the "right" TID values. The problem with a long-lasting secret is the need to recycle them eventually, e.g. when the "server secret" changes. I presume that this could be detected by an optimistic procedure: try to use the old account + secret, and if that fails, go get a new secret. We would need to specify that too. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Jul 23 13:58:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26639 for ; Tue, 23 Jul 2002 13:58:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03248 for midcom-archive@odin.ietf.org; Tue, 23 Jul 2002 13:59:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03021; Tue, 23 Jul 2002 13:58:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02989 for ; Tue, 23 Jul 2002 13:58:16 -0400 (EDT) Received: from oak.Research.Panasonic.COM (oak.Research.Panasonic.COM [150.169.1.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26538 for ; Tue, 23 Jul 2002 13:57:14 -0400 (EDT) Received: from mastodon.kmerl.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.Research.Panasonic.COM (8.11.6+Sun/8.10.2) with ESMTP id g6NHvjB14481 for ; Tue, 23 Jul 2002 13:57:45 -0400 (EDT) Received: from tornado.kmerl.com (firebox [150.169.11.2]) by mastodon.kmerl.research.panasonic.com (8.10.2+Sun/8.10.2) with ESMTP id g6NHnxc03785 for ; Tue, 23 Jul 2002 13:49:59 -0400 (EDT) Subject: RE: [midcom] Last call reminder MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 23 Jul 2002 10:57:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Message-ID: Thread-Topic: [midcom] Last call reminder Thread-Index: AcIyaDNsAKizhb8JTHi34kGDBD2KawAAvirQ From: "Yutaka Takeda" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA02990 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Regarding the re-try of discovery process, what I proposed to do to this issue was still using the same port number that IANA would assign for STUN server... For the subsequent discovery process, STUN client can use different 'source' port number of the local device to send a STUN request to the same port number (likely to be the default 3478) of the STUN server. This way, the NAT device newly creates the binding table so that previous process will not affect to the new result. If the result falls into 'Full-cone' where it should be 'Restricted-cone', application might decide not to send a packet to prime the NAT at the actual UDP port to receive incoming packets. Since it is actually a Restricted-cone NAT, incoming packet will nerver reach local device. Considering the device may re-boot within a short time, it should be something that implementers have to be aware of... Yutaka Takeda > -----Original Message----- > From: Panayiotis A. Thermos [mailto:pthermos@telcordia.com] > Sent: Tuesday, July 23, 2002 9:41 AM > To: Yutaka Takeda > Cc: midcom@ietf.org > Subject: RE: [midcom] Last call reminder > > > > > We experianced the same issue using our implementation > (http://www.columbia.edu/~pt81/cs6901-08/cs6901-08.html) > > After the initial STUN discover (requests/responses) the NAT device > maintains state of the connection for a predifined period of time. > > For example fpr a Linux firewall configured as NAT the UDP connections > are maintained for about 3 minutes. The TCP conections are maintained > for much longer, a little over 10 minutes or so. > > Indeed this can be an issue, but I believe that the > assumption is that the > discovery algorithm provides all the steps to identify > correctly your NAT > configuration the first time. > > If you like to verify the results you can send your STUN > requests to a new > STUN server with different IP address _AND_ different port. > But since the > port is most likely to be standardized down the road by IANA, > sending your > STUN requests to a new STUN server will help resolve this issue. > > > Peter Thermos > > > > > > > > "Yutaka Takeda" on 07/23/2002 01:25:27 AM > > To: midcom@ietf.org > cc: (bcc: Panayiotis A. Thermos/Telcordia) > Subject: RE: [midcom] Last call reminder > > > > Depending on the implementation, STUN client likely re-tries the > discovery process to make sure the result was correct. In such > a case, I have observed one problem when it was 'Restricted > cone NAT'. > > In the first discovery process, it results in Restricted NAT. And > then, STUN client re-tries the one from the same port. In Test II > after knowing that it is natted with Test I, STUN client receives > a response and ends up with wrong result of Full-cone NAT. This > happens because STUN client has already sent a packet to the > secondary IP (Ca) in Test I (to Ca) in the first discovery process. > > To prevent this, the following workaround can be taken. > > - Prepare more than one port for STUN discovery process. > - Perform each process with different port number. > > This is an implementation issue, however, it is good to point out > this and conduct implementers to take a workaround > described above in case implementers want to re-try the process. > > ------------------------------ > Yutaka Takeda - Project Leader > Kyushu Matsushita Electric Research Laboratory > of Panasonic Technologies Company > A Division of Matsushita Electric Corporation of America > Tel: 858-485-4692, Fax: 858-485-6647 > E-mail: takeday@kmerl.com > > > > -----Original Message----- > > From: mshore@cisco.com [mailto:mshore@cisco.com] > > Sent: Monday, July 22, 2002 5:41 AM > > To: midcom@ietf.org > > Subject: [midcom] Last call reminder > > > > > > The STUN draft is in WG last call, which closes on Wednesday > > the 24th. Speak now or forever hold your peace. > > > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt > > > > 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 daemon@ns.ietf.org Tue Jul 23 14:05:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26958 for ; Tue, 23 Jul 2002 14:05:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04313 for midcom-archive@odin.ietf.org; Tue, 23 Jul 2002 14:06:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04204; Tue, 23 Jul 2002 14:05:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04175 for ; Tue, 23 Jul 2002 14:05:04 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26878 for ; Tue, 23 Jul 2002 14:04:01 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6NI4QOu004599; Tue, 23 Jul 2002 11:04:26 -0700 (PDT) Received: from fluffyw2k (dhcp-128-107-209-123.cisco.com [128.107.209.123]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADN25102; Tue, 23 Jul 2002 11:04:47 -0700 (PDT) From: "Cullen Jennings" To: "Christian Huitema" , "Pete Cordell" , Subject: RE: [midcom] STUN last call Date: Tue, 23 Jul 2002 11:04:31 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit It is important for the security that the OTP is not valid for a long time. I agree with Pete that we want to be able to build a stateless server but as Christian correctly points out below, it is possible to make a stateless server without any changes to the current draft. Cullen > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Christian Huitema > Sent: Tuesday, July 23, 2002 9:49 AM > To: Pete Cordell; midcom@ietf.org; Melinda Shore > Subject: RE: [midcom] STUN last call > > > Pete's idea makes sense, but there are a few issues. It really is a > trade-off between security and ease of operation. > > > My main concern is that the default security mechanisms > > require the server > > to be stateful. This is undesirable and I think it can be > > avoided with only > > minor changes. This would involve the server supplying the TARGET-TID > > instead of the client. The following sequence would result: > > > > 1. Client sends shared secret request over TLS. > > > > 2. Server returns TARGET-TID and corresponding TARGET-OTP to client. > > The server can generate these as: > > > > TARGET-TID = random; > > TARGET-OTP = HMAC_?( server_secret, TARGET-TID ); > > > > Being algorithmically related, a server does not need state. > > Because both > > are supplied by the server, an attacker can't request the TARGET-OTP > > corresponding to a particular TARGET-TID. > > This is one possible implementation. In fact, the current spec links the > "target-otp" to the client supplied transaction-id, TARGET-TID, which > means that you can implement the server exactly the same way: > > target-otp = one-way-hash(server_secret, TARGET-TID) > > This means that the server does not have to be stateful. The difference > between the current draft and Pete's proposal is really the lifetime of > the "target-otp": in the draft, we make it one transaction; in Pete's > proposal, there would be some long lasting "server supplied user-name", > and the secret would remain valid that long. Pete's proposal also have > the advantage of using server supplied TID, while the draft's proposal > might open the way for some clever attacks in which the client chooses > the "right" TID values. > > The problem with a long-lasting secret is the need to recycle them > eventually, e.g. when the "server secret" changes. I presume that this > could be detected by an optimistic procedure: try to use the old account > + secret, and if that fails, go get a new secret. We would need to > specify that too. > > -- Christian Huitema > > > _______________________________________________ > 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 daemon@ns.ietf.org Tue Jul 23 14:21:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27597 for ; Tue, 23 Jul 2002 14:21:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05172 for midcom-archive@odin.ietf.org; Tue, 23 Jul 2002 14:22:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05104; Tue, 23 Jul 2002 14:21:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05080 for ; Tue, 23 Jul 2002 14:21:09 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27552 for ; Tue, 23 Jul 2002 14:20:06 -0400 (EDT) From: mshore@cisco.com Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6NIKcqI002824 for ; Tue, 23 Jul 2002 11:20:38 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEO68970; Tue, 23 Jul 2002 11:16:37 -0700 (PDT) Message-Id: <200207231816.AEO68970@mira-sjc5-4.cisco.com> To: midcom@ietf.org Subject: Re: [midcom] Last call reminder In-Reply-To: Message from "Yutaka Takeda" of "Tue, 23 Jul 2002 10:57:44 PDT." Date: Tue, 23 Jul 2002 14:19:06 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Thanks very much to everybody for going through the document with such care. Just to clarify, it's my sense that most of what's been discussed in the past few days is editorial in nature (can be corrected in the document without going through WG last call again), rather than something that would prevent the document from being sent on to the IESG. Does anybody feel otherwise? Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Jul 23 16:56:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04104 for ; Tue, 23 Jul 2002 16:56:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17291 for midcom-archive@odin.ietf.org; Tue, 23 Jul 2002 16:57:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17122; Tue, 23 Jul 2002 16:55:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17092 for ; Tue, 23 Jul 2002 16:55:47 -0400 (EDT) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03995 for ; Tue, 23 Jul 2002 16:54:38 -0400 (EDT) Received: from host213-1-186-247.in-addr.btopenworld.com ([213.1.186.247] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 17X6gh-000433-00; Tue, 23 Jul 2002 21:55:20 +0100 Message-ID: <026d01c2328b$74cf97c0$0200000a@tkw> From: "Pete Cordell" To: "Christian Huitema" , , "Melinda Shore" References: Subject: Re: [midcom] STUN last call Date: Tue, 23 Jul 2002 21:47:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Christian, (Glad it makes some sense. I'm only just starting to feel I understand this security stuff!) One question that might have a bearing on the way to go is, what would happen if you were using STUN to refresh the bindings in a NAT that didn't have any active media for some reason? Would you have to supply new TIDs each time and potentially exhaust the cache of TARGET-TID / TARGET-OTPs pairs you have collected, or would you use some other mechanism? (I guess a server having to MAC a response for which the client doesn't care about the contents of would be quite expensive for the server, so an alternative scheme might be desirable.) Pete. ----- Original Message ----- From: "Christian Huitema" To: "Pete Cordell" ; ; "Melinda Shore" Sent: 23 July 2002 17:49 Subject: RE: [midcom] STUN last call Pete's idea makes sense, but there are a few issues. It really is a trade-off between security and ease of operation. > My main concern is that the default security mechanisms > require the server > to be stateful. This is undesirable and I think it can be > avoided with only > minor changes. This would involve the server supplying the TARGET-TID > instead of the client. The following sequence would result: > > 1. Client sends shared secret request over TLS. > > 2. Server returns TARGET-TID and corresponding TARGET-OTP to client. > The server can generate these as: > > TARGET-TID = random; > TARGET-OTP = HMAC_?( server_secret, TARGET-TID ); > > Being algorithmically related, a server does not need state. > Because both > are supplied by the server, an attacker can't request the TARGET-OTP > corresponding to a particular TARGET-TID. This is one possible implementation. In fact, the current spec links the "target-otp" to the client supplied transaction-id, TARGET-TID, which means that you can implement the server exactly the same way: target-otp = one-way-hash(server_secret, TARGET-TID) This means that the server does not have to be stateful. The difference between the current draft and Pete's proposal is really the lifetime of the "target-otp": in the draft, we make it one transaction; in Pete's proposal, there would be some long lasting "server supplied user-name", and the secret would remain valid that long. Pete's proposal also have the advantage of using server supplied TID, while the draft's proposal might open the way for some clever attacks in which the client chooses the "right" TID values. The problem with a long-lasting secret is the need to recycle them eventually, e.g. when the "server secret" changes. I presume that this could be detected by an optimistic procedure: try to use the old account + secret, and if that fails, go get a new secret. We would need to specify that too. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 24 09:22:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15186 for ; Wed, 24 Jul 2002 09:22:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24444 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 09:23:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24407; Wed, 24 Jul 2002 09:21:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24376 for ; Wed, 24 Jul 2002 09:21:55 -0400 (EDT) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15076 for ; Wed, 24 Jul 2002 09:20:51 -0400 (EDT) Received: from host213-122-50-75.in-addr.btopenworld.com ([213.122.50.75] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #8) id 17XHBF-0003ke-00; Wed, 24 Jul 2002 09:07:33 +0100 Message-ID: <006201c232e9$680dd160$0200000a@tkw> From: "Pete Cordell" To: Cc: References: <200207221238.AEO24990@mira-sjc5-4.cisco.com> Subject: Re: [midcom] Last call reminder Date: Wed, 24 Jul 2002 09:08:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Here's some editorial errors I found when skimming through STUN. (I'm afraid I didn't give it a thorough read.) 8.1 (Clarity): If the STUN Shared Secret Request was used, the key MUST be the {one placed}->{TARGET-OTP} in a Shared Secret Response to a Shared Secret Request that had a TARGET-TID equal to the transaction identifier in the Binding Request. It would be nice to re-word this paragraph, but I've tried and it's difficult! Best I could do is below, but its not much of an improvement. If the STUN Shared Secret Request was used, the key MUST be the TARGET-OTP from the Shared Secret response corresponding to a to a Shared Secret Request containing a TARGET-TID equal to the transaction identifier of the Binding Request. 8.2 (Typo): SHOULD {prevent} -> {present} a site certificate ? 8.2 (Functional): 'The server MUST always return the same TARGET-OTP for two requests with the same TARGET-TID.' This sounds like a way that an attacker can learn the TARGET-OTP corresponding to a TARGET-TID. This could be useful in an attack. Also, stated as is, it does not allow the server to change the key generation mechanism (say a master secret) from one month to the next. 11.2.6 (Typo): TARGET-TID: Re: 'This MUST be equal to the transaction ID that will be used in Binding Requests that contain the shared secret learned from the exchange.' This doesn't seem right. Maybe it should be: This MUST be equal to the transaction ID that will be used in Binding Requests that {contain}->{are authenticated by} the shared secret learned from the exchange. (General (Clarity): Still think CHANGED-ADDRESS should be CHANGE-ADDRESS to ties in more closely with the text 'The fourth attribute is the CHANGE(D)-ADDRESS attribute. It is present in Binding Responses. It informs the client of the source IP address and port that would be used if the client requested the "change IP" and "change port" behavior.'. It also implies that the address has been changed, but in many cases it hasn't. It's readily confused with MAPPED-ADDRESS for the first time reader. It is possible for someone to mis-interpret CHANGE-ADDRESS, but being a verb type thing and then containing a description and appearing in a response readers can more readily dismiss those erroneous interpretations. But the world won't end if its not changed.) Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: To: Sent: 22 July 2002 13:40 Subject: [midcom] Last call reminder > The STUN draft is in WG last call, which closes on Wednesday > the 24th. Speak now or forever hold your peace. > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt > > 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 daemon@optimus.ietf.org Wed Jul 24 15:23:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28947 for ; Wed, 24 Jul 2002 15:23:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18497 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 15:24:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17616; Wed, 24 Jul 2002 15:12:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17585 for ; Wed, 24 Jul 2002 15:12:37 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28486 for ; Wed, 24 Jul 2002 15:11:33 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OJBNYH018011; Wed, 24 Jul 2002 15:11:23 -0400 (EDT) Message-ID: <3D3EFBDA.9050107@dynamicsoft.com> Date: Wed, 24 Jul 2002 15:11:22 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing CC: midcom@ietf.org Subject: Re: [midcom] Last call reminder References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Thanks for your comments. Responses inline. Dan Wing wrote: >>The STUN draft is in WG last call, which closes on Wednesday >>the 24th. Speak now or forever hold your peace. >> >>http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt > > > Two nits are that the I-D needs to have " nat" changed to " NAT", > and " stun" to " STUN". Fixed. Note that I have kept the verb "natted" all lowercase however. > > > Section 11.1, which defines the binary values of the various > messages, should indicate which hex values are undefined > and how they their use by an implementation should be correctly > documented (via an IANA registration or via a new RFC, or > both). It is my hope that new messages won't be needed, but I will add a sentence that says new ones can be defined in RFCs, and a server that receives a message it doesn't know about simply discards it. I noticed several other 11.* sections also don't > define how unused fields should be defined; perhaps 11.0 > can say something regarding the entire section. The spec talks about unknown attributes, unknown address families, and flags, all of which have defined behavior. For errors, the spec addresses unknown numbers, but not unknown classes. I'll add a sentence that says unknown classes are treated as 400. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 daemon@optimus.ietf.org Wed Jul 24 15:28:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29047 for ; Wed, 24 Jul 2002 15:28:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18725 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 15:29:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17976; Wed, 24 Jul 2002 15:19:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17936 for ; Wed, 24 Jul 2002 15:19:03 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28697 for ; Wed, 24 Jul 2002 15:17:58 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OJIWYH018017; Wed, 24 Jul 2002 15:18:32 -0400 (EDT) Message-ID: <3D3EFD87.3020803@dynamicsoft.com> Date: Wed, 24 Jul 2002 15:18:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing CC: midcom@ietf.org Subject: Re: [midcom] Last call reminder References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Dan Wing wrote: > Section 10.2, "Binding Lifetime Discovery", doesn't explain what > a client is supposed to do with this information. It's somewhat > obvious that a client would use this information to decide when > to send a keepalive packet (to keep the NAT binding active), but > it would be useful to point out the reason a client would want > to learn how long a binding remains active. I added the following text: STUN can also be used to discover the lifetimes of the bindings created by the NAT. In many cases, the client will need to refresh the binding, either through a new STUN request, or an application packet, in order for the application to continue to use the binding. By discovering the binding lifetime, the client can determine how frequently it needs to refresh. > > What needs to be discussed -- either in 10.2 or 14.3 ("Brittleness > Introduced by STUN") is that any learning of the binding lifetime > is only valuable if the NAT device doesn't release the binding > prematurely due to a reboot, exhaustion of UDP ports for new > connections, or other actions. Since the client doesn't own the binding, how does it release it? The only way it can be released is through inactivity in the NAT. A reboot of the client won't cause that; if it sends a STUn request on startup on the same local port/address, it will get the same public address back as long as it hasn't expired in the NATs. So, I do not see the issue here. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 daemon@optimus.ietf.org Wed Jul 24 15:35:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29279 for ; Wed, 24 Jul 2002 15:35:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19573 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 15:36:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18554; Wed, 24 Jul 2002 15:25:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18523 for ; Wed, 24 Jul 2002 15:25:39 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28965 for ; Wed, 24 Jul 2002 15:24:34 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OJP4YH018021; Wed, 24 Jul 2002 15:25:05 -0400 (EDT) Message-ID: <3D3EFF0F.20205@dynamicsoft.com> Date: Wed, 24 Jul 2002 15:25:03 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yutaka Takeda CC: midcom@ietf.org Subject: Re: [midcom] Last call reminder References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I agree that the best resolution is to use a different local socket for subsequent retries. I also agree that this is an implementation issue, but worth documenting. I added the following text: Typically, a client will re-do this discovery process periodically to detect changes, or look for inconsistent results. It is important to note that when the discovery process is redone, it should not generally be done from the same local address and port used in the previous discovery process. If the same local address and port are reused, bindings from the previous test may still be in existence, and these will invalidate the results of the test. Using a different local addres and port for subsequent tests resolves this problem. An alternative is to wait sufficiently long to be confident that the old bindings have expired (half an hour should more than suffice). Thanks, Jonathan R. Yutaka Takeda wrote: > Regarding the re-try of discovery process, what I proposed to do to > this issue was still using the same port number that IANA would > assign for STUN server... > > For the subsequent discovery process, STUN client can use different > 'source' port number of the local device to send a STUN request to > the same port number (likely to be the default 3478) of the STUN > server. This way, the NAT device newly creates the binding table > so that previous process will not affect to the new result. > > If the result falls into 'Full-cone' where it should be > 'Restricted-cone', > application might decide not to send a packet to prime the NAT at > the actual UDP port to receive incoming packets. Since it is > actually a Restricted-cone NAT, incoming packet will nerver reach > local device. > > Considering the device may re-boot within a short time, it should > be something that implementers have to be aware of... > > > Yutaka Takeda > > >>-----Original Message----- >>From: Panayiotis A. Thermos [mailto:pthermos@telcordia.com] >>Sent: Tuesday, July 23, 2002 9:41 AM >>To: Yutaka Takeda >>Cc: midcom@ietf.org >>Subject: RE: [midcom] Last call reminder >> >> >> >> >>We experianced the same issue using our implementation >>(http://www.columbia.edu/~pt81/cs6901-08/cs6901-08.html) >> >>After the initial STUN discover (requests/responses) the NAT device >>maintains state of the connection for a predifined period of time. >> >>For example fpr a Linux firewall configured as NAT the UDP connections >>are maintained for about 3 minutes. The TCP conections are maintained >>for much longer, a little over 10 minutes or so. >> >>Indeed this can be an issue, but I believe that the >>assumption is that the >>discovery algorithm provides all the steps to identify >>correctly your NAT >>configuration the first time. >> >>If you like to verify the results you can send your STUN >>requests to a new >>STUN server with different IP address _AND_ different port. >>But since the >>port is most likely to be standardized down the road by IANA, >>sending your >>STUN requests to a new STUN server will help resolve this issue. >> >> >>Peter Thermos >> >> >> >> >> >> >> >>"Yutaka Takeda" on 07/23/2002 01:25:27 AM >> >>To: midcom@ietf.org >>cc: (bcc: Panayiotis A. Thermos/Telcordia) >>Subject: RE: [midcom] Last call reminder >> >> >> >>Depending on the implementation, STUN client likely re-tries the >>discovery process to make sure the result was correct. In such >>a case, I have observed one problem when it was 'Restricted >>cone NAT'. >> >>In the first discovery process, it results in Restricted NAT. And >>then, STUN client re-tries the one from the same port. In Test II >>after knowing that it is natted with Test I, STUN client receives >>a response and ends up with wrong result of Full-cone NAT. This >>happens because STUN client has already sent a packet to the >>secondary IP (Ca) in Test I (to Ca) in the first discovery process. >> >>To prevent this, the following workaround can be taken. >> >>- Prepare more than one port for STUN discovery process. >>- Perform each process with different port number. >> >>This is an implementation issue, however, it is good to point out >>this and conduct implementers to take a workaround >>described above in case implementers want to re-try the process. >> >>------------------------------ >>Yutaka Takeda - Project Leader >>Kyushu Matsushita Electric Research Laboratory >>of Panasonic Technologies Company >>A Division of Matsushita Electric Corporation of America >>Tel: 858-485-4692, Fax: 858-485-6647 >>E-mail: takeday@kmerl.com >> >> >> >>>-----Original Message----- >>>From: mshore@cisco.com [mailto:mshore@cisco.com] >>>Sent: Monday, July 22, 2002 5:41 AM >>>To: midcom@ietf.org >>>Subject: [midcom] Last call reminder >>> >>> >>>The STUN draft is in WG last call, which closes on Wednesday >>>the 24th. Speak now or forever hold your peace. >>> >>>http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt >>> >>>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 > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 daemon@optimus.ietf.org Wed Jul 24 15:36:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29333 for ; Wed, 24 Jul 2002 15:36:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19602 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 15:37:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18665; Wed, 24 Jul 2002 15:27:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18637 for ; Wed, 24 Jul 2002 15:27:06 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28995 for ; Wed, 24 Jul 2002 15:26:01 -0400 (EDT) Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OJQSM2021814; Wed, 24 Jul 2002 12:26:28 -0700 (PDT) Received: from DWINGW2K4 (sjc-vpn2-774.cisco.com [10.21.115.6]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AFR55884; Wed, 24 Jul 2002 12:25:03 -0700 (PDT) From: "Dan Wing" To: "Jonathan Rosenberg" Cc: Subject: RE: [midcom] Last call reminder Date: Wed, 24 Jul 2002 12:26:27 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3D3EFD87.3020803@dynamicsoft.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > I added the following text: > > STUN can also be used to discover the lifetimes of the bindings > created by the NAT. In many cases, the client will need to refresh the > binding, either through a new STUN request, or an application packet, > in order for the application to continue to use the binding. By > discovering the binding lifetime, the client can determine how > frequently it needs to refresh. Thanks. > > What needs to be discussed -- either in 10.2 or 14.3 ("Brittleness > > Introduced by STUN") is that any learning of the binding lifetime > > is only valuable if the NAT device doesn't release the binding > > prematurely due to a reboot, exhaustion of UDP ports for new > > connections, or other actions. > > Since the client doesn't own the binding, how does it release it? The > only way it can be released is through inactivity in the NAT. You're tyinking of a reboot of the STUN client. I'm thinking of a reboot of the NAT itself -- the Linksys box, for example. This could be a result of a reset (to load new firmware), power failure, software fault, remote DoS, etc. > A reboot > of the client won't cause that; if it sends a STUn request on startup on > the same local port/address, it will get the same public address back as > long as it hasn't expired in the NATs. It's pretty unlikely it'll send a STUN request on startup using the same local port/address, but if you're expecting this, it's part of the brittleness of STUN and this expectation should be mentioned in the brittleness section. -d > So, I do not see the issue here. > > Thanks, > Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > 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 daemon@optimus.ietf.org Wed Jul 24 15:37:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29381 for ; Wed, 24 Jul 2002 15:37:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19666 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 15:39:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18856; Wed, 24 Jul 2002 15:30:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18821 for ; Wed, 24 Jul 2002 15:30:04 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29084 for ; Wed, 24 Jul 2002 15:28:59 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OJTXYH018027; Wed, 24 Jul 2002 15:29:33 -0400 (EDT) Message-ID: <3D3F001C.2080606@dynamicsoft.com> Date: Wed, 24 Jul 2002 15:29:32 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing CC: midcom@ietf.org Subject: Re: [midcom] Last call reminder References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Dan Wing wrote: >>>What needs to be discussed -- either in 10.2 or 14.3 ("Brittleness >>>Introduced by STUN") is that any learning of the binding lifetime >>>is only valuable if the NAT device doesn't release the binding >>>prematurely due to a reboot, exhaustion of UDP ports for new >>>connections, or other actions. >> >>Since the client doesn't own the binding, how does it release it? The >>only way it can be released is through inactivity in the NAT. > > > You're tyinking of a reboot of the STUN client. I'm thinking of a > reboot of the NAT itself -- the Linksys box, for example. This > could be a result of a reset (to load new firmware), power failure, > software fault, remote DoS, etc. Ah. I misunderstood. Yes, a reboot of the NAT could taint the binding lifetime results. I'll mention this in the section on lifetime discovery and in the brittleness section. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 daemon@optimus.ietf.org Wed Jul 24 17:34:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03230 for ; Wed, 24 Jul 2002 17:34:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27611 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 17:35:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26784; Wed, 24 Jul 2002 17:27:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26753 for ; Wed, 24 Jul 2002 17:27:28 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03100 for ; Wed, 24 Jul 2002 17:26:17 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OLQmYH018095; Wed, 24 Jul 2002 17:26:48 -0400 (EDT) Message-ID: <3D3F1B97.90107@dynamicsoft.com> Date: Wed, 24 Jul 2002 17:26:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Pete Cordell , midcom@ietf.org, Melinda Shore Subject: Re: [midcom] STUN last call References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit inline. Christian Huitema wrote: > Pete's idea makes sense, but there are a few issues. It really is a > trade-off between security and ease of operation. > > >>My main concern is that the default security mechanisms >>require the server >>to be stateful. This is undesirable and I think it can be >>avoided with only >>minor changes. This would involve the server supplying the TARGET-TID >>instead of the client. The following sequence would result: >> >>1. Client sends shared secret request over TLS. >> >>2. Server returns TARGET-TID and corresponding TARGET-OTP to client. >> The server can generate these as: >> >> TARGET-TID = random; >> TARGET-OTP = HMAC_?( server_secret, TARGET-TID ); >> >>Being algorithmically related, a server does not need state. >>Because both >>are supplied by the server, an attacker can't request the TARGET-OTP >>corresponding to a particular TARGET-TID. > > > This is one possible implementation. In fact, the current spec links the > "target-otp" to the client supplied transaction-id, TARGET-TID, which > means that you can implement the server exactly the same way: > > target-otp = one-way-hash(server_secret, TARGET-TID) > > This means that the server does not have to be stateful. The difference > between the current draft and Pete's proposal is really the lifetime of > the "target-otp": in the draft, we make it one transaction; in Pete's > proposal, there would be some long lasting "server supplied user-name", > and the secret would remain valid that long. Pete's proposal also have > the advantage of using server supplied TID, while the draft's proposal > might open the way for some clever attacks in which the client chooses > the "right" TID values. Actually, one need not be all that clever. An attacker will see a STUN request flow by. It knows the transaction ID of this request, since its there in the clear. So, it connects to the server, sends a shared secret request with that target TID, and gets back the shared secret. It will be the same one used to build the HMAC. So, it can now freely modify the request and reconstruct a valid HMAC for it. To avoid this attack, the OTP has to have the same properties as the session key that is used as part of the TLS connection; namely, it must be unguessable and be scoped to that particular connection. To achieve this, the server must hand out the target TID, as Pete has suggested, and furthermore, it must never hand out the same target TID for any two requests sent over different TLS connections. Unless anyone objects or can think of a reason that this logic is wrong, I will update the draft with these requirements. > > The problem with a long-lasting secret is the need to recycle them > eventually, e.g. when the "server secret" changes. I presume that this > could be detected by an optimistic procedure: try to use the old account > + secret, and if that fails, go get a new secret. We would need to > specify that too. The only requirement is that the server be able to obtain the shared secret from the TID within the timeframe over which the request will be sent. This should be on the order of a minute or two. The objective is not to allow a client to request TIDs and hold on to them for extensive periods of time. If you are worried about call setup delays for SIP, the TID acquisition can be done in parallel with the user input that results in the call. In the case of a sip hardphone, the minute the user picks up the phone, the phone can establish the TLS connection in preparation for obtaining TIDs. This process would normally complete before the user even presses the first button. As such, I will add text stating that the client cannot expect the TID and its associated OTP to be valid for more than 2 minutes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 daemon@optimus.ietf.org Wed Jul 24 17:38:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03280 for ; Wed, 24 Jul 2002 17:38:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27762 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 17:39:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26882; Wed, 24 Jul 2002 17:29:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26847 for ; Wed, 24 Jul 2002 17:29:47 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03154 for ; Wed, 24 Jul 2002 17:28:41 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OLTDYH018098; Wed, 24 Jul 2002 17:29:13 -0400 (EDT) Message-ID: <3D3F1C28.2000303@dynamicsoft.com> Date: Wed, 24 Jul 2002 17:29:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell CC: Christian Huitema , midcom@ietf.org, Melinda Shore Subject: Re: [midcom] STUN last call References: <026d01c2328b$74cf97c0$0200000a@tkw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Pete Cordell wrote: > Christian, > > (Glad it makes some sense. I'm only just starting to feel I understand > this > security stuff!) > > One question that might have a bearing on the way to go is, what would > happen if you were using STUN to refresh the bindings in a NAT that > didn't > have any active media for some reason? Would you have to supply new > TIDs > each time and potentially exhaust the cache of TARGET-TID / TARGET-OTPs > pairs you have collected, or would you use some other mechanism? As I have proposed in a separate email, to ensure a small lifetime for the passwords, you can't build up a cache of the TIDs and use them throughout the call. I have proposed 2 minutes as a lifetime. Thus, you would need to acquire new TIDs in this case. (I > guess a > server having to MAC a response for which the client doesn't care about > the > contents of would be quite expensive for the server, so an alternative > scheme might be desirable.) Why does the client not care? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 daemon@optimus.ietf.org Wed Jul 24 18:00:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03642 for ; Wed, 24 Jul 2002 18:00:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29188 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 18:01:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28166; Wed, 24 Jul 2002 17:53:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28139 for ; Wed, 24 Jul 2002 17:53:24 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03506 for ; Wed, 24 Jul 2002 17:52:18 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 14:52:50 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 14:52:50 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 14:52:50 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 14:52:50 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 24 Jul 2002 14:52:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN last call Date: Wed, 24 Jul 2002 14:52:01 -0700 Message-ID: Thread-Topic: [midcom] STUN last call Thread-Index: AcIzWLdmN3I263lGQSCcpab4O44bSgAA1O3Q From: "Christian Huitema" To: "Jonathan Rosenberg" Cc: "Pete Cordell" , , "Melinda Shore" X-OriginalArrivalTime: 24 Jul 2002 21:52:48.0318 (UTC) FILETIME=[733CFDE0:01C2335C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA28140 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > To avoid this attack, the OTP has to have the same properties as the > session key that is used as part of the TLS connection; > namely, it must > be unguessable and be scoped to that particular connection. > To achieve > this, the server must hand out the target TID, as Pete has suggested, > and furthermore, it must never hand out the same target TID > for any two > requests sent over different TLS connections. > > Unless anyone objects or can think of a reason that this > logic is wrong, > I will update the draft with these requirements. I you go on updating the draft, then you should divorce the two roles of the TID, identifying the transaction for matching questions and responses, and identifying the key used for securing the transaction. If the key is valid for 2 minutes, it will probably be used for several transactions -- RTP and RTCP channels for audio and video comes to mind. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 24 18:20:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04191 for ; Wed, 24 Jul 2002 18:20:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00104 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 18:21:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29686; Wed, 24 Jul 2002 18:13:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29654 for ; Wed, 24 Jul 2002 18:13:07 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03900 for ; Wed, 24 Jul 2002 18:12:02 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OMCYYH018146; Wed, 24 Jul 2002 18:12:34 -0400 (EDT) Message-ID: <3D3F2651.1040008@dynamicsoft.com> Date: Wed, 24 Jul 2002 18:12:33 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Pete Cordell , midcom@ietf.org, Melinda Shore Subject: Re: [midcom] STUN last call References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema wrote: >>To avoid this attack, the OTP has to have the same properties as the >>session key that is used as part of the TLS connection; >>namely, it must >>be unguessable and be scoped to that particular connection. >>To achieve >>this, the server must hand out the target TID, as Pete has suggested, >>and furthermore, it must never hand out the same target TID >>for any two >>requests sent over different TLS connections. >> >>Unless anyone objects or can think of a reason that this >>logic is wrong, >>I will update the draft with these requirements. > > > I you go on updating the draft, then you should divorce the two roles of > the TID, identifying the transaction for matching questions and > responses, and identifying the key used for securing the transaction. If > the key is valid for 2 minutes, it will probably be used for several > transactions -- RTP and RTCP channels for audio and video comes to mind. So, you would propose a server-provided username, which would be valid for 2 minutes, which would be included in the binding request? The server would then supply the username and the OTP to a client in the Shared Secret Response message. I like this better. We could also allow the server to specify the lifetime of the username in the shared secret response, allowing for longer lived values than 2 minutes. Not sure if its worth the added complexity... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 daemon@optimus.ietf.org Wed Jul 24 19:25:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05572 for ; Wed, 24 Jul 2002 19:25:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA03550 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 19:26:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03316; Wed, 24 Jul 2002 19:18:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03285 for ; Wed, 24 Jul 2002 19:18:26 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05391 for ; Wed, 24 Jul 2002 19:17:22 -0400 (EDT) Received: from BOBP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A5BF3B42013E; Wed, 24 Jul 2002 19:18:23 -0400 Message-ID: <000701c23368$67bd9bd0$2300000a@BOBP> From: "Bob Penfield" To: "Jonathan Rosenberg" , "Christian Huitema" Cc: "Pete Cordell" , , "Melinda Shore" References: <3D3F2651.1040008@dynamicsoft.com> Subject: Re: [midcom] STUN last call Date: Wed, 24 Jul 2002 19:18:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jonathan Rosenberg" > > Christian Huitema wrote: > >>To avoid this attack, the OTP has to have the same properties as the > >>session key that is used as part of the TLS connection; > >>namely, it must > >>be unguessable and be scoped to that particular connection. > >>To achieve > >>this, the server must hand out the target TID, as Pete has suggested, > >>and furthermore, it must never hand out the same target TID > >>for any two > >>requests sent over different TLS connections. > >> > >>Unless anyone objects or can think of a reason that this > >>logic is wrong, > >>I will update the draft with these requirements. > > > > > > I you go on updating the draft, then you should divorce the two roles of > > the TID, identifying the transaction for matching questions and > > responses, and identifying the key used for securing the transaction. If > > the key is valid for 2 minutes, it will probably be used for several > > transactions -- RTP and RTCP channels for audio and video comes to mind. > > So, you would propose a server-provided username, which would be valid > for 2 minutes, which would be included in the binding request? The > server would then supply the username and the OTP to a client in the > Shared Secret Response message. I like this better. > > We could also allow the server to specify the lifetime of the username > in the shared secret response, allowing for longer lived values than 2 > minutes. Not sure if its worth the added complexity... Would the TID be the username? If so, would you then have to add a separate transaction id for matching requests and responses using the same TID and shared secret? Also, would you get better replay protection by including both the username and transaction id in the HMAC of the MESSAGE-INTEGRITY? cheers, (-:bob _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 24 19:53:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06312 for ; Wed, 24 Jul 2002 19:53:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA05351 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 19:54:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05002; Wed, 24 Jul 2002 19:47:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04971 for ; Wed, 24 Jul 2002 19:47:06 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06172 for ; Wed, 24 Jul 2002 19:46:02 -0400 (EDT) Received: from BOBP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AC7A8E17005C; Wed, 24 Jul 2002 19:47:06 -0400 Message-ID: <004101c2336c$6b06af80$2300000a@BOBP> From: "Bob Penfield" To: "Jonathan Rosenberg" Cc: References: <3D3F2651.1040008@dynamicsoft.com> Date: Wed, 24 Jul 2002 19:47:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] A few STUN nits Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit In section 8.1, 3rd paragraph, the last sentence says "The Binding Error Response is sent to the source IP address and port the Binding Request came from, and sent from the source IP address and port the Binding Request was sent to." This sentence is a bit confusing. Should the second "source IP address" be "destination" address. Or should the word "source" be dropped in both places. In section 10.3, 4th paragraph (1st on page 22), it says "This request contains a RESPONSE-ADDRESS, which is set to that mapped address learned from the previous Binding Response." Should "set to that" be "set to the"? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 24 21:00:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08129 for ; Wed, 24 Jul 2002 21:00:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA09801 for midcom-archive@odin.ietf.org; Wed, 24 Jul 2002 21:01:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08797; Wed, 24 Jul 2002 20:51:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08722 for ; Wed, 24 Jul 2002 20:51:47 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07861 for ; Wed, 24 Jul 2002 20:50:44 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 17:51:05 -0700 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 17:51:18 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 17:51:14 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 17:51:14 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 24 Jul 2002 17:51:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN last call Date: Wed, 24 Jul 2002 17:51:28 -0700 Message-ID: Thread-Topic: [midcom] STUN last call Thread-Index: AcIzXxow9iaszIpySO2+cS9LyIvqMwAFgsGQ From: "Christian Huitema" To: "Jonathan Rosenberg" Cc: "Pete Cordell" , , "Melinda Shore" X-OriginalArrivalTime: 25 Jul 2002 00:51:13.0587 (UTC) FILETIME=[60136830:01C23375] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA08723 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > > I you go on updating the draft, then you should divorce the > two roles of > > the TID, identifying the transaction for matching questions and > > responses, and identifying the key used for securing the > transaction. If > > the key is valid for 2 minutes, it will probably be used for several > > transactions -- RTP and RTCP channels for audio and video > comes to mind. > > So, you would propose a server-provided username, which would > be valid > for 2 minutes, which would be included in the binding request? The > server would then supply the username and the OTP to a client in the > Shared Secret Response message. I like this better. Yes. I guess that is exactly what Pete asked for... I would rather you call it "key-id" that "username". The server does not know who the user it. > We could also allow the server to specify the lifetime of the > username > in the shared secret response, allowing for longer lived > values than 2 > minutes. Not sure if its worth the added complexity... Don't go there! -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jul 25 02:11:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24081 for ; Thu, 25 Jul 2002 02:11:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01630 for midcom-archive@odin.ietf.org; Thu, 25 Jul 2002 02:12:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01225; Thu, 25 Jul 2002 02:00:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01185 for ; Thu, 25 Jul 2002 02:00:57 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14972 for ; Thu, 25 Jul 2002 01:59:51 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6P60JYH018279; Thu, 25 Jul 2002 02:00:20 -0400 (EDT) Message-ID: <3D3F93F0.2030909@dynamicsoft.com> Date: Thu, 25 Jul 2002 02:00:16 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield CC: Christian Huitema , Pete Cordell , midcom@ietf.org, Melinda Shore Subject: Re: [midcom] STUN last call References: <000701c23368$67bd9bd0$2300000a@BOBP> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit inline. Bob Penfield wrote: > ----- Original Message ----- > From: "Jonathan Rosenberg" > >>Christian Huitema wrote: >> >>>>To avoid this attack, the OTP has to have the same properties as the >>>>session key that is used as part of the TLS connection; >>>>namely, it must >>>>be unguessable and be scoped to that particular connection. >>>>To achieve >>>>this, the server must hand out the target TID, as Pete has >>> > suggested, > >>>>and furthermore, it must never hand out the same target TID >>>>for any two >>>>requests sent over different TLS connections. >>>> >>>>Unless anyone objects or can think of a reason that this >>>>logic is wrong, >>>>I will update the draft with these requirements. >>> >>> >>>I you go on updating the draft, then you should divorce the two >> > roles of > >>>the TID, identifying the transaction for matching questions and >>>responses, and identifying the key used for securing the >> > transaction. If > >>>the key is valid for 2 minutes, it will probably be used for several >>>transactions -- RTP and RTCP channels for audio and video comes to >> > mind. > >>So, you would propose a server-provided username, which would be valid >>for 2 minutes, which would be included in the binding request? The >>server would then supply the username and the OTP to a client in the >>Shared Secret Response message. I like this better. >> >>We could also allow the server to specify the lifetime of the username >>in the shared secret response, allowing for longer lived values than 2 >>minutes. Not sure if its worth the added complexity... > > > Would the TID be the username? No. This was exactly what Christian was saying - decouple them. > If so, would you then have to add a > separate > transaction id for matching requests and responses using the same TID > and > shared secret? Also, would you get better replay protection by including > both the username and transaction id in the HMAC of the > MESSAGE-INTEGRITY? No doubt. Everything is going to be HMACd. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 daemon@optimus.ietf.org Thu Jul 25 02:11:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24084 for ; Thu, 25 Jul 2002 02:11:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01641 for midcom-archive@odin.ietf.org; Thu, 25 Jul 2002 02:12:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00723; Thu, 25 Jul 2002 01:59:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00695 for ; Thu, 25 Jul 2002 01:58:53 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14909 for ; Thu, 25 Jul 2002 01:57:47 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.194]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6P5w0YH018276; Thu, 25 Jul 2002 01:58:01 -0400 (EDT) Message-ID: <3D3F9365.20705@dynamicsoft.com> Date: Thu, 25 Jul 2002 01:57:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Pete Cordell , midcom@ietf.org, Melinda Shore Subject: Re: [midcom] STUN last call References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit inline. Christian Huitema wrote: >>>I you go on updating the draft, then you should divorce the >> >>two roles of >> >>>the TID, identifying the transaction for matching questions and >>>responses, and identifying the key used for securing the >> >>transaction. If >> >>>the key is valid for 2 minutes, it will probably be used for several >>>transactions -- RTP and RTCP channels for audio and video >> >>comes to mind. >> >>So, you would propose a server-provided username, which would >>be valid >>for 2 minutes, which would be included in the binding request? The >>server would then supply the username and the OTP to a client in the >>Shared Secret Response message. I like this better. > > > Yes. I guess that is exactly what Pete asked for... > I would rather you call it "key-id" that "username". The server does not > know who the user it. Not in this case, no. However, Cullen Jennings had asked, during the midcom meeting, for the addition of a "username" attribute, optionally present in bind requests, to handle the eventual usage of non-TLS based shared secret mechanisms (i.e., a securid key or something). Seems like we can just use that field for this purpose. > > >>We could also allow the server to specify the lifetime of the >>username >>in the shared secret response, allowing for longer lived >>values than 2 >>minutes. Not sure if its worth the added complexity... > > > Don't go there! OK. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 daemon@optimus.ietf.org Thu Jul 25 09:31:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03300 for ; Thu, 25 Jul 2002 09:31:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27965 for midcom-archive@odin.ietf.org; Thu, 25 Jul 2002 09:32:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27191; Thu, 25 Jul 2002 09:27:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27159 for ; Thu, 25 Jul 2002 09:27:12 -0400 (EDT) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02891 for ; Thu, 25 Jul 2002 09:26:09 -0400 (EDT) Received: from host213-122-185-254.in-addr.btopenworld.com ([213.122.185.254] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 17Xie0-00052R-00; Thu, 25 Jul 2002 14:27:05 +0100 Message-ID: <008201c233df$2ae26980$0200000a@tkw> From: "Pete Cordell" To: "Christian Huitema" , "Jonathan Rosenberg" Cc: , "Melinda Shore" References: Subject: Re: [midcom] STUN last call Date: Thu, 25 Jul 2002 14:20:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Christian Huitema" > We could also allow the server to specify the lifetime of the > username > in the shared secret response, allowing for longer lived > values than 2 > minutes. Not sure if its worth the added complexity... Don't go there! -- Christian Huitema If we have a username or keyid that can be used multiple times, but we don't want dynamic lifetimes, can we make the minimum lifetime of the keyid longer, say 24 hours. In my mind creating a TLS connection per STUN request (as a first approximation) seems a lot of work for the server. There's various DH keys to be generated, public key operations, various key material expansion, cryto on the messages, numerous round trips etc. I figure a TLS connection could consume maybe 4 or more times more processing than a STUN binding request. As a 16 byte key-id and key seems stronger than many user-id/passwords protecting data on the net, a longer period would seem beneficial to some servers without an major down side. (Actually, I think a server specified lifetime doesn't sound that bad. For the server it can effectively be fixed text that it outputs. The client could either use it or ignore it. - Easiest way would be to use volatile store for the lifetime and key info. If it re-booted within the lifetime, it would just get a new key.) Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jul 25 09:31:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03316 for ; Thu, 25 Jul 2002 09:31:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28003 for midcom-archive@odin.ietf.org; Thu, 25 Jul 2002 09:32:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27224; Thu, 25 Jul 2002 09:27:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27197 for ; Thu, 25 Jul 2002 09:27:17 -0400 (EDT) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02899 for ; Thu, 25 Jul 2002 09:26:14 -0400 (EDT) Received: from host213-122-185-254.in-addr.btopenworld.com ([213.122.185.254] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 17Xie2-00052R-00; Thu, 25 Jul 2002 14:27:06 +0100 Message-ID: <008301c233df$2bed70e0$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: "Christian Huitema" , , "Melinda Shore" References: <026d01c2328b$74cf97c0$0200000a@tkw> <3D3F1C28.2000303@dynamicsoft.com> Subject: Re: [midcom] STUN last call Date: Thu, 25 Jul 2002 14:26:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jonathan Rosenberg" > (I > > guess a > > server having to MAC a response for which the client doesn't care about > > the > > contents of would be quite expensive for the server, so an alternative > > scheme might be desirable.) > > Why does the client not care? > You're right - It would only not care that the answer was unauthenticated if the answer it got was the same as the previous authenticated answer. If it got a different answer, then it would care very much (NAT might have re-booted). Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jul 25 12:43:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11717 for ; Thu, 25 Jul 2002 12:43:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10992 for midcom-archive@odin.ietf.org; Thu, 25 Jul 2002 12:44:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10864; Thu, 25 Jul 2002 12:41:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10833 for ; Thu, 25 Jul 2002 12:41:42 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11621 for ; Thu, 25 Jul 2002 12:40:36 -0400 (EDT) From: mshore@cisco.com Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6PGfBqI018231 for ; Thu, 25 Jul 2002 09:41:11 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEP32792; Thu, 25 Jul 2002 09:37:11 -0700 (PDT) Message-Id: <200207251637.AEP32792@mira-sjc5-4.cisco.com> To: midcom@ietf.org Date: Thu, 25 Jul 2002 12:39:35 -0400 Subject: [midcom] STUN WG last call closed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org It looks like we've gotten another document through WG last call (whew!) with a number of editorial comments but no show-stoppers. Many thanks for the scrutiny and the comments. The next step is for the editorial comments to be integrated into the document, after which it will be submitted to the IESG for their review. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jul 26 16:56:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08342 for ; Fri, 26 Jul 2002 16:56:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21793 for midcom-archive@odin.ietf.org; Fri, 26 Jul 2002 16:57:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21664; Fri, 26 Jul 2002 16:54:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21641 for ; Fri, 26 Jul 2002 16:54:21 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08267 for ; Fri, 26 Jul 2002 16:53:15 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6QKs3X24783 for ; Fri, 26 Jul 2002 15:54:03 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 15:53:49 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C7C8@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Fri, 26 Jul 2002 15:53:39 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] MIDCOM Protocol Evaluation - Proposed changes to SNMP - Section 1 .1.3 - para 2 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi all, This is the change that I propose to make to Section 1.1.3, paragraph 2 with regards to clarifying the model applied to the SNMP evaluation. Old Text (from draft-ietf-midcom-protocol-eval-02.txt): "The SNMP use of the term agent is different from its use in the Midcom framework: The SNMP Manager corresponds to the Midcom agent and the SNMP Agent corresponds to the Middlebox." Proposed New Text: "The SNMP use of the term agent differs from its use in the Midcom framework: The SNMP Manager corresponds to the Midcom agent and the SNMP Agent corresponds to the MIDCOM PDP. The SNMP evaluation assumes that the MIDCOM PDP is physically part of the middlebox, which is allowed by the MIDCOM framework and described in section 6.0 of [2]. Thus, for the purpose of this evaluation, the SNMP agent corresponds to the Middlebox." *************** Although comments on the overall document will be accepted through August 2nd, I would like to request that feedback on this proposed change be provided by 6PM CST Tuesday (30 July) so that we can address any concerns prior to the 2nd; with no response meaning that the proposed text is OK. *************** Thanks, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 ------------------------ For those not familiar with the motivation for this change, a change had been made in the -02 version, as resolution of mailing list discussion, to replace the use of "MIDCOM PDP" with "Middlebox" throughout the SNMP evaluation. The original statement in the -01 version of the protocol evaluation draft and in the original SNMP Protocol evaluation was: "The SNMP use of the term agent is different from its use in the Midcom framework: The SNMP Manager corresponds to the Midcom agent and the SNMP Agent corresponds to the Midcom PDP." Thus, the intent of this change is just to clarify the model used for the SNMP evaluation. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jul 26 16:56:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08359 for ; Fri, 26 Jul 2002 16:56:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21804 for midcom-archive@odin.ietf.org; Fri, 26 Jul 2002 16:57:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21610; Fri, 26 Jul 2002 16:53:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21581 for ; Fri, 26 Jul 2002 16:53:12 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08254 for ; Fri, 26 Jul 2002 16:52:06 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6QKqsX24672 for ; Fri, 26 Jul 2002 15:52:54 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 15:52:40 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C7C7@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Fri, 26 Jul 2002 15:52:39 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] MIDCOM Protocol Evaluation - Proposed changes to SNMP - Section 1 .1.1 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi all, This is the change that I propose to make to Section 1.1.1, with regards to clarifying the applicability of SNMP as the MIDCOM protocol. Old Text (from draft-ietf-midcom-protocol-eval-02.txt): "The primary advantages of SNMP compared to other protocols evaluated are that it is a mature, well understood protocol currently deployed in various scenarios. In addition, mature toolsets are available for SNMP managers and agents. SNMP is mainly used for monitoring rather than for configuring network nodes, however, thus reducing its applicability to MIDCOM." Proposed New Text: "The primary advantages of SNMP are that it is a mature, well understood protocol currently deployed in various scenarios, with mature toolsets available for SNMP managers and agents. However, several other factors also affect SNMP's applicability as the MIDCOM protocol: - SNMP is mainly used for monitoring rather than for configuring network nodes, and - SNMPv3 is required in order to meet the security requirements." *************** Although comments on the overall document will be accepted through August 2nd, I would like to request that feedback on this proposed change be provided by 6PM CST Tuesday (30 July) so that we can address any concerns prior to the 2nd; with no response meaning that the proposed text is OK. *************** Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jul 26 16:57:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08422 for ; Fri, 26 Jul 2002 16:57:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21900 for midcom-archive@odin.ietf.org; Fri, 26 Jul 2002 16:58:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21849; Fri, 26 Jul 2002 16:57:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21820 for ; Fri, 26 Jul 2002 16:57:16 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08372 for ; Fri, 26 Jul 2002 16:56:10 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6QKuwX25072 for ; Fri, 26 Jul 2002 15:56:58 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 15:56:44 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C7C9@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Fri, 26 Jul 2002 15:56:41 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] MIDCOM Protocol Evaluation - Proposed changes to COPS Section 1.5 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi all, This is the detailed change that I propose to make to Section 1.5, with regards to clarifying the COPS protocol evaluation, explicitly wrt to the requirement for COPS-PR. Old Text (from draft-ietf-midcom-protocol-eval-02.txt): "Within the context of this document, COPS and COPS-PR have similar compliancy with regards to the MIDCOM protocol requirements, with the only major difference being how MIDCOM policy rules attributes are described with COPS MIDCOM client specific objects or with COPS-PR MIDCOM PIB attributes. Thus, the evaluation takes into account both COPS and COPS-PR. If COPS is deemed the most suitable protocol for MIDCOM, the feasibility and complexity of the creation and usage of COPS MIDCOM client specific objects versus the COPS-PR MIDCOM specific PIBs should be compared. Thus, references to COPS are applicable to both COPS and COPS-PR." Proposed New Text: "Overall, COPS and COPS-PR have similar compliancy with regards to the MIDCOM protocol requirements. In this document, references to COPS are generally applicable to both COPS and COPS-PR. However, COPS-PR is explicitly identified to meet two of the requirements. The only other major difference between COPS-PR and COPS, as applied to the MIDCOM protocol, would be the description of the MIDCOM policy rule attributes with COPS-PR MIDCOM PIB attributes rather than COPS MIDCOM client specific objects." **************** Although comments on the overall document will be accepted through August 2nd, I would like to request that feedback on this proposed change be provided by 6PM CST Tuesday (30 July), so that we can address any concerns prior to the 2nd; with no response meaning that the proposed text is OK. **************** Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jul 26 16:59:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08497 for ; Fri, 26 Jul 2002 16:59:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22593 for midcom-archive@odin.ietf.org; Fri, 26 Jul 2002 17:00:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21941; Fri, 26 Jul 2002 16:58:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21910 for ; Fri, 26 Jul 2002 16:58:42 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08436 for ; Fri, 26 Jul 2002 16:57:36 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6QKwOX25173 for ; Fri, 26 Jul 2002 15:58:25 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 15:58:10 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C7CA@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Fri, 26 Jul 2002 15:58:03 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] MIDCOM Protocol Evaluation - Proposed changes to COPS Section 1.5 .2 - new sentences Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi all, These are the new sentences that I propose to add to the end of the existing paragraph in Section 1.5.2. Note, this change is intended to clarify the "directionality", referred to with regards to COPS failing to meet requirement 2.1.1, and also referenced in the Conclusion (Section 3). Proposed New Text: "One major difference between the COPS protocol model and the MIDCOM protocol requirements is that MIDCOM requires that the MIDCOM Agent establish the session. Whereas, the COPS definition is that a PEP (Middlebox) establishes communication with a PDP (MIDCOM Agent). " *************** Although comments on the overall document will be accepted through August 2nd, I would like to request that feedback on this proposed change be provided by 6PM CST Tuesday (30 July) so that we can address any concerns prior to the 2nd; with no response meaning that the proposed text is OK. *************** Thanks, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jul 26 16:59:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08514 for ; Fri, 26 Jul 2002 16:59:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22755 for midcom-archive@odin.ietf.org; Fri, 26 Jul 2002 17:00:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21991; Fri, 26 Jul 2002 16:59:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21960 for ; Fri, 26 Jul 2002 16:59:13 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08449 for ; Fri, 26 Jul 2002 16:58:07 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6QKwtX25237 for ; Fri, 26 Jul 2002 15:58:56 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 15:58:41 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C7CB@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Fri, 26 Jul 2002 15:58:36 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] MIDCOM Protocol Evaluation - Proposed changes to Megaco Section 1 .3.2 - new sentences Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi all, This is the 2 new sentences that I propose to add at the end of the existing paragraph in Section 1.3.2. Note, this change is intended to clarify the "directionality component", referred to with regards to Megaco failing to meet requirement 2.1.1, and also referenced in the Conclusion (Section 3). Proposed New Text: "One major difference between the Megaco model and the MIDCOM protocol requirements is that MIDCOM requires that the MIDCOM Agent establish the session. Whereas, the Megaco definition is that a MG (Middlebox) establishes communication with an MGC (MIDCOM Agent)." *************** Although comments on the overall document will be accepted through August 2nd, I would like to request that feedback on this proposed change be provided by 6PM CST Tuesday (30 July) so that we can address any concerns prior to the 2nd; with no response meaning that the proposed text is OK. *************** Thanks, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jul 26 18:52:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11293 for ; Fri, 26 Jul 2002 18:52:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA27899 for midcom-archive@odin.ietf.org; Fri, 26 Jul 2002 18:53:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27849; Fri, 26 Jul 2002 18:52:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27820 for ; Fri, 26 Jul 2002 18:52:25 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11264 for ; Fri, 26 Jul 2002 18:51:18 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6QMq7X15543 for ; Fri, 26 Jul 2002 17:52:07 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 17:51:53 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C7CF@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Fri, 26 Jul 2002 17:51:52 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] MIDCOM Protocol Evaluation - 2.2.2 Diameter - P -> P+? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi all, As I mentioned in the meeting in Yokohama, there still are some inconsistencies in the evaluation. One specific example that I would like to propose changing is 2.2.2 for Diameter. I would propose we change the P to P+ for Diameter. I think this was just one that I originally missed when we added the P+ category to the -01 version. Any dissenters should reply by 6PM CST Tuesday (30 July) so that we can address any concerns prior to the August 2nd deadline for comments. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jul 26 19:26:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11971 for ; Fri, 26 Jul 2002 19:26:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA29185 for midcom-archive@odin.ietf.org; Fri, 26 Jul 2002 19:27:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29163; Fri, 26 Jul 2002 19:26:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29135 for ; Fri, 26 Jul 2002 19:26:31 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11937 for ; Fri, 26 Jul 2002 19:25:24 -0400 (EDT) Received: from BOBP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AAA42941012C; Fri, 26 Jul 2002 19:26:28 -0400 Message-ID: <000f01c234fb$dad54200$2300000a@BOBP> From: "Bob Penfield" To: "Bob Penfield" , "Tom-PT Taylor" , "midcom" References: <4D79C746863DD51197690002A52CDA0001E8A6A0@zcard0kc.ca.nortel.com> <008101c231b7$b3f74c60$2300000a@acmepacket.com> Subject: Re: [midcom] Semantics Discussion Points Date: Fri, 26 Jul 2002 19:26:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Bob Penfield" > ----- Original Message ----- > From: "Tom-PT Taylor" > > > > > 3. Meaning of End Of Session > > > > Do rules continue to survive to the end of their lifetime? > > This should probably be specified in protocol at rule or session > establishment. In the case of redundant agents, where one agent might crash > or restart, you do not want to stop the flows/sessions. If rule state is > stored at the endpoints instead of at proxies which act as midcom agents, a > failed/restarted agent would not mean that the rule state was lost to the > application, and thus there is no need to delete the rule. > OOPS, this is an answer to a different question. Namely, do rules survive the end of a MIDCOM session (i.e. when the agent closes the connection). The "end of lifetime question" sounds like question 10 in the original email: > > > > 10. Grace Period and Pre-Notification > > > > Should there be notifications before rule lifetime expiry? > > I'm inclined to think so. It does allow the agent to rely on the middlebox > for the expiration timing. Otherwise, the agent would have to have timers > too so it could extend the rule lifetime shortly before it expires. > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jul 29 17:41:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16168 for ; Mon, 29 Jul 2002 17:41:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02443 for midcom-archive@odin.ietf.org; Mon, 29 Jul 2002 17:42:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02339; Mon, 29 Jul 2002 17:38:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02303 for ; Mon, 29 Jul 2002 17:38:40 -0400 (EDT) Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16099 for ; Mon, 29 Jul 2002 17:37:29 -0400 (EDT) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA27957 for ; Mon, 29 Jul 2002 17:32:13 -0400 (EDT) To: midcom@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Mon, 29 Jul 2002 17:31:45 -0400 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 07/29/2002 05:32:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] STUN Message validation question Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org The STUN proposal states that a STUN client can validate server responses by using the server's certificate. Specificaly page 15, section 8.3,towards the end of the second paragraph it states "... If the certificate used for the signature is a site certificate, the client SHOULD validate that the domain it used to perform the STUN query is a sub-domain of the domain in the site certificate. In other words, if the client queries stun.example.com, the client SHOULD validate that the signature was certified as coming from example.com..." I'm confused how the client can verify the server's information during the discovery phase when it sends a CHANGE-IP and CHANGE-PORT message and it receives responses from another STUN server. Please correct me if my following assumptions are not correct. Based on the current verbiage of the proposal the STUN client will receive a response from another STUN server and continue to follow it's discovery process. If the client decides to verify the information used by the second server there are two cases" a) the STUN client will use the initial COOKIE that was received from the initial STUN request with the first server. b) the second server includes a COOKIE in it's response so the client will use this COOKIE to authenticate the STUN message. In case (a) the client will be using the wrong COOKIE and thus the second server will not sign the response. In case (b) it means that the client will have to send another STUN message (based on the STUN proposal) to the second server to verify the authenticity of the response from the second server. And in order for the client to verify the response it will have to compare the attributes from the first response and the second response from the second server and I quote from the STUN proposal, "....If the other attributes in the response match the first response, and the signature is valid, the client can trust that the information has not been tampered with, and is authentic." But the attributes will not be the same since the initial request asked for "CHANGE-IP" and "CHANGE-PORT". So the client will send the same request with "CHANGE-IP" and "CHANGE-PORT" to the second server (in order to verify it) and the second server will see "CHANGE-IP" and "CHANGE-PORT" and send it to another server. This will cause a domino effect while the client is trying to verify if what it received ws correct and there is a posibility of falling in to an infinite loop. One idea would be to have the first server tell the second server to automaticaly sign the response to the client without having the client initiate a new COOKIE exchange with the second server. Peter Thermos _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 30 14:32:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03681 for ; Tue, 30 Jul 2002 14:32:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17311 for midcom-archive@odin.ietf.org; Tue, 30 Jul 2002 14:33:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16296; Tue, 30 Jul 2002 14:24:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16265 for ; Tue, 30 Jul 2002 14:24:35 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03216 for ; Tue, 30 Jul 2002 14:23:27 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6UIO3hI012762; Tue, 30 Jul 2002 11:24:03 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADP04752; Tue, 30 Jul 2002 11:24:15 -0700 (PDT) From: "Cullen Jennings" To: "Panayiotis A. Thermos" , Subject: RE: [midcom] STUN Message validation question Date: Tue, 30 Jul 2002 11:25:00 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Lets make sure we are both talking about the same draft. The latest draft is: http://search.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt This substantially changes the security stuff from the previous draft. In the new one, the certificate check only has to do with the TLS connection that is used to get the OTP. Cullen > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Panayiotis A. Thermos > Sent: Monday, July 29, 2002 2:32 PM > To: midcom@ietf.org > Subject: [midcom] STUN Message validation question > > > The STUN proposal states that a STUN client can > validate server responses by using the server's > certificate. Specificaly page 15, section 8.3,towards > the end of the second paragraph it states > > "... If the certificate used for the signature is a > site certificate, the client SHOULD validate that > the domain it used to perform the STUN query is a > sub-domain of the domain in the site certificate. > In other words, if the client queries stun.example.com, > the client SHOULD validate that the signature was > certified as coming from example.com..." > > I'm confused how the client can verify the server's > information during the discovery phase when it > sends a CHANGE-IP and CHANGE-PORT message and it > receives responses from another STUN server. > > Please correct me if my following assumptions are not > correct. > > Based on the current verbiage of the proposal the STUN > client will receive a response from another STUN server > and continue to follow it's discovery process. > > If the client decides to verify the information used by the > second server there are two cases" > > a) the STUN client will use the initial COOKIE that > was received from the initial STUN request with > the first server. > > b) the second server includes a COOKIE in it's response > so the client will use this COOKIE to authenticate > the STUN message. > > In case (a) the client will be using the wrong COOKIE and thus > the second server will not sign the response. > > In case (b) it means that the client will have to send another > STUN message (based on the STUN proposal) to the second > server to verify the authenticity of the response from the > second server. And in order for the client to verify the response > it will have to compare the attributes from the first response > and the second response from the second server and I quote from > the STUN proposal, > > "....If the other attributes in the response match the first response, > and the signature is valid, the client can trust that the > information has not been tampered with, and is authentic." > > But the attributes will not be the same since the initial request > asked for "CHANGE-IP" and "CHANGE-PORT". So the client will > send the same request with "CHANGE-IP" and "CHANGE-PORT" to the > second server (in order to verify it) and the second server will > see "CHANGE-IP" and "CHANGE-PORT" and send it to another server. > This will cause a domino effect while the client is trying to verify > if what it received ws correct and there is a posibility of falling > in to an infinite loop. > > One idea would be to have the first server tell the second server > to automaticaly sign the response to the client without having > the client initiate a new COOKIE exchange with the second server. > > > Peter Thermos > > > _______________________________________________ > 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 daemon@optimus.ietf.org Tue Jul 30 15:57:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06797 for ; Tue, 30 Jul 2002 15:57:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22123 for midcom-archive@odin.ietf.org; Tue, 30 Jul 2002 15:58:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21782; Tue, 30 Jul 2002 15:49:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21748 for ; Tue, 30 Jul 2002 15:49:20 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06648 for ; Tue, 30 Jul 2002 15:48:11 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6UJn9a29989 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 30 Jul 2002 12:49:10 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6UJn5Q03610 for ; Tue, 30 Jul 2002 12:49:05 -0700 (PDT) To: midcom Date: Tue, 30 Jul 2002 14:48:54 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] Questions on middleboxes with more than 2 interfaces Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Middlebox experts, Middleboxes with more than 2 physical interfaces were discussed briefly in the Yokohama WG sessions and in hallway conversations. I don't think any conclusions were reached on this, but I could be wrong. The questions below all come from the fact that the MIDCOM framework, while it talks about multiple streams both in the private and public domains, does not talk about whether those data streams are caried on one physical interface / subnet both in the private and public domains, or are multiple physicals interfaces possible in each domain. The MIDCOM semantics I-Ds also are relatively silent on this issue. So, I'll pose some questions and suggest some answers to get discussion going on this. Q1. Can a middlebox have multiple physical interfaces on the private side or inside? I don't know of any NATs or firewalls that have this capability, but I can readily imagine the usefulness and existence of such things. Does anybody know of any such middleboxes, perhaps other types of middleboxe than NATter or firewall? I think VPN tunnel switches would have this capability if they were considered middleboxes. Q2. Can a middlebox have multiple physical interfaces on the public side or outside? Again, I don't know of any, but can imagine this, although not as readily as multiple interfaces on the private side. VPN tunnel switches might fit better here. Q3. If a middlebox has multiple physical interfaces on the private side, can it have multiple private address realms? If a NAT had multiple private side interfaces, I could readily imagine that it could support multiple private address realms. Q4. If a middle has both multiple private side interfaces and multiple private address realms, what is the relationship between them? While I can't see more than one private address realm per private side interface, I can imagine multiple private side interfaces per private address realm. Q5. How would the MIDCOM framework, semantics, protocol, etc., view a middlebox with multiple private side interfaces or private address realms or both? If the middle box had one public side interface and one private address realm per private side interface, one could define a "virtual" middlebox per private side interface / private address realm. This may not scale well, but it might work. The only real problem I see here is that to "trombone" or "hairpin" from one private address realm to another would require using addresses in the public realm, which could have problems with resource consumption, performance, signaling complexity, etc. (This is (roughly?) equivalent to double NATting.) If the middlebox had multiple public side interfaces or multiple private side interfaces per private address realm, then I don't think the multiple virtual middlebox approach would work well at all. MIDCOM semantics and protocols would have to be extended to explicitly support this. Q6. What middlebox semantics and protocol extensions would be required to support middleboxes such as these? I can think of several things: - a rule would have to include up to four sockets (address / port combinations): source socket; mapped source socket; destination socket; and mapped destination socket. "source" and "destination" obviously refer to packet flow in one direction and would be reversed for packet flow in the opposite direction. For firewall pinholes only two sockets would be used, three would be used for one-way NAT mappings, and four for two-way NAT mappings. - Each unmapped and mapped socket pair, "source" and "destination", would have to include either an interface identifier or an address realm identifier. Interface identifiers would allow finer grained rules to be specified; address realm identifiers might match semantics better. Whether an interface or address realm was public or private would have to be derivable from the identifier. Or there would have to be separate private and public identifer spaces, and then an additional type-of-identifier parameter (public or private) would have to be included in each socket pair specification. - It might be useful to include query capabilities that would enumerate either all interfaces and address realms, or only those for which a particular agent is authorized. The interface enumeration should include the identification of the address realm accessed through that interface. Q7. Is any of this at all useful? Should we even bother discussing it? I don't know, that's why I'm asking the questions. :-) Comments and cogent thoughts welcome and appreciated. Jim Renkel Director, Advanced Technology & System Engineering The CommWorks Corp., a 3Com company _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 30 16:11:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07286 for ; Tue, 30 Jul 2002 16:11:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA23177 for midcom-archive@odin.ietf.org; Tue, 30 Jul 2002 16:13:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22810; Tue, 30 Jul 2002 16:02:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22784 for ; Tue, 30 Jul 2002 16:02:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06874 for ; Tue, 30 Jul 2002 16:01:04 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6UK1fhI027462; Tue, 30 Jul 2002 13:01:41 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEQ49901; Tue, 30 Jul 2002 12:57:41 -0700 (PDT) Message-Id: <200207301957.AEQ49901@mira-sjc5-4.cisco.com> To: James_Renkel@3com.com cc: midcom From: Melinda Shore Subject: Re: [midcom] Questions on middleboxes with more than 2 interfaces In-Reply-To: Message from James_Renkel@3com.com of "Tue, 30 Jul 2002 14:48:54 CDT." Date: Tue, 30 Jul 2002 15:59:56 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We talked about this quite a bit last year. The number of interfaces on a firewall or NAT is clearly outside the scope of the working group. The implications of doing much more than simply providing a blob to pass interface identifiers around with addresses are mind-bogglingly awful, and the decision was, basically, to punt. Let's avoid revisiting that mess - discussion of what data need to be carried by the protocol is fine, but discussion about the behavior of middleboxes in the face of more than two interfaces should serve only to elucidate the data question and should not be concerned with specifying behaviors. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 30 19:09:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12426 for ; Tue, 30 Jul 2002 19:09:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA03792 for midcom-archive@odin.ietf.org; Tue, 30 Jul 2002 19:10:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03317; Tue, 30 Jul 2002 19:02:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03277 for ; Tue, 30 Jul 2002 19:02:04 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12301 for ; Tue, 30 Jul 2002 19:00:57 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6UN1P9V006664 for ; Tue, 30 Jul 2002 16:01:25 -0700 (PDT) Received: from fluffyw2k (dhcp-128-107-142-72.cisco.com [128.107.142.72]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADP14765; Tue, 30 Jul 2002 16:01:48 -0700 (PDT) From: "Cullen Jennings" To: "Midcom" Date: Tue, 30 Jul 2002 16:01:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [midcom] STUN update time proposals Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I waited until after last call to mention this because I do not think they should hold up the current stuff but it might be a reasonable extension. Add an optional tag that the STUN server can return that indicates an upper bound on how long the NAT binding is valid without an update. This will be useful for the clients trying to discover the length of time the binding in the NAT stay valid. The STUN server never knows all the NATs in the path but it may know one of the NATs and how it is configured. From this it may know how long that particular NAT will keep in the binding open without an update. Other NATs in the path may have shorter times. This is why the client must consider this an upper bound on the time not the actual time. Cullen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jul 30 22:37:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17412 for ; Tue, 30 Jul 2002 22:37:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA13840 for midcom-archive@odin.ietf.org; Tue, 30 Jul 2002 22:38:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13097; Tue, 30 Jul 2002 22:27:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13069 for ; Tue, 30 Jul 2002 22:27:12 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16892 for ; Tue, 30 Jul 2002 22:26:03 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6V2QgYH022489; Tue, 30 Jul 2002 22:26:42 -0400 (EDT) Message-ID: <3D474ADF.8070305@dynamicsoft.com> Date: Tue, 30 Jul 2002 22:26:39 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Midcom Subject: Re: [midcom] STUN update time proposals References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit This came up during the Minneapolis IETF, as I recall. I feel its not a good thing to do. The reason is that its fundamental to the model that STUN is not processed by NAT. What you are proposing only makes sense in the model where STUN *is* understood and processed by NAT. I am worried about the potential for abuse, security problems, and so on, since the protocol is not designed for that. I would rather pursue such avenues in the tist/nsis framework, as thats what its meant for. -Jonathan R. Cullen Jennings wrote: > I waited until after last call to mention this because I do not think > they > should hold up the current stuff but it might be a reasonable extension. > > Add an optional tag that the STUN server can return that indicates an > upper > bound on how long the NAT binding is valid without an update. This will > be > useful for the clients trying to discover the length of time the binding > in > the NAT stay valid. > > The STUN server never knows all the NATs in the path but it may know one > of > the NATs and how it is configured. From this it may know how long that > particular NAT will keep in the binding open without an update. Other > NATs > in the path may have shorter times. This is why the client must consider > this an upper bound on the time not the actual time. > > Cullen > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 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 daemon@optimus.ietf.org Wed Jul 31 01:06:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21042 for ; Wed, 31 Jul 2002 01:06:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA22517 for midcom-archive@odin.ietf.org; Wed, 31 Jul 2002 01:07:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19615; Wed, 31 Jul 2002 00:56:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19586 for ; Wed, 31 Jul 2002 00:56:43 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20741 for ; Wed, 31 Jul 2002 00:55:35 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6V4tv9V009632; Tue, 30 Jul 2002 21:55:57 -0700 (PDT) Received: from fluffyw2k (dhcp-128-107-209-123.cisco.com [128.107.209.123]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADP23210; Tue, 30 Jul 2002 21:56:19 -0700 (PDT) From: "Cullen Jennings" To: "Jonathan Rosenberg" Cc: "Midcom" Subject: RE: [midcom] STUN update time proposals Date: Tue, 30 Jul 2002 21:56:05 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <3D474ADF.8070305@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I was not thinking of the NAT modifying the STUN message. The option would be protected by the signature in the STUN response so it would fail if the NAT modified it. I was imagining a scenario more along the following lines. A large cable ISP has a large NAT that NATs all of it's customers. It also is very nice and runs a SMTP server and STUN server for all of it's (and only it's) customers. Additionally, each customer might run a second NAT at their home so they can connect multiple computers for the price of one. The ISP knows that their large NAT keeps binding up for 5 minutes. They configure this into their STUN server. This stun server is guaranteed by ACL to only accept responses from customers of the ISP that are behind this NAT. This helps the client short circuit the times that they need to search because they can start at 5 minutes and binary divide from there. The client can't just blindly use 5 minutes because it has no idea what the NAT in the home is and might be less than this. If the STUN server served the internet as a whole it would not be possible to add this option because the server would not know anything about the NAT that might in the path. I only have vague recollection of why we discarded it in Minneapolis. I completely agree that moving to a point were the NAT needs to some how understand STUN completely defeats the purpose of doing STUN in the first place - I'm not advocating that at all. TIST seems like a far more interesting way of discovering the minimal time of any middle box in the path. Cullen > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 30, 2002 7:27 PM > To: Cullen Jennings > Cc: Midcom > Subject: Re: [midcom] STUN update time proposals > > > This came up during the Minneapolis IETF, as I recall. > > I feel its not a good thing to do. The reason is that its fundamental to > the model that STUN is not processed by NAT. What you are proposing only > makes sense in the model where STUN *is* understood and processed by > NAT. I am worried about the potential for abuse, security problems, and > so on, since the protocol is not designed for that. I would rather > pursue such avenues in the tist/nsis framework, as thats what its > meant for. > > -Jonathan R. > > Cullen Jennings wrote: > > I waited until after last call to mention this because I do not think > > they > > should hold up the current stuff but it might be a reasonable extension. > > > > Add an optional tag that the STUN server can return that indicates an > > upper > > bound on how long the NAT binding is valid without an update. This will > > be > > useful for the clients trying to discover the length of time the binding > > in > > the NAT stay valid. > > > > The STUN server never knows all the NATs in the path but it may know one > > of > > the NATs and how it is configured. From this it may know how long that > > particular NAT will keep in the binding open without an update. Other > > NATs > > in the path may have shorter times. This is why the client must consider > > this an upper bound on the time not the actual time. > > > > Cullen > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > 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 daemon@optimus.ietf.org Wed Jul 31 13:49:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09765 for ; Wed, 31 Jul 2002 13:49:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25599 for midcom-archive@odin.ietf.org; Wed, 31 Jul 2002 13:50:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25246; Wed, 31 Jul 2002 13:47:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25215 for ; Wed, 31 Jul 2002 13:47:17 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09585 for ; Wed, 31 Jul 2002 13:46:09 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6VHlHa00488 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 31 Jul 2002 10:47:18 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6VHlCQ15504; Wed, 31 Jul 2002 10:47:12 -0700 (PDT) Subject: Re: [midcom] Questions on middleboxes with more than 2 interfaces To: Melinda Shore Cc: midcom Date: Wed, 31 Jul 2002 12:47:04 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Melinda, I agree completely. Specifying the behavior of middleboxes, whether they have only two interfaces or more than two interfaces, is beyond the scope of this WG. Middlebox behavior discussion should be limited to making sure we support middlebox behaviors that are already known or can be reasonably anticipated. I raised these questions strictly for the purpose of, as you suggest, making sure that we have the necessary stuff in the semantics and protocol(s). And to find out whether or not we should even be thinking about middleboxes with more than two interfaces! I personally think we should, but I could be wrong. :-) Jim Melinda Shore on 07/30/2002 02:59:56 PM Sent by: Melinda Shore To: James Renkel/MW/US/3Com cc: midcom Subject: Re: [midcom] Questions on middleboxes with more than 2 interfaces We talked about this quite a bit last year. The number of interfaces on a firewall or NAT is clearly outside the scope of the working group. The implications of doing much more than simply providing a blob to pass interface identifiers around with addresses are mind-bogglingly awful, and the decision was, basically, to punt. Let's avoid revisiting that mess - discussion of what data need to be carried by the protocol is fine, but discussion about the behavior of middleboxes in the face of more than two interfaces should serve only to elucidate the data question and should not be concerned with specifying behaviors. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 31 14:09:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11254 for ; Wed, 31 Jul 2002 14:09:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27637 for midcom-archive@odin.ietf.org; Wed, 31 Jul 2002 14:11:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27522; Wed, 31 Jul 2002 14:09:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27492 for ; Wed, 31 Jul 2002 14:09:46 -0400 (EDT) Received: from mail1.netscreen.com ([63.126.135.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11218 for ; Wed, 31 Jul 2002 14:08:37 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.10.21]) by mail1.netscreen.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6VI6ld15011; Wed, 31 Jul 2002 11:06:48 -0700 (PDT) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Jul 2002 11:06:05 -0700 Message-ID: From: John LaCour To: "'James_Renkel@3com.com'" , Melinda Shore Cc: midcom Subject: RE: [midcom] Questions on middleboxes with more than 2 interfaces Date: Wed, 31 Jul 2002 11:06:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org In my view, we should be thinking about middleboxes with two address-space/security realms and providing a protocol with appropriate semantics to request NAT and pinhole services between those realms. How those realms map to a physical middlebox is outside the scope of the wg and protocol and will be left to implementors to work out on their own. -John > -----Original Message----- > From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] > Sent: Wednesday, July 31, 2002 10:47 AM > To: Melinda Shore > Melinda, > > I agree completely. Specifying the behavior of middleboxes, whether > they have only two interfaces or more than two interfaces, is beyond > the scope of this WG. Middlebox behavior discussion should be limited > to making sure we support middlebox behaviors that are already known > or can be reasonably anticipated. > > I raised these questions strictly for the purpose of, as you suggest, > making sure that we have the necessary stuff in the semantics and > protocol(s). > > And to find out whether or not we should even be thinking about > middleboxes with more than two interfaces! I personally think we > should, but I could be wrong. :-) > > Jim > > > > > > > Melinda Shore on 07/30/2002 02:59:56 PM > > Sent by: Melinda Shore > > > To: James Renkel/MW/US/3Com > cc: midcom > Subject: Re: [midcom] Questions on middleboxes with more > than 2 interfaces > > > We talked about this quite a bit last year. The number of > interfaces on a firewall or NAT is clearly outside the scope > of the working group. The implications of doing much more > than simply providing a blob to pass interface identifiers > around with addresses are mind-bogglingly awful, and the > decision was, basically, to punt. Let's avoid revisiting > that mess - discussion of what data need to be carried by > the protocol is fine, but discussion about the behavior of > middleboxes in the face of more than two interfaces should > serve only to elucidate the data question and should not be > concerned with specifying behaviors. > > 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 daemon@optimus.ietf.org Wed Jul 31 15:37:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14991 for ; Wed, 31 Jul 2002 15:37:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05118 for midcom-archive@odin.ietf.org; Wed, 31 Jul 2002 15:39:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04445; Wed, 31 Jul 2002 15:36:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04416 for ; Wed, 31 Jul 2002 15:36:12 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14847 for ; Wed, 31 Jul 2002 15:35:01 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6VJa7a01845 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Wed, 31 Jul 2002 12:36:08 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6VJa3Q02454 for ; Wed, 31 Jul 2002 12:36:03 -0700 (PDT) To: midcom Date: Wed, 31 Jul 2002 14:35:53 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Subject: [midcom] Comments on protocol evaluation draft Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Middlebox experts, Overall, I think this work is great. Mary Barnes should be complimented and thanked for pulling this together. While I have a few small issues with the facts or claims in Sections 1 and 2, my real concern is with Section 3. The concern is not so much with the facts presented there, but with the way they might be interpreted *as presented there*. What the MIDCOM WG has tried to do in this protocol evaluation, and I think largely succeeded in doing, is to compare the frameworks and capabilities of a number of protocols to the MIDCOM requirements and framework (Many of the MIDCOM requirements addressed the matching of MIDCOM and protocol framework elements.). If you look at this on a MIDCOM requirement by requirement (and / or framework element by framework element basis) against the framework elements and protocol capabilities of a single protocol, there are a number of possibilities: - The protocol's framework elements and protocol capabilities match exactly (or extremely close to exactly) the MIDCOM requirement or framework element. GREAT! This is what we were looking and hoping for. - The protocol does not have any framework elements or protocol capabilities that address the MIDCOM requirement or framework element. Not so great, but, again, this is what we were looking (but not hoping) for. - The protocol's framework elements and protocol capabilities somewhat match the MIDCOM requirement or framework element. Here's where I start to have some problems. Where the match is not exact, there's two possibilities (or a combination of them): - In the individual protocol evaluation, a proposal is made to modify or extend the protocol's mandatory framework elements or protocol capabilities, or to modify optional framework elements or protocol capabilities, to match the MIDCOM requirement or framework element. From our perspective, this is good, but it may not be so good to other users of the protocol. If the protocol is single purpose with few users at this time and no guarantee of forward compatibility (e.g., RSIP), modifying the protocol ain't so bad. But if the protocol has other purposes, many users, or the guarantee of forward compatibility, this may not be so good (The implications of "other purposes" and "many users" is hopefully obvious. I'll return to the issue of guaranteed forward compatibility below.). Also, extending the protocol with optional framework elements and capabilities is probably not bad. - Alternately or in combination, a proposal is made to "think about the MIDCOM requirement or framework element in a different way" so that the match is exact or almost so. I think there's quite a bit of this going on in the protocol evaluations. Taken individually, if the proposed change in thinking is not large, this might not be bad. Taken together, if the sum of all such changed thinking for a protocol is not large, this may also be not bad. But, if taken together the sum of all such proposals for a given protocol is large, then essentially this says that the MIDCOM framework or requirements would need some rather extensive revision to match the protocol's framework and capabilities. That's probably bad. For both of the above alternatives, the protocol would have been scored as partially matching the MIDCOM requirements. But the distinction between the two alternatives is lost in the scoring, so that the count of the partial matches can not be easily evaluated as being overall good or overall bad. I didn't go through the exercise (and maybe I should) of marking each partial requirements match as one or the other of the above and counting the number of each alternative for each protocol, but my gut feeling is that we may have a problem here. Returning to the issue of guaranteed forward compatibility, if the proposal is to modify or extend mandatory framework elements or protocol capabilities, or to modify optional elements or capabilities, then all other users of the protocol, or its modified optional elements and capabilities, would have to support the changes that were made to the protocol for MIDCOM. Depending on the size of these changes, this may not be acceptable to the protocols other users. And we probably shouldn't consider these types of changes without those users buying into them. Again, I didn't specifically count the applicable scorings here and maybe I should have, but in this case I don't really think we have much of a problem. Another issue that I have with the whole evaluation is that it did not consider the impact of a protocol's mandatory framework elements and protocol capabilities that are *not* required by MIDCOM. The problem here is that middleboxes and agents / applications may have to support these even though they're not used. If the protocol has another simultaneous use in the middlebox or agent / application, then the impact is not so bad, in fact there may be no impact at all. But if the use of the protocol is its first use in the middlebox or agent / application, then I think we have to seriously consider this potential problem. This problem relates to, but is not exclusive to, library and source code reuse, which in general is desirable. But if the library or source code has a lot of unused capabilities, and the MIDCOM implementer can't (afford to) remove them, then this will place an unnecessary cost on implementations. I have no idea how to evaluate this in advance, but I have a gut feeling we may have a *real* problem here. I am certainly open to ideas on how to evaluate this in advance. But maybe we'll just have to wait for specific protocol proposals to be able to see through this issue. So, overall, I think the evaluation is good, but I have some issues with how the facts presented, especially the summary counts, may be interpreted. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jul 31 15:45:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15281 for ; Wed, 31 Jul 2002 15:45:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05535 for midcom-archive@odin.ietf.org; Wed, 31 Jul 2002 15:46:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05417; Wed, 31 Jul 2002 15:44:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05388 for ; Wed, 31 Jul 2002 15:44:00 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15218 for ; Wed, 31 Jul 2002 15:42:49 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6VJhwa04045 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 31 Jul 2002 12:43:59 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6VJhsQ03457; Wed, 31 Jul 2002 12:43:54 -0700 (PDT) Subject: RE: [midcom] Questions on middleboxes with more than 2 interfaces To: John LaCour Cc: midcom Date: Wed, 31 Jul 2002 14:43:44 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org John, My initial reaction is that I agree that if there's only two realms, the number of interfaces onto which they map and how they map is an implementation issue. But I want to think about it just a bit more to be sure. But what if the middlebox supports more than two realms? That's the real issue that I was trying to get to. Jim John LaCour on 07/31/2002 01:06:30 PM Sent by: John LaCour To: James Renkel/MW/US/3Com, Melinda Shore cc: midcom Subject: RE: [midcom] Questions on middleboxes with more than 2 interfaces In my view, we should be thinking about middleboxes with two address-space/security realms and providing a protocol with appropriate semantics to request NAT and pinhole services between those realms. How those realms map to a physical middlebox is outside the scope of the wg and protocol and will be left to implementors to work out on their own. -John > -----Original Message----- > From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] > Sent: Wednesday, July 31, 2002 10:47 AM > To: Melinda Shore > Melinda, > > I agree completely. Specifying the behavior of middleboxes, whether > they have only two interfaces or more than two interfaces, is beyond > the scope of this WG. Middlebox behavior discussion should be limited > to making sure we support middlebox behaviors that are already known > or can be reasonably anticipated. > > I raised these questions strictly for the purpose of, as you suggest, > making sure that we have the necessary stuff in the semantics and > protocol(s). > > And to find out whether or not we should even be thinking about > middleboxes with more than two interfaces! I personally think we > should, but I could be wrong. :-) > > Jim > > > > > > > Melinda Shore on 07/30/2002 02:59:56 PM > > Sent by: Melinda Shore > > > To: James Renkel/MW/US/3Com > cc: midcom > Subject: Re: [midcom] Questions on middleboxes with more > than 2 interfaces > > > We talked about this quite a bit last year. The number of > interfaces on a firewall or NAT is clearly outside the scope > of the working group. The implications of doing much more > than simply providing a blob to pass interface identifiers > around with addresses are mind-bogglingly awful, and the > decision was, basically, to punt. Let's avoid revisiting > that mess - discussion of what data need to be carried by > the protocol is fine, but discussion about the behavior of > middleboxes in the face of more than two interfaces should > serve only to elucidate the data question and should not be > concerned with specifying behaviors. > > 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