From exim@www1.ietf.org Sat Nov 1 12:45:23 2003 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 MAA11366 for ; Sat, 1 Nov 2003 12:45:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFzo8-0006i8-UX for midcom-archive@odin.ietf.org; Sat, 01 Nov 2003 12:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA1Hj4bI025779 for midcom-archive@odin.ietf.org; Sat, 1 Nov 2003 12:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFzo6-0006hL-Uc; Sat, 01 Nov 2003 12:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFznL-0006gh-Q3 for midcom@optimus.ietf.org; Sat, 01 Nov 2003 12:44:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11353 for ; Sat, 1 Nov 2003 12:44:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFznK-0003XF-00 for midcom@ietf.org; Sat, 01 Nov 2003 12:44:14 -0500 Received: from out004pub.verizon.net ([206.46.170.142] helo=out004.verizon.net) by ietf-mx with esmtp (Exim 4.12) id 1AFznJ-0003Wy-00 for midcom@ietf.org; Sat, 01 Nov 2003 12:44:13 -0500 Received: from [192.168.1.100] ([151.199.24.202]) by out004.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20031101174343.XKSS4654.out004.verizon.net@[192.168.1.100]> for ; Sat, 1 Nov 2003 11:43:43 -0600 From: Bryan Ford Organization: Massachusetts Institute of Technology To: midcom@ietf.org Date: Sat, 1 Nov 2003 12:43:41 -0500 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311011243.41255.baford@mit.edu> X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [151.199.24.202] at Sat, 1 Nov 2003 11:43:42 -0600 Content-Transfer-Encoding: 7bit Subject: [midcom] New draft - "Peer-to-Peer communication across Middleboxes" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi folks, Pyda Srisuresh just recently submitted a new version of the Internet-Draft "Peer-to-Peer communication across Middleboxes" that he, Dan Kegel, and I have been working on together - intended to become an informational RFC describing the existing practice for P2P communication across middleboxes, with recommendations for application developers and NAT designers to support and increase the robustness of these techniques: http://www.ietf.org/internet-drafts/draft-ford-midcom-p2p-01.txt The main difference in this new version is that, as per the suggestions of Christian Huitema and others, the new IP option we proposed in the previous draft has been split out (to appear later in a separate draft). Also the sections on recommendations to P2P application developers, and the security section, have been filled out much more. We believe this draft is substantially complete and on-target (modulo a little more editing for flow, clarity, and stylistic consistency), and would like to solicit your comments and suggestions. Thanks very much! Bryan _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Nov 7 17:30:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11252 for ; Fri, 7 Nov 2003 17:30:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIF7E-0006ws-Ef for midcom-archive@odin.ietf.org; Fri, 07 Nov 2003 17:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7MU4xG026704 for midcom-archive@odin.ietf.org; Fri, 7 Nov 2003 17:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIF7C-0006wW-5W; Fri, 07 Nov 2003 17:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIF7A-0006w3-9u for midcom@optimus.ietf.org; Fri, 07 Nov 2003 17:30:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11203 for ; Fri, 7 Nov 2003 17:29:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIF77-0004Bb-00 for midcom@ietf.org; Fri, 07 Nov 2003 17:29:57 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AIF77-0004BG-00 for midcom@ietf.org; Fri, 07 Nov 2003 17:29:57 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Nov 2003 14:34:44 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA7MTPmU020345 for ; Fri, 7 Nov 2003 14:29:25 -0800 (PST) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOA07415; Fri, 7 Nov 2003 14:29:23 -0800 (PST) Date: Fri, 7 Nov 2003 17:29:22 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [midcom] meeting multicast Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit For those who won't be able to attend next week's meeting, the session is going to be multicast. Information on how to receive multicast sessions is available at http://videolab.uoregon.edu/events/ietf/ietf58.html . Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Nov 14 10:43:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16554 for ; Fri, 14 Nov 2003 10:43:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg6T-0008Os-3A for midcom-archive@odin.ietf.org; Fri, 14 Nov 2003 10:43:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEFhKc9032288 for midcom-archive@odin.ietf.org; Fri, 14 Nov 2003 10:43:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg6D-0008MK-Kz; Fri, 14 Nov 2003 10:43:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg5B-0008LD-Er for midcom@optimus.ietf.org; Fri, 14 Nov 2003 10:42:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16465 for ; Fri, 14 Nov 2003 10:41:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg59-0007Oq-00 for midcom@ietf.org; Fri, 14 Nov 2003 10:41:59 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKg58-0007OR-00 for midcom@ietf.org; Fri, 14 Nov 2003 10:41:58 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 14 Nov 2003 07:48:41 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAEFfPw5005847 for ; Fri, 14 Nov 2003 07:41:25 -0800 (PST) Received: from cisco.com (rtp-vpn1-819.cisco.com [10.82.227.51]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOF83710; Fri, 14 Nov 2003 07:41:24 -0800 (PST) Date: Fri, 14 Nov 2003 10:41:23 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <0014E28D-16B9-11D8-A130-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [midcom] Fwd: minutes of MIDCOM session Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Here are the draft minutes from the midcom meeting earlier this week. Please send corrections to the mailing list. Many thanks to Juergen for taking notes. Begin forwarded message: > Minutes of the midcom session at IETF58 > > Minneapolis, Tuesday, November 11, 2003, 15:45 h - 16:00 h > > Melinda Shore reported on the WG documents status. The semantics > document was sent to the IESG. The protocol evaluation document > still in the RFC editor queue. The MIDOCM MIB document is delayed > but progressing. > > Mary Barnes reported on progress of the MIDCOM MIB design. The > MIDCOM MIB analysis document draft-ietf-midcom-mib-analysis-01.txt > was updating. It is awaiting approval to split FW functionality > from the IPSec Policy Configuration MIB. > > Two new issues were raised. It was questioned whether or not IP > address wildcarding is required for A0, and whether or not port > ranges larger than 2 port numbers are required. > > Out of the design teams, two drafts for the MIDCOM MIB were written > as individual submission. One approach uses explicit relationships > to used resources, the other one uses implicit relationships. > Currently, merging both approaches is progressing. Agreements were > made about > - realizing PRR policies on NATs by disabled bindings, > - realizing PER policies on NATs by NAT sessions (at least in > most cases), and > - the indexing scheme for groups. > Still under discussion is modeling of policy rules. > > It is planned to have a merged MIDCOM MIB proposal by Nov 27. > Then interim feedback from a MIB doctor will be requested. > Completion of the I-D is envisioned for February 2004 which > would allow submitting the document to the IESG around April > 2004. > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Nov 17 19:52:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16117 for ; Mon, 17 Nov 2003 19:52:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALu68-0003FQ-Kl for midcom-archive@odin.ietf.org; Mon, 17 Nov 2003 19:52:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI0q452012477 for midcom-archive@odin.ietf.org; Mon, 17 Nov 2003 19:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALu64-0003E7-NB; Mon, 17 Nov 2003 19:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALu5Z-0003CC-2G for midcom@optimus.ietf.org; Mon, 17 Nov 2003 19:51:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16081; Mon, 17 Nov 2003 19:51:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALu5V-0002Ye-00; Mon, 17 Nov 2003 19:51:25 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALu5V-0002YY-00; Mon, 17 Nov 2003 19:51:25 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAI0orAt020501; Mon, 17 Nov 2003 16:50:53 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKA52949; Mon, 17 Nov 2003 16:50:52 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 17 Nov 2003 16:50:51 -0800 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN From: Cullen Jennings To: Pete Cordell , Mmusic , Midcom Message-ID: In-Reply-To: <004d01c3985b$b1f25340$0200000a@tkw> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit If people have specific technical issues about the security of TURN that are not documented in the current draft - it would be really nice to know about them. I always hear there are some but I never seem to hear what exactly they are. I do understand Melinda's general concerns on if media relays should be done at all no matter how they are done. Thanks Cullen On 10/21/03 10:14 PM, "Pete Cordell" wrote: > What you say Christian is technically absolutely correct. > > However this communities appetite for implementing and labelling their > products with even -00 draft material suggests to me that many implementers > (and probably their customers) are not bothered by these subtleties of IETF > process. > > Certainly it would help to know whether informational or proposed standard > is > being sought for this draft. > > Pete. > > ============================================= > Pete Cordell > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: "Christian Huitema" > To: "Pete Cordell" ; "Melinda Shore" > > Cc: "Jonathan Rosenberg" ; "Peterson, Jon" > ; "Mmusic" ; > Sent: 20 October 2003 20:27 > Subject: RE: [midcom] Re: [MMUSIC] Status of TURN > > > Individual submissions are a well established part of the process, and > should be considered a fine way to make progress when a working group > would not. There is a catch, however. Individual contributions are very > seldom published as proposed standards -- they normally end up as either > experimental or informational. The criteria for publishing something as > informational ought to be, demonstration of at least some significant > interest in the community -- but not necessarily demonstration of > consensus. The bar for refusing publication in the presence of enough > interest has to be somewhat high -- basically, the group has to be > convinced that implementing the proposal as is would damage the > Internet. > > Obviously, publication as a proposed standard would require the > equivalent of WG consensus. I don't believe there is such consensus on > TURN. > > -- Christian Huitema > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Nov 19 12:36:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28516 for ; Wed, 19 Nov 2003 12:36:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWFJ-0001ax-6e for midcom-archive@odin.ietf.org; Wed, 19 Nov 2003 12:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJHa552006108 for midcom-archive@odin.ietf.org; Wed, 19 Nov 2003 12:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWFF-0001a5-Q3; Wed, 19 Nov 2003 12:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAQM-0005nz-8L for midcom@optimus.ietf.org; Tue, 18 Nov 2003 13:18:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05156 for ; Tue, 18 Nov 2003 13:17:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAQK-0002Xe-00 for midcom@ietf.org; Tue, 18 Nov 2003 13:18:00 -0500 Received: from imo-m05.mx.aol.com ([64.12.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AMAQJ-0002XQ-00 for midcom@ietf.org; Tue, 18 Nov 2003 13:17:59 -0500 Received: from Juberti@aol.com by imo-m05.mx.aol.com (mail_out_v36_r1.1.) id l.17b.222cc57f (16112) for ; Tue, 18 Nov 2003 13:17:05 -0500 (EST) Received: from pc-sn654362.ad.aol.aoltw.net (ac9b5940.ipt.aol.com [172.155.89.64]) by air-id12.mx.aol.com (v97.8) with ESMTP id MAILINID124-3ef03fba62202f4; Tue, 18 Nov 2003 13:17:05 -0500 Date: Tue, 18 Nov 2003 13:17:05 -0500 From: "Justin Uberti" To: midcom@ietf.org Message-ID: <3FBA6221.8000104@aol.com> X-Mailer: AOL Communicator (20030919.3 Win) Organization: America Online MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-AOL-IP: 172.155.89.64 Subject: [midcom] Reference STUN servers? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hello, I have been testing my STUN client library against the two public STUN servers I know of, stun01.sipphone.com, and larry.gloo.net. However, I am not getting the results I expect - when I send a binding request to the server and get back a CHANGED-ADDRESS, and then send a second binding request to the CHANGED-ADDRESS, the servers reply to the binding request from a different port (i.e. not the one from the CHANGED-ADDRESS). I am not setting any CHANGE-REQUEST flags. ex: sending request to stun01.sipphone.com (69.0.208.27:3478) received reply from 609.0.208.27:3478 source address = 69.0.208.27:3478 changed address = 69.0.209.22:3479 sending request to 69.0.209.22:3479 received reply from 69.0.209.22:3478 <----------- BAD source address = 69.0.209.22:3479 changed address = 69.0.209.27:3478 I assume this is not the correct behavior, as it causes the NAT detection flow proposed in the STUN RFC to detect port-restricted-cone NATs as symmetric NATs. Does anyone know of any running 'reference' servers that are known to behave correctly? Thanks in advance, Justin Uberti _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Nov 20 02:35:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20888 for ; Thu, 20 Nov 2003 02:35:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjLK-0004Uy-O7 for midcom-archive@odin.ietf.org; Thu, 20 Nov 2003 02:35:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK7ZATU017269 for midcom-archive@odin.ietf.org; Thu, 20 Nov 2003 02:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjLB-0004TI-IM; Thu, 20 Nov 2003 02:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjKy-0004PX-BV for midcom@optimus.ietf.org; Thu, 20 Nov 2003 02:34:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20822 for ; Thu, 20 Nov 2003 02:34:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjKv-0005UG-00 for midcom@ietf.org; Thu, 20 Nov 2003 02:34:45 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AMjKu-0005TA-00 for midcom@ietf.org; Thu, 20 Nov 2003 02:34:44 -0500 Received: from dynamicsoft.com ([63.113.46.66]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAK7YEca019590; Thu, 20 Nov 2003 02:34:14 -0500 (EST) Message-ID: <3FBC6E72.7020700@dynamicsoft.com> Date: Thu, 20 Nov 2003 02:34:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Uberti CC: midcom@ietf.org Subject: Re: [midcom] Reference STUN servers? References: <3FBA6221.8000104@aol.com> In-Reply-To: <3FBA6221.8000104@aol.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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You are correct that this is not the behavior implied by the specification. -Jonathan R. Justin Uberti wrote: > Hello, > > I have been testing my STUN client library against the two public STUN > servers I know of, stun01.sipphone.com, and larry.gloo.net. However, I > am not getting the results I expect - when I send a binding request to > the server and get back a CHANGED-ADDRESS, and then send a second > binding request to the CHANGED-ADDRESS, the servers reply to the binding > request from a different port (i.e. not the one from the > CHANGED-ADDRESS). I am not setting any CHANGE-REQUEST flags. > > ex: > sending request to stun01.sipphone.com (69.0.208.27:3478) > received reply from 609.0.208.27:3478 > source address = 69.0.208.27:3478 > changed address = 69.0.209.22:3479 > > sending request to 69.0.209.22:3479 > received reply from 69.0.209.22:3478 <----------- BAD > source address = 69.0.209.22:3479 > changed address = 69.0.209.27:3478 > > I assume this is not the correct behavior, as it causes the NAT > detection flow proposed in the STUN RFC to detect port-restricted-cone > NATs as symmetric NATs. Does anyone know of any running 'reference' > servers that are known to behave correctly? > > Thanks in advance, > Justin Uberti > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Nov 20 14:59:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21354 for ; Thu, 20 Nov 2003 14:59:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuxF-0005jG-D6 for midcom-archive@odin.ietf.org; Thu, 20 Nov 2003 14:59:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJx59l022021 for midcom-archive@odin.ietf.org; Thu, 20 Nov 2003 14:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuxB-0005ic-AP; Thu, 20 Nov 2003 14:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuwf-0005hw-Ic for midcom@optimus.ietf.org; Thu, 20 Nov 2003 14:58:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21315 for ; Thu, 20 Nov 2003 14:58:15 -0500 (EST) From: les.carter@newkinetics.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuwc-0001Lq-00 for midcom@ietf.org; Thu, 20 Nov 2003 14:58:26 -0500 Received: from sentinel.newkinetics.com ([66.92.184.212] helo=workhorse.newkinetics.com) by ietf-mx with esmtp (Exim 4.12) id 1AMuwa-0001Le-00 for midcom@ietf.org; Thu, 20 Nov 2003 14:58:25 -0500 Received: from workhorse.newkinetics.com (localhost [127.0.0.1]) by workhorse.newkinetics.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id hAKK4l2j018339; Thu, 20 Nov 2003 12:04:47 -0800 Received: (from carterl@localhost) by workhorse.newkinetics.com (8.12.2/8.12.2/Submit) id hAKK4lfN018338; Thu, 20 Nov 2003 12:04:47 -0800 Date: Thu, 20 Nov 2003 12:04:47 -0800 Message-Id: <200311202004.hAKK4lfN018338@workhorse.newkinetics.com> X-Authentication-Warning: workhorse.newkinetics.com: carterl set sender to les.carter@newkinetics.com using -f To: midcom@ietf.org X-Originating-IP: 207.20.176.130 X-Mailer: Usermin 1.000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1069358687" X-Virus-Scanned: by amavis-milter (http://amavis.org/) Subject: [midcom] Re: Reference STUN servers? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --bound1069358687 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi Justin, I noticed the same behaviour. You (and anyone else) can use our beta server if they like, available at stun01.newkinetics.com If you get any problems with it email me directly at les.carter@newkinetics.com. It's just going through testing right now, and at present doesn't support the TLS part of the spec (, to be implemented in the next month or so). Hope this helps, Les _-- > > Message: 1 > Date: Tue, 18 Nov 2003 13:17:05 -0500 > From: "Justin Uberti" > To: midcom@ietf.org > Organization: America Online > Subject: [midcom] Reference STUN servers? > > Hello, > > I have been testing my STUN client library against the two public STUN > servers I know of, stun01.sipphone.com, and larry.gloo.net. However, I > am not getting the results I expect - when I send a binding request to > the server and get back a CHANGED-ADDRESS, and then send a second > binding request to the CHANGED-ADDRESS, the servers reply to the binding > request from a different port (i.e. not the one from the > CHANGED-ADDRESS). I am not setting any CHANGE-REQUEST flags. > > ex: > sending request to stun01.sipphone.com (69.0.208.27:3478) > received reply from 609.0.208.27:3478 > source address = 69.0.208.27:3478 > changed address = 69.0.209.22:3479 > > sending request to 69.0.209.22:3479 > received reply from 69.0.209.22:3478 <----------- BAD > source address = 69.0.209.22:3479 > changed address = 69.0.209.27:3478 > > I assume this is not the correct behavior, as it causes the NAT > detection flow proposed in the STUN RFC to detect port-restricted-cone > NATs as symmetric NATs. Does anyone know of any running 'reference' > servers that are known to behave correctly? > > Thanks in advance, > Justin Uberti > > --bound1069358687-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Nov 23 21:45:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08379 for ; Sun, 23 Nov 2003 21:45:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO6im-0007KL-KM for midcom-archive@odin.ietf.org; Sun, 23 Nov 2003 21:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO2j4JN028161 for midcom-archive@odin.ietf.org; Sun, 23 Nov 2003 21:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO6ik-0007Jg-OD; Sun, 23 Nov 2003 21:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO6iH-0007In-Tb for midcom@optimus.ietf.org; Sun, 23 Nov 2003 21:44:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08370 for ; Sun, 23 Nov 2003 21:44:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO6iE-0003EO-00 for midcom@ietf.org; Sun, 23 Nov 2003 21:44:30 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AO6iE-0003E3-00 for midcom@ietf.org; Sun, 23 Nov 2003 21:44:30 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2003 18:45:15 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAO2hpw5025335; Sun, 23 Nov 2003 18:43:59 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn3-960.cisco.com [10.21.67.192]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKE89822; Sun, 23 Nov 2003 18:43:46 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 23 Nov 2003 16:45:58 -0800 Subject: Re: [midcom] Reference STUN servers? From: Cullen Jennings To: Justin Uberti , Midcom , Message-ID: In-Reply-To: <3FBA6221.8000104@aol.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The best list to get this fixed would probably be email to stun@vovida.org. Can you send me an ethereal dump with the message you send and the response. I will see if I can get it fixed on the larry.gloo.net server - I don't think this should be happening. Cullen On 11/18/03 10:17 AM, "Justin Uberti" wrote: > Hello, > > I have been testing my STUN client library against the two public STUN > servers I know of, stun01.sipphone.com, and larry.gloo.net. However, I > am not getting the results I expect - when I send a binding request to > the server and get back a CHANGED-ADDRESS, and then send a second > binding request to the CHANGED-ADDRESS, the servers reply to the binding > request from a different port (i.e. not the one from the > CHANGED-ADDRESS). I am not setting any CHANGE-REQUEST flags. > > ex: > sending request to stun01.sipphone.com (69.0.208.27:3478) > received reply from 609.0.208.27:3478 > source address = 69.0.208.27:3478 > changed address = 69.0.209.22:3479 > > sending request to 69.0.209.22:3479 > received reply from 69.0.209.22:3478 <----------- BAD > source address = 69.0.209.22:3479 > changed address = 69.0.209.27:3478 > > I assume this is not the correct behavior, as it causes the NAT > detection flow proposed in the STUN RFC to detect port-restricted-cone > NATs as symmetric NATs. Does anyone know of any running 'reference' > servers that are known to behave correctly? > > Thanks in advance, > Justin Uberti > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Nov 24 08:57:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08335 for ; Mon, 24 Nov 2003 08:57:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHD5-0002at-4o for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 08:57:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODv3pC009928 for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 08:57:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHD2-0002ZN-TP; Mon, 24 Nov 2003 08:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHCZ-0002Z1-9m for midcom@optimus.ietf.org; Mon, 24 Nov 2003 08:56:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08310 for ; Mon, 24 Nov 2003 08:56:16 -0500 (EST) From: Albrecht.Schwarz@alcatel.de Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOHCX-0005Ft-00 for midcom@ietf.org; Mon, 24 Nov 2003 08:56:29 -0500 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1AOHCX-0005Ef-00 for midcom@ietf.org; Mon, 24 Nov 2003 08:56:29 -0500 Received: from slsas5.stgl.netd.alcatel.de (destgs0000c.ad1.ad.alcatel.com [149.204.45.57]) by mailrelay1.alcatel.de (8.12.10/8.12.10) with ESMTP id hAODtnYC000020; Mon, 24 Nov 2003 13:55:49 GMT To: midcom@ietf.org Cc: snmpv3@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 Nov 2003 14:55:47 +0100 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 11/24/2003 02:55:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] MIDCOM Protocol Semantics <-> SNMPv3 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Dear MIDCOM experts The "semantics draft" is now going for informational RFC in my understanding. SNMPv3 was recommended as MIDCOM protocol end of last year to my knowledge. I'm wondering whether (1) SNMPv3 is used as "MIDCOM protocol syntax" for the "MIDCOM Protocol Semantics"? and (2) if yes, will there be an additional "MIB plane" for provisioning midcom boxes (besides the dynamic configuration actions according "MIDCOM Protocol Semantics")? Thanks, Albrecht Schwarz ALCATEL _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Nov 24 08:57:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08336 for ; Mon, 24 Nov 2003 08:57:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHD5-0002au-53 for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 08:57:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODv33A009922 for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 08:57:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHD2-0002ZF-Hr; Mon, 24 Nov 2003 08:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHCW-0002Yw-KZ for midcom@optimus.ietf.org; Mon, 24 Nov 2003 08:56:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08307 for ; Mon, 24 Nov 2003 08:56:13 -0500 (EST) From: Albrecht.Schwarz@alcatel.de Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOHCV-0005Fg-00 for midcom@ietf.org; Mon, 24 Nov 2003 08:56:27 -0500 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1AOHCP-0005EH-00 for midcom@ietf.org; Mon, 24 Nov 2003 08:56:22 -0500 Received: from slsas5.stgl.netd.alcatel.de (destgs0000c.ad1.ad.alcatel.com [149.204.45.57]) by mailrelay1.alcatel.de (8.12.10/8.12.10) with ESMTP id hAODtnYC000020; Mon, 24 Nov 2003 13:55:49 GMT To: midcom@ietf.org Cc: snmpv3@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 Nov 2003 14:55:47 +0100 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 11/24/2003 02:55:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-virus-scanned: hAODtnYC000020 at mailrelay1.alcatel.de Subject: [midcom] MIDCOM Protocol Semantics <-> SNMPv3 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Dear MIDCOM experts The "semantics draft" is now going for informational RFC in my understanding. SNMPv3 was recommended as MIDCOM protocol end of last year to my knowledge. I'm wondering whether (1) SNMPv3 is used as "MIDCOM protocol syntax" for the "MIDCOM Protocol Semantics"? and (2) if yes, will there be an additional "MIB plane" for provisioning midcom boxes (besides the dynamic configuration actions according "MIDCOM Protocol Semantics")? Thanks, Albrecht Schwarz ALCATEL _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Nov 24 09:08:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08635 for ; Mon, 24 Nov 2003 09:08:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHNk-0003Fi-OH for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 09:08:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOE841v012473 for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 09:08:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHNh-0003Dn-9U; Mon, 24 Nov 2003 09:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHMu-00033U-6o for midcom@optimus.ietf.org; Mon, 24 Nov 2003 09:07:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08615 for ; Mon, 24 Nov 2003 09:06:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOHMs-0005Xd-00 for midcom@ietf.org; Mon, 24 Nov 2003 09:07:10 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AOHMs-0005Wo-00 for midcom@ietf.org; Mon, 24 Nov 2003 09:07:10 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hAOE6cD1042609 for ; Mon, 24 Nov 2003 15:06:39 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hAOE3elk042382 for ; Mon, 24 Nov 2003 15:03:40 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hAOE3eCx042380; Mon, 24 Nov 2003 15:03:40 +0100 (CET) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4AEA233057; Mon, 24 Nov 2003 15:03:39 +0100 (CET) Date: Mon, 24 Nov 2003 15:03:37 +0100 From: Martin Stiemerling To: Albrecht.Schwarz@alcatel.de Cc: midcom@ietf.org Subject: Re: [midcom] MIDCOM Protocol Semantics <-> SNMPv3 Message-ID: <129550000.1069682617@n-stiemerling.office> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, | Dear MIDCOM experts | | The "semantics draft" is now going for informational RFC in my | understanding. SNMPv3 was recommended as MIDCOM protocol end of last | year to my knowledge. Yes, it is. SNMPv3 is the MIDCOM protocol. | I'm wondering whether | (1) SNMPv3 is used as "MIDCOM protocol syntax" for the "MIDCOM Protocol | Semantics"? The MIDCOM protocol will be implemented as a MIB module. | and | (2) if yes, will there be an additional "MIB plane" for provisioning | midcom boxes (besides the dynamic configuration actions according | "MIDCOM Protocol Semantics")? That's a question to the WG chair. Martin Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Nov 24 09:35:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09587 for ; Mon, 24 Nov 2003 09:35:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHnr-000591-CH for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 09:35:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOEZ3H7019751 for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 09:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHnp-00056V-Ug; Mon, 24 Nov 2003 09:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOHnL-00051V-V6 for midcom@optimus.ietf.org; Mon, 24 Nov 2003 09:34:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09518 for ; Mon, 24 Nov 2003 09:34:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOHnJ-00063D-00 for midcom@ietf.org; Mon, 24 Nov 2003 09:34:29 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOHnJ-00062d-00 for midcom@ietf.org; Mon, 24 Nov 2003 09:34:29 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAOEXtAt024966; Mon, 24 Nov 2003 06:33:56 -0800 (PST) Received: from cisco.com ([10.25.65.179]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AON10644; Mon, 24 Nov 2003 06:33:54 -0800 (PST) Date: Mon, 24 Nov 2003 09:33:52 -0500 Subject: Re: [midcom] MIDCOM Protocol Semantics <-> SNMPv3 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Albrecht.Schwarz@alcatel.de, midcom@ietf.org To: Martin Stiemerling From: Melinda Shore In-Reply-To: <129550000.1069682617@n-stiemerling.office> Message-Id: <39C12254-1E8B-11D8-8485-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, November 24, 2003, at 09:03 AM, Martin Stiemerling wrote: > and > | (2) if yes, will there be an additional "MIB plane" for provisioning > | midcom boxes (besides the dynamic configuration actions according > | "MIDCOM Protocol Semantics")? > That's a question to the WG chair. I think it's actually a question for somebody else. Provisioning is clearly out of scope for this working group. There's not any work going on that I'm aware of (modulo the NAT MIB, which is NAT- specific). Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Nov 24 09:54:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10165 for ; Mon, 24 Nov 2003 09:54:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOI6D-0006tY-RT for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 09:54:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOEs1HH026504 for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 09:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOI6D-0006tK-7T; Mon, 24 Nov 2003 09:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOI5p-0006sP-Uu for midcom@optimus.ietf.org; Mon, 24 Nov 2003 09:53:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10152 for ; Mon, 24 Nov 2003 09:53:22 -0500 (EST) From: Albrecht.Schwarz@alcatel.de Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOI5o-0006JN-00 for midcom@ietf.org; Mon, 24 Nov 2003 09:53:36 -0500 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1AOI5n-0006Ir-00 for midcom@ietf.org; Mon, 24 Nov 2003 09:53:35 -0500 Received: from slsas5.stgl.netd.alcatel.de (destgs0000c.ad1.ad.alcatel.com [149.204.45.57]) by mailrelay1.alcatel.de (8.12.10/8.12.10) with ESMTP id hAOEr3YC028375 for ; Mon, 24 Nov 2003 14:53:03 GMT Subject: Re: [midcom] MIDCOM Protocol Semantics <-> SNMPv3 To: midcom@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 24 Nov 2003 15:53:02 +0100 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 11/24/2003 03:53:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-virus-scanned: hAOEr3YC028375 at mailrelay1.alcatel.de Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Melinda & Martin, thanks for your quick and precise responses! Kind regards, Albrecht ----- Forwarded by Albrecht SCHWARZ/DE/ALCATEL on 24.11.2003 15:51 ----- Melinda Shore m> cc: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, midcom@ietf.org Sent by: Subject: Re: [midcom] MIDCOM Protocol Semantics <-> SNMPv3 midcom-admin@iet f.org 24.11.2003 15:33 On Monday, November 24, 2003, at 09:03 AM, Martin Stiemerling wrote: > and > | (2) if yes, will there be an additional "MIB plane" for provisioning > | midcom boxes (besides the dynamic configuration actions according > | "MIDCOM Protocol Semantics")? > That's a question to the WG chair. I think it's actually a question for somebody else. Provisioning is clearly out of scope for this working group. There's not any work going on that I'm aware of (modulo the NAT MIB, which is NAT- specific). Melinda |---------+---------------------------------> | | Martin Stiemerling | | | | | | Sent by: | | | midcom-admin@ietf.org | | | | | | | | | 24.11.2003 15:03 | | | | |---------+---------------------------------> >------------------------------------------------------------------------------------------------------------| | | | To: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL | | cc: midcom@ietf.org | | Subject: Re: [midcom] MIDCOM Protocol Semantics <-> SNMPv3 | >------------------------------------------------------------------------------------------------------------| Hi, | Dear MIDCOM experts | | The "semantics draft" is now going for informational RFC in my | understanding. SNMPv3 was recommended as MIDCOM protocol end of last | year to my knowledge. Yes, it is. SNMPv3 is the MIDCOM protocol. | I'm wondering whether | (1) SNMPv3 is used as "MIDCOM protocol syntax" for the "MIDCOM Protocol | Semantics"? The MIDCOM protocol will be implemented as a MIB module. | and | (2) if yes, will there be an additional "MIB plane" for provisioning | midcom boxes (besides the dynamic configuration actions according | "MIDCOM Protocol Semantics")? That's a question to the WG chair. Martin Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Nov 24 11:51:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15578 for ; Mon, 24 Nov 2003 11:51:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJvX-0007UI-Rg for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 11:51:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOGp75B028778 for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 11:51:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJvS-0007Ti-8L; Mon, 24 Nov 2003 11:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJut-0007T5-QQ for midcom@optimus.ietf.org; Mon, 24 Nov 2003 11:50:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15555 for ; Mon, 24 Nov 2003 11:50:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJus-0000CD-00 for midcom@ietf.org; Mon, 24 Nov 2003 11:50:26 -0500 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1AOJur-0000CA-00 for midcom@ietf.org; Mon, 24 Nov 2003 11:50:25 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id LAA29955 for ; Mon, 24 Nov 2003 11:51:18 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma029939; Mon, 24 Nov 03 11:51:10 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 24 Nov 2003 11:50:14 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 24 Nov 2003 11:50:14 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 Nov 2003 11:50:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] MIDCOM Protocol Semantics <-> SNMPv3 Date: Mon, 24 Nov 2003 11:50:14 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA013B1248@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] MIDCOM Protocol Semantics <-> SNMPv3 Thread-Index: AcOykt3NHbqQ5fv5Sp2/DGEgqVCexgAFHtZw From: "Harrington, David" To: X-OriginalArrivalTime: 24 Nov 2003 16:50:14.0942 (UTC) FILETIME=[0891A3E0:01C3B2AB] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:80.8653 M:99.5542 P:95.9108 R:95.9108 S:71.0311 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Albrecht, The terminology you use in your question means different things to different people.=20 Let me try to answer what I think you're asking. The MIDCOM MIB work is designed to enable the dynamic changes to firewalls and NATs for discrete uses as described in the semantics document. The design team is utilizing existing mib modules where possible, and supplementing those mib modules with a midcom-specific mib module.=20 The MIDCOM MIB will help coordinate the dynamic changes to the configuration in the leveraged mib modules for midcom-specific purposes. For example, the MIDCOM MIB will be used to coordinate the length and owner of a midcom session, concepts not naturally part of a firewall or a NAT or SNMPv3 permissions. For firewall management, the design team will leverage the capabilities of the IPSP MIB, including rule specification and rule groupings. For NAT management, the design team will leverage the NAT MIB, including public and private addresses and binds. For security, the design team will leverage the security features of SNMPv3, including which midcom agents are authorized to modify which mib modules. These "leveraged" mibs will allow you to provision firewalls and NATS and permissions, beyond that for midcom purposes (depending of course on what you're trying to provision).=20 So for provisioning of firewalls, look at the IPSP MIB. This has expired in the I-D respository, and is in the process of being rewritten into three smaller mib modules, which hopefully will be published soon, and announced to the midcom WG. For NAT provisioning, look for draft-ietf-nat-natmib-07.txt. I hope this helps, dbh > -----Original Message----- > From: Albrecht.Schwarz@alcatel.de=20 > [mailto:Albrecht.Schwarz@alcatel.de]=20 > Sent: Monday, November 24, 2003 8:56 AM > To: midcom@ietf.org > Cc: snmpv3@lists.tislabs.com > Subject: [midcom] MIDCOM Protocol Semantics <-> SNMPv3 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Dear MIDCOM experts >=20 > The "semantics draft" is now going for informational RFC in my > understanding. SNMPv3 was recommended as MIDCOM protocol end of last > year to my knowledge. > I'm wondering whether > (1) SNMPv3 is used as "MIDCOM protocol syntax" for the=20 > "MIDCOM Protocol > Semantics"? > and > (2) if yes, will there be an additional "MIB plane" for provisioning > midcom boxes (besides the dynamic configuration actions according > "MIDCOM Protocol Semantics")? >=20 > Thanks, > Albrecht Schwarz > ALCATEL >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Nov 24 17:47:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07932 for ; Mon, 24 Nov 2003 17:47:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPTz-0008Bq-Kb for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 17:47:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOMl3dE031478 for midcom-archive@odin.ietf.org; Mon, 24 Nov 2003 17:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPTx-0008B3-C1; Mon, 24 Nov 2003 17:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPTS-0008AS-H2 for midcom@optimus.ietf.org; Mon, 24 Nov 2003 17:46:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07860 for ; Mon, 24 Nov 2003 17:46:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOPTP-0007eN-00 for midcom@ietf.org; Mon, 24 Nov 2003 17:46:28 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AOPTP-0007di-00 for midcom@ietf.org; Mon, 24 Nov 2003 17:46:27 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hAOMjsD3067621 for ; Mon, 24 Nov 2003 23:45:56 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hAOMjoYg067619 for ; Mon, 24 Nov 2003 23:45:50 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hAOMjnCx067616; Mon, 24 Nov 2003 23:45:50 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E19CF1112C; Mon, 24 Nov 2003 23:45:46 +0100 (CET) Date: Mon, 24 Nov 2003 23:47:30 +0100 From: Juergen Quittek To: Melinda Shore , Martin Stiemerling Cc: Albrecht.Schwarz@alcatel.de, midcom@ietf.org Subject: Re: [midcom] MIDCOM Protocol Semantics <-> SNMPv3 Message-ID: <2147483647.1069717650@[10.1.1.26]> In-Reply-To: <39C12254-1E8B-11D8-8485-000A95E35274@cisco.com> References: <39C12254-1E8B-11D8-8485-000A95E35274@cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda, At the design team discussions in Minneapolis we found that we can group the requirements for the MIDCOM MIB. There are the requirements defined by the MIDCOM semantics. The semantics include some lately added features suggested by Suresh reflecting the existing NAT implementations. These requirements constitute one group, the MIDCOM protocol group. Beyond these, there are requirements that are not written down yet. Suresh said that a network management applications would require to get detailed information on which policy rule is liked to what entry in the NAT MIB. As far as I understood, David was in line with this. Wes told us that we need to add some means allowing a management application to set the firewall priority of MIDCOM policies in firewall. These requirements constitute a group that Martin and I call MIDCOM server management requirements. Shall we include these requirements that are not yet written down in the MIDCOM MIB or shall we exclude them? I think there are good reasons to support them although they are rather on the 'MIB plane'. Juergen --On 24.11.2003 9:33 Uhr -0500 Melinda Shore wrote: > On Monday, November 24, 2003, at 09:03 AM, Martin Stiemerling wrote: >> and >> | (2) if yes, will there be an additional "MIB plane" for provisioning >> | midcom boxes (besides the dynamic configuration actions according >> | "MIDCOM Protocol Semantics")? >> That's a question to the WG chair. > > I think it's actually a question for somebody else. Provisioning > is clearly out of scope for this working group. There's not any > work going on that I'm aware of (modulo the NAT MIB, which is NAT- > specific). > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Nov 25 13:51:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01720 for ; Tue, 25 Nov 2003 13:51:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiHB-0007th-Pa for midcom-archive@odin.ietf.org; Tue, 25 Nov 2003 13:51:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPIp5me030358 for midcom-archive@odin.ietf.org; Tue, 25 Nov 2003 13:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiH8-0007tF-9Q; Tue, 25 Nov 2003 13:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiGQ-0007rE-ND for midcom@optimus.ietf.org; Tue, 25 Nov 2003 13:50:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01679 for ; Tue, 25 Nov 2003 13:50:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOiGO-0002o5-00 for midcom@ietf.org; Tue, 25 Nov 2003 13:50:16 -0500 Received: from imo-m02.mx.aol.com ([64.12.136.5]) by ietf-mx with esmtp (Exim 4.12) id 1AOiGN-0002n5-00 for midcom@ietf.org; Tue, 25 Nov 2003 13:50:15 -0500 Received: from Juberti@aol.com by imo-m02.mx.aol.com (mail_out_v36_r1.1.) id c.54.1d3964da (16086); Tue, 25 Nov 2003 13:47:34 -0500 (EST) Received: from pc-sn654362.ad.aol.aoltw.net ([10.2.174.8]) by air-id10.mx.aol.com (v97.8) with ESMTP id MAILINID103-3ed63fc3a3c6155; Tue, 25 Nov 2003 13:47:34 -0500 Date: Tue, 25 Nov 2003 13:47:39 -0500 From: "Justin Uberti" Subject: Re: [midcom] Reference STUN servers? To: "Cullen Jennings" cc: Midcom , les.carter@newkinetics.com, stun@vovida.org Message-ID: <3FC3A3CB.2000704@aol.com> X-Mailer: AOL Communicator (20030919.3 Win) Organization: America Online MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=74373703-41-1069786059-1684 Content-Transfer-Encoding: 8BIT X-AOL-IP: 10.2.174.8 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --74373703-41-1069786059-1684 Content-Type: TEXT/HTML; CHARSET=us-ascii Hi,

Thanks for getting back to me.

Here is a ethereal dump of a NAT discovery process for a restricted cone NAT against the larry.gloo.net server. (The stun01.sipphone.com server behaves similarly, I assume they both use the Vovida STUN library).

Pay particular attention to frames 10 and 11. 10 is the outgoing Type-I request to the CHANGED-ADDRESS; note that the destination port is 3479. 11 is the reply to that request; note that the source port is 3478, which as Jonathan Rosenberg pointed out, is incorrect behavior.

The Vovida STUN library has a number of problems. Looking at the stun.cxx file at the lines 1190-1200, it is clear that the code does not look at what port the request is received on, the 'recvAlt' variable is only set based on the IP address used. As a result, when the time comes to send the reply, the reply to a CHANGED-ADDRESS request is on the wrong port.

The Vovida library also does the NAT detection process incorrectly, with the result typically being that most NATs are incorrectly detected as Full Cones.

I did try the stun01.newkinetics.com server and it seemed to work fine.

Regards,
Justin Uberti
Chief Architect
America Online

Cullen Jennings wrote on 11/23/2003, 7:45 PM:

>
> The best list to get this fixed would probably be email to
> stun@vovida.org.
>
> Can you send me an ethereal dump with the message you send and the
> response.
> I will see if I can get it fixed on the larry.gloo.net server - I don't
> think this should be happening.
>
> Cullen
>
>
> On 11/18/03 10:17 AM, "Justin Uberti" <juberti@aol.com> wrote:
>
> > Hello,
> >
> > I have been testing my STUN client library against the two public STUN
> > servers I know of, stun01.sipphone.com, and larry.gloo.net. However, I
> > am not getting the results I expect - when I send a binding request to
> > the server and get back a CHANGED-ADDRESS, and then send a second
> > binding request to the CHANGED-ADDRESS, the servers reply to the
> binding
> > request from a different port (i.e. not the one from the
> > CHANGED-ADDRESS). I am not setting any CHANGE-REQUEST flags.
> >
> > ex:
> > sending request to stun01.sipphone.com (69.0.208.27:3478)
> > received reply from 609.0.208.27:3478
> > source address = 69.0.208.27:3478
> > changed address = 69.0.209.22:3479
> >
> > sending request to 69.0.209.22:3479
> > received reply from 69.0.209.22:3478 <----------- BAD
> > source address = 69.0.209.22:3479
> > changed address = 69.0.209.27:3478
> >
> > I assume this is not the correct behavior, as it causes the NAT
> > detection flow proposed in the STUN RFC to detect port-restricted-cone
> > NATs as symmetric NATs. Does anyone know of any running 'reference'
> > servers that are known to behave correctly?
> >
> > Thanks in advance,
> > Justin Uberti
> >
> >
> > _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > https://www1.ietf.org/mailman/listinfo/midcom
> >
>

  --74373703-41-1069786059-1684 Content-Type: APPLICATION/OCTET-STREAM; NAME="stun-larry-gloo-net-bad-port.cap" Content-ID: Content-Disposition: ATTACHMENT; FILENAME="stun-larry-gloo-net-bad-port.cap" Content-Transfer-Encoding: BASE64 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAhZrDP4/KDAA+AAAAPgAAAAAGJdw3FQAGW4bHAggA RQAAMAXQAACAEQAAwKgBykIH7tIGkA2WAByaFgABAAAAAAAAAAAAAAAAAACgNL33hZrDP3lZ DgBiAAAAYgAAAAAGW4bHAgAGJdw3FQgARQAAVAAAQAAvEVhNQgfu0sCoAcoNlgaQAEBI9AEB ACQAAAAAAAAAAAAAAACgNL33AAEACAABBpCsiB+UAAQACAABDZZCB+7SAAUACAABDZdCB+7V hZrDP/hxDgA+AAAAPgAAAAAGJdw3FQAGW4bHAggARQAAMAXRAACAEQAAwKgBykIH7tIGkA2W AByaFgABAAAAAAAAAAAAAAAAAACgNL33hprDPxwjAABGAAAARgAAAAAGJdw3FQAGW4bHAggA RQAAOAXSAACAEQAAwKgBykIH7tIGkA2WACTn5wABAAgAAAAAAAAAAAAAAACgN2/+AAMABAAA AAaGmsM/esEAAGIAAABiAAAAAAZbhscCAAYl3DcVCABFAABUAABAAC8RWE1CB+7SwKgByg2W BpAAQEj0AQEAJAAAAAAAAAAAAAAAAKA0vfcAAQAIAAEGkKyIH5QABAAIAAENlkIH7tIABQAI AAENl0IH7tWGmsM/ks0BAEYAAABGAAAAAAYl3DcVAAZbhscCCABFAAA4BdMAAIARAADAqAHK Qgfu0gaQDZYAJOfnAAEACAAAAAAAAAAAAAAAAKA3b/4AAwAEAAAABoaawz/z5wQARgAAAEYA AAAABiXcNxUABluGxwIIAEUAADgF1AAAgBEAAMCoAcpCB+7SBpANlgAk5+cAAQAIAAAAAAAA AAAAAAAAoDdv/gADAAQAAAAGhprDPxMeCwBGAAAARgAAAAAGJdw3FQAGW4bHAggARQAAOAXV AACAEQAAwKgBykIH7tIGkA2WACTn5wABAAgAAAAAAAAAAAAAAACgN2/+AAMABAAAAAaHmsM/ 5z0IAEYAAABGAAAAAAYl3DcVAAZbhscCCABFAAA4BdYAAIARAADAqAHKQgfu0gaQDZYAJOfn AAEACAAAAAAAAAAAAAAAAKA3b/4AAwAEAAAABomawz8//wIAPgAAAD4AAAAABiXcNxUABluG xwIIAEUAADAF1wAAgBEAAMCoAcpCB+7VBpANlwAcYGcAAQAAAAAAAAAAAAAAAAAAoGf3b4ma wz+hkgQAYgAAAGIAAAAABluGxwIABiXcNxUIAEUAAFQAAEAALxFYSkIH7tXAqAHKDZYGkABA D0YBAQAkAAAAAAAAAAAAAAAAoGf3bwABAAgAAQaQrIgflAAEAAgAAQ2XQgfu1QAFAAgAAQ2W Qgfu0omawz9EqgQAPgAAAD4AAAAABiXcNxUABluGxwIIAEUAADAF2AAAgBEAAMCoAcpCB+7V BpANlwAcYGcAAQAAAAAAAAAAAAAAAAAAoGf3b4mawz+CnQUARgAAAEYAAAAABiXcNxUABluG xwIIAEUAADgF2QAAgBEAAMCoAcpCB+7SBpANlgAk2ZAAAQAIAAAAAAAAAAAAAAAAoGp+JgAD AAQAAAACiZrDP9o7BgBiAAAAYgAAAAAGW4bHAgAGJdw3FQgARQAAVAAAQAAvEVhKQgfu1cCo AcoNlgaQAEAPRgEBACQAAAAAAAAAAAAAAACgZ/dvAAEACAABBpCsiB+UAAQACAABDZdCB+7V AAUACAABDZZCB+7SiZrDPx4zBwBiAAAAYgAAAAAGW4bHAgAGJdw3FQgARQAAVAAAQAAvEVhN Qgfu0sCoAcoNlwaQAECIjQEBACQAAAAAAAAAAAAAAACgan4mAAEACAABBpCsiB+UAAQACAAB DZdCB+7SAAUACAABDZdCB+7ViZrDP/FJBwBGAAAARgAAAAAGJdw3FQAGW4bHAggARQAAOAXa AACAEQAAwKgBykIH7tIGkA2WACTZkAABAAgAAAAAAAAAAAAAAACgan4mAAMABAAAAAKJmsM/ gd4IAGIAAABiAAAAAAZbhscCAAYl3DcVCABFAABUAABAAC8RWE1CB+7SwKgByg2XBpAAQIiN AQEAJAAAAAAAAAAAAAAAAKBqfiYAAQAIAAEGkKyIH5QABAAIAAENl0IH7tIABQAIAAENl0IH 7tWMmsM/PB8PAFUAAABVAAAAAAYl3DcVAAZbhscCCABFAABHBdwAAIARAADAqAHKwKgBAQQE ADUAM3fdJ7IBAAABAAAAAAAACmFvbGNjNDA0aHAGb2ZmaWNlA2FvbANjb20AAAEAAYyawz/D IA8AXAAAAFwAAAD///////8ABluGxwIIAEUAAE4F3gAAgBGvp8CoAcrAqAH/AIkAiQA6aPuo 2gEQAAEAAAAAAAAgRUJFUEVNRURFRERFREFERUVJRkFDQUNBQ0FDQUNBQ0EAACAAAQ== --74373703-41-1069786059-1684 Content-Type: TEXT/HTML; CHARSET=us-ascii
--74373703-41-1069786059-1684-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom