From mailnull@www1.ietf.org Wed May 7 04:23:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20465 for ; Wed, 7 May 2003 04:23:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h478WYJ24576 for midcom-archive@odin.ietf.org; Wed, 7 May 2003 04:32:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h478VL824454; Wed, 7 May 2003 04:31:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4788h823402 for ; Wed, 7 May 2003 04:08:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19910 for ; Wed, 7 May 2003 03:59:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DJrh-0006JI-00 for midcom@ietf.org; Wed, 07 May 2003 04:01:25 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19DJrg-0006J8-00 for midcom@ietf.org; Wed, 07 May 2003 04:01:24 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h4781jVI016566 for ; Wed, 7 May 2003 10:01:46 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 02D06A1936 for ; Wed, 7 May 2003 09:54:14 +0200 (CEST) Message-ID: <3EB8BD69.1000704@ccrle.nec.de> Date: Wed, 07 May 2003 10:01:45 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe 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] Semantics: Encryption in Session Establishment 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, after the last session at IETF-56 in San Francisco, somebody raised a concern with respect to the encryption method in the Session Establishment (SE) transaction. I would be happy if these concerns could be raised again on the mailling list. As far as I rember the concern was that carring encryption method information in the SE transaction is doubled work and should be left to an underlying protocol. Thanks in advance Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de 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 mailnull@www1.ietf.org Mon May 12 04:33:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05305 for ; Mon, 12 May 2003 04:33:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4C7wsS04772 for midcom-archive@odin.ietf.org; Mon, 12 May 2003 03:58:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4C7vZB04733; Mon, 12 May 2003 03:57:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4C7uEB04683 for ; Mon, 12 May 2003 03:56:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05269 for ; Mon, 12 May 2003 04:30:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19F8jI-00062B-00 for midcom@ietf.org; Mon, 12 May 2003 04:32:16 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19F8jH-000627-00 for midcom@ietf.org; Mon, 12 May 2003 04:32:15 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h4C8XFlS020774 for ; Mon, 12 May 2003 01:33:15 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h4C8XDbr025567 for ; Mon, 12 May 2003 03:33:13 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 May 2003 04:33:00 -0400 Message-ID: From: "Kurapati, mahesh" To: midcom@ietf.org Date: Mon, 12 May 2003 04:34:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [midcom] Clarification on RowStatus and Agent Capabilities Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi all, I am new to this group. Please direct me, if this is not the right forum to be asked. My question is regarding instrumentation of read-create objects, RowStatus and Agent Capabilities. Say a table has two columnar objects c1, c2 with read-create access in addition to a ROWSTATUS object r1. 1. Should a row be created when a set request is received on one of the columnar object (c1.) with a non existing instance? If a row is created, what shall be the value of RowStatus object? 2. Can the RowStatus be partially implemented? In the sense, for one of the table that we designed it does not make sense to have all the RowStatus values supported? In such scenarios, can we implement this object partially? 3. Can we change the AGENT-CAPABILITIES section in a standard MIB, if we take deviations from the standard definitions? Please clarify me, Thanks and Regards Mahesh _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon May 12 04:45:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05454 for ; Mon, 12 May 2003 04:45:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4C8BFI06449 for midcom-archive@odin.ietf.org; Mon, 12 May 2003 04:11:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4C8A6B06410; Mon, 12 May 2003 04:10:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4C89ZB06381 for ; Mon, 12 May 2003 04:09:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05437 for ; Mon, 12 May 2003 04:43:38 -0400 (EDT) From: hlpeth@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19F8wC-00065V-00 for midcom@ietf.org; Mon, 12 May 2003 04:45:36 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19F8wA-00064s-00 for midcom@ietf.org; Mon, 12 May 2003 04:45:35 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h4C8hp127310 for ; Mon, 12 May 2003 14:13:51 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h4C8hk927287; Mon, 12 May 2003 14:13:46 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h4C8kxd26487; Mon, 12 May 2003 14:16:59 +0530 (IST) Subject: Re: [midcom] Clarification on RowStatus and Agent Capabilities To: "Kurapati, mahesh" Cc: midcom@ietf.org Date: Mon, 12 May 2003 14:12:33 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/05/2003 02:11:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, Contact the SNMP forums, say snmpconf@snmp.com regards -- harish "Kurapati, mahesh" @ietf.org on 05/12/2003 02:04:51 PM Sent by: midcom-admin@ietf.org To: midcom@ietf.org cc: Subject: [midcom] Clarification on RowStatus and Agent Capabilities Hi all, I am new to this group. Please direct me, if this is not the right forum to be asked. My question is regarding instrumentation of read-create objects, RowStatus and Agent Capabilities. Say a table has two columnar objects c1, c2 with read-create access in addition to a ROWSTATUS object r1. 1. Should a row be created when a set request is received on one of the columnar object (c1.) with a non existing instance? If a row is created, what shall be the value of RowStatus object? 2. Can the RowStatus be partially implemented? In the sense, for one of the table that we designed it does not make sense to have all the RowStatus values supported? In such scenarios, can we implement this object partially? 3. Can we change the AGENT-CAPABILITIES section in a standard MIB, if we take deviations from the standard definitions? Please clarify me, Thanks and Regards Mahesh _______________________________________________ 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 mailnull@www1.ietf.org Mon May 12 09:43:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11815 for ; Mon, 12 May 2003 09:43:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CD8w727651 for midcom-archive@odin.ietf.org; Mon, 12 May 2003 09:08:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CD7bB27590; Mon, 12 May 2003 09:07:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CD6aB26667 for ; Mon, 12 May 2003 09:06:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11761 for ; Mon, 12 May 2003 09:40:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FDZW-0007kA-00 for midcom@ietf.org; Mon, 12 May 2003 09:42:31 -0400 Received: from adsl-66-127-127-227.dsl.scrm01.pacbell.net ([66.127.127.227] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 19FDZV-0007jw-00 for midcom@ietf.org; Mon, 12 May 2003 09:42:30 -0400 Received: (from hardaker@localhost) by localhost.localdomain (8.11.6/8.11.6) id h4CDhOi13298; Mon, 12 May 2003 06:43:24 -0700 To: "Kurapati, mahesh" Cc: midcom@ietf.org Subject: Re: [midcom] Clarification on RowStatus and Agent Capabilities References: From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories Date: Mon, 12 May 2003 06:43:24 -0700 In-Reply-To: (mahesh Kurapati's message of "Mon, 12 May 2003 04:34:51 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: , >>>>> On Mon, 12 May 2003 04:34:51 -0400, "Kurapati, mahesh" said: mahesh> 1. Should a row be created when a set request is received on mahesh> one of the columnar object (c1.) with a non mahesh> existing instance? If a row is created, what shall be the mahesh> value of RowStatus object? That is up to the MIB designer. You can document the behavior you want in the DESCRIPTION clause of the RowStatus column. Some RowStatus columns state that the RowStatus column MUST be set, others stay that rows can be created without using the RowStatus column. If done without, it should be equivalent to a "createAndGo". MAHESH> 2. Can the RowStatus be partially implemented? In the sense, MAHESH> for one of the table that we designed it does not make sense MAHESH> to have all the RowStatus values supported? In such MAHESH> scenarios, can we implement this object partially? One of the common things to do these days is to not require the use of createAndWait. Thus, in the IPSEC-POLICY-MIB we recently wrote: OBJECT ipspAutoIkeRowStatus SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } DESCRIPTION "Support of the values notInService(2), notReady(3), and createAndWait(5) is not required." mahesh> 3. Can we change the AGENT-CAPABILITIES section in a standard mahesh> MIB, if we take deviations from the standard definitions? Not sure what the question is... mahesh> Please clarify me, mahesh> Thanks and Regards mahesh> Mahesh mahesh> _______________________________________________ mahesh> midcom mailing list mahesh> midcom@ietf.org mahesh> https://www1.ietf.org/mailman/listinfo/midcom -- Wes Hardaker Network Associates Laboratories _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed May 14 12:34:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25807 for ; Wed, 14 May 2003 12:34:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4EG0cO27709 for midcom-archive@odin.ietf.org; Wed, 14 May 2003 12:00:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EFxKB27584; Wed, 14 May 2003 11:59:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EFvTB27466 for ; Wed, 14 May 2003 11:57:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25489 for ; Wed, 14 May 2003 12:30:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FzAw-0007Ho-00 for midcom@ietf.org; Wed, 14 May 2003 12:32:18 -0400 Received: from [12.25.1.120] (helo=ctron-dnm.enterasys.com ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 19FzAv-0007Hl-00 for midcom@ietf.org; Wed, 14 May 2003 12:32:17 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id MAA09413 for ; Wed, 14 May 2003 12:46:55 -0400 (EDT) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma009362; Wed, 14 May 03 12:46:46 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Wed, 14 May 2003 12:34:08 -0400 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 14 May 2003 12:34:08 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] Clarification on RowStatus and Agent Capabilities X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 14 May 2003 12:34:07 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA603240@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] Clarification on RowStatus and Agent Capabilities Thread-Index: AcMYY9y1eCTmBg7nSwSr0H0i/i6CWgB0mTAg From: "Harrington, David" To: , "Kurapati, mahesh" Cc: X-OriginalArrivalTime: 14 May 2003 16:34:08.0437 (UTC) FILETIME=[A4592E50:01C31A36] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4EFvTB27467 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The preferred list to ask about mib design is mibs@ops.ietf.org --- David Harrington dbh@enterasys.com co-chair, IETF SNMPv3 WG _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri May 16 03:06:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15474 for ; Fri, 16 May 2003 03:06:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4G6Y5215708 for midcom-archive@odin.ietf.org; Fri, 16 May 2003 02:34:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G6RkB15122; Fri, 16 May 2003 02:27:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G6QUB15090 for ; Fri, 16 May 2003 02:26:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15378 for ; Fri, 16 May 2003 02:58:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GZCS-0004vV-00 for midcom@ietf.org; Fri, 16 May 2003 03:00:16 -0400 Received: from [202.104.128.171] (helo=smtp.tencent.com) by ietf-mx with esmtp (Exim 4.12) id 19GZCK-0004vJ-00 for midcom@ietf.org; Fri, 16 May 2003 03:00:09 -0400 Received: mail from tencent.com by smtp.tencent.com (8.12.9/8.12.8) with ESMTP id h4G6pelT006744 for ; Fri, 16 May 2003 14:51:42 +0800 Received: from Jade (kim97.com [172.30.10.97] (may be forged)) by tencent.com (8.12.8/8.12.8) with SMTP id h4G6ulQM017294 for ; Fri, 16 May 2003 14:56:48 +0800 From: "Jade Chen Yan" To: Date: Fri, 16 May 2003 14:58:29 +0800 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [midcom] stun client Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , HI, List, It seem the STUN client should know at least 2 SERVER addr to determine the symmetric NAT, am I right? Best Regards, Jade begin 666 ATT00001.htm M/"%$3T-465!%($A434P@4%5"3$E#("(M+R]7,T,O+T141"!(5$U,(#,N,B\O M14XB/@T*/$A434P^#0H\2$5!1#X-"CQ-151!($A45% M15%5258](D-O;G1E M;G0M5'EP92(@0T].5$5.5#TB=&5X="]H=&UL.R!C:&%R6UM971R:6,@3D%4+"!A M;2!)(')I9VAT/SPO1D].5#X-"CPO4#X-"CQ"4CX-"@T*/% ^/$9/3E0@4TE: M13TR/D)E; Fri, 16 May 2003 03:47:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4G7FBq18910 for midcom-archive@odin.ietf.org; Fri, 16 May 2003 03:15:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G7E9B18886; Fri, 16 May 2003 03:14:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G7D9B18839 for ; Fri, 16 May 2003 03:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15926 for ; Fri, 16 May 2003 03:45:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GZvp-00054Z-00 for midcom@ietf.org; Fri, 16 May 2003 03:47:09 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19GZvj-00054G-00 for midcom@ietf.org; Fri, 16 May 2003 03:47:03 -0400 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 h4G7lGx5016381; Fri, 16 May 2003 00:47:17 -0700 (PDT) Received: from [192.168.1.5] (sjc-vpn1-146.cisco.com [10.21.96.146]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEF22861; Fri, 16 May 2003 00:47:16 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 16 May 2003 00:47:14 -0700 Subject: Re: [midcom] stun client From: Cullen Jennings To: Jade Chen Yan , Midcom Message-ID: In-Reply-To: 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 It only needs to know one to start with - it sends a message to that and in the response it finds out the other address. Cullen On 5/15/03 11:58 PM, "Jade Chen Yan" wrote: > HI, List, > > It seem the STUN client should know at least 2 SERVER addr to determine the > symmetric NAT, am I right? > > > Best Regards, > Jade > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri May 16 07:25:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19672 for ; Fri, 16 May 2003 07:25:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GAqni32680 for midcom-archive@odin.ietf.org; Fri, 16 May 2003 06:52:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GApWB32640; Fri, 16 May 2003 06:51:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GAoRB32557 for ; Fri, 16 May 2003 06:50:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19485; Fri, 16 May 2003 07:22:28 -0400 (EDT) Message-Id: <200305161122.HAA19485@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: Fri, 16 May 2003 07:22:28 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-02.txt 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: , --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 : MIDCOM Protocol Semantics Author(s) : M. Stiemerling et al. Filename : draft-ietf-midcom-semantics-02.txt Pages : 58 Date : 2003-5-15 This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or - more probably - a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-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-semantics-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-semantics-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: <2003-5-15150208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-15150208.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri May 16 09:51:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24705 for ; Fri, 16 May 2003 09:51:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GDJKq10399 for midcom-archive@odin.ietf.org; Fri, 16 May 2003 09:19:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GDIFB10305; Fri, 16 May 2003 09:18:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GDHUB10251 for ; Fri, 16 May 2003 09:17:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24623 for ; Fri, 16 May 2003 09:49:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GfcI-0007P1-00 for midcom@ietf.org; Fri, 16 May 2003 09:51:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19GfcH-0007Og-00 for midcom@ietf.org; Fri, 16 May 2003 09:51:21 -0400 Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4GDprdh013168; Fri, 16 May 2003 09:51:54 -0400 (EDT) Message-ID: <3EC4ECF5.4030308@dynamicsoft.com> Date: Fri, 16 May 2003 09:51:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Jade Chen Yan , Midcom Subject: Re: [midcom] stun client References: In-Reply-To: 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 To be clear, you don't need two servers either. The first server will return a new IP/port in the response. This can represent a different virtual interface on the same server. -Jonathan R. Cullen Jennings wrote: > It only needs to know one to start with - it sends a message to that and in > the response it finds out the other address. > > Cullen > > > On 5/15/03 11:58 PM, "Jade Chen Yan" wrote: > > >>HI, List, >> >>It seem the STUN client should know at least 2 SERVER addr to determine the >>symmetric NAT, am I right? >> >> >>Best Regards, >>Jade >> >> > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Mon May 19 08:28:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18934 for ; Mon, 19 May 2003 08:28:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JBvto11342 for midcom-archive@odin.ietf.org; Mon, 19 May 2003 07:57:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JBtUB11238; Mon, 19 May 2003 07:55:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JBssB11187 for ; Mon, 19 May 2003 07:54:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18852 for ; Mon, 19 May 2003 08:25:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HjjX-00031j-00 for midcom@ietf.org; Mon, 19 May 2003 08:27:15 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19HjjW-00031g-00 for midcom@ietf.org; Mon, 19 May 2003 08:27:14 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h4JCS0VI040173 for ; Mon, 19 May 2003 14:28:01 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 047579CB39 for ; Mon, 19 May 2003 14:18:32 +0200 (CEST) Message-ID: <3EC8CD9D.6070900@ccrle.nec.de> Date: Mon, 19 May 2003 14:27:09 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: multipart/mixed; boundary="------------040408020007040400090602" Subject: [midcom] Changes in draft-ietf-midcom-semantics-02.txt 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. --------------040408020007040400090602 Content-Type: multipart/alternative; boundary="------------030908020806030401080406" --------------030908020806030401080406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, here is the list of changes in draft-ietf-midcom-semantics-02.txt: - IP wildcarding added in sectiom 2.3.5 - Security considerations - Middlebox capabilities moved from SE section to section 2.1.6 "Middlebox capabilties" - Added a 'mode' parameter to PRR transaction. This supports middleboxes that provide traditional-NAT and twice-NAT in the same device and can switch between them on a per rule base - Added a Policy List (PL) transaction. This transaction is similar to the GL transaction, but for policy rules. With PL an agent can explore easily the list of accessible policy rules. - Removed the 'encryption' parameter from the SE transaction, since this is doubled work. - Renamed the 'reply parameters (failure)' to 'failure reason' and moved components common to all failure replies into the transaction template in section 1.2. - Simplified the session statement machine, i.e. failures in - Some editoral text shaping Martin -------- Original Message -------- Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-02.txt Date: Fri, 16 May 2003 07:22:28 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: 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 : MIDCOM Protocol Semantics Author(s) : M. Stiemerling et al. Filename : draft-ietf-midcom-semantics-02.txt Pages : 58 Date : 2003-5-15 This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or - more probably - a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-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-semantics-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-semantics-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. --------------030908020806030401080406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

here is the list of changes in draft-ietf-midcom-semantics-02.txt:
- IP wildcarding added in sectiom 2.3.5
- Security considerations
- Middlebox capabilities moved from SE section to section 2.1.6 "Middlebox capabilties"
- Added a 'mode' parameter to PRR transaction. This supports middleboxes that provide traditional-NAT and twice-NAT in the same device and can switch between them on a per rule base
- Added a Policy List (PL) transaction. This transaction is similar to the GL transaction, but for policy rules. With PL an agent can explore easily the list of accessible policy rules.
- Removed the 'encryption' parameter from the SE transaction, since this is doubled work.
- Renamed the 'reply parameters (failure)' to 'failure reason' and moved components common to all failure replies into the transaction template in section 1.2.
- Simplified the session statement machine, i.e. failures in
- Some editoral text shaping

Martin

-------- Original Message --------
Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-02.txt
Date: Fri, 16 May 2003 07:22:28 -0400
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
To: IETF-Announce: ;
CC: 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		: MIDCOM Protocol Semantics
	Author(s)	: M. Stiemerling et al.
	Filename	: draft-ietf-midcom-semantics-02.txt
	Pages		: 58
	Date		: 2003-5-15
	
This memo specifies semantics for a Middlebox Communication (MIDCOM)
protocol to be used by MIDCOM agents for interacting with
middleboxes, such as firewalls and NATs.  The semantics discussion
does not include any specification of a concrete syntax or a
transport protocol.  However, a concrete protocol is expected to
implement the specified semantics or - more probably - a superset of
it.  The MIDCOM protocol semantics is derived from the MIDCOM
requirements, from the MIDCOM framework, and from working group
decisions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-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-semantics-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-semantics-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.
--------------030908020806030401080406-- --------------040408020007040400090602 Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-midcom-semantics-02.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-5-15150208.I-D@ietf.org> --------------040408020007040400090602-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon May 19 09:03:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19724 for ; Mon, 19 May 2003 09:03:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JCWZX13673 for midcom-archive@odin.ietf.org; Mon, 19 May 2003 08:32:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JCPEB13402; Mon, 19 May 2003 08:25:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JCOPB13352 for ; Mon, 19 May 2003 08:24:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19570 for ; Mon, 19 May 2003 08:54:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HkC7-0003DH-00 for midcom@ietf.org; Mon, 19 May 2003 08:56:47 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19HkC1-0003DE-00 for midcom@ietf.org; Mon, 19 May 2003 08:56:41 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h4JCvIVI042639 for ; Mon, 19 May 2003 14:57:18 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 7CC133A0E5 for ; Mon, 19 May 2003 14:47:49 +0200 (CEST) Message-ID: <3EC8D4AF.2010209@ccrle.nec.de> Date: Mon, 19 May 2003 14:57:19 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe 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] UPDATE: Changes in draft-ietf-midcom-semantics-02.txt 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, since some sentences haven't made it completely into the email: - Simplified the session statement machine, i.e. failed transaction do not result in the deletion of policy rule. The rule remains as is. - PID reusing. The policy ID assigned in the PRR transaction is re-used by the middlebox as the policy ID in the PER transaction response. Martin -------- Original Message -------- Subject: [midcom] Changes in draft-ietf-midcom-semantics-02.txt Date: Mon, 19 May 2003 14:27:09 +0200 From: Martin Stiemerling To: midcom@ietf.org Hi, here is the list of changes in draft-ietf-midcom-semantics-02.txt: - IP wildcarding added in sectiom 2.3.5 - Security considerations - Middlebox capabilities moved from SE section to section 2.1.6 "Middlebox capabilties" - Added a 'mode' parameter to PRR transaction. This supports middleboxes that provide traditional-NAT and twice-NAT in the same device and can switch between them on a per rule base - Added a Policy List (PL) transaction. This transaction is similar to the GL transaction, but for policy rules. With PL an agent can explore easily the list of accessible policy rules. - Removed the 'encryption' parameter from the SE transaction, since this is doubled work. - Renamed the 'reply parameters (failure)' to 'failure reason' and moved components common to all failure replies into the transaction template in section 1.2. - Simplified the session statement machine, i.e. failures in - Some editoral text shaping Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon May 19 09:25:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20224 for ; Mon, 19 May 2003 09:25:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JCs0115633 for midcom-archive@odin.ietf.org; Mon, 19 May 2003 08:54:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JCiXB15168; Mon, 19 May 2003 08:44:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JChYB15098 for ; Mon, 19 May 2003 08:43:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20030 for ; Mon, 19 May 2003 09:14:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HkUd-0003JO-00 for midcom@ietf.org; Mon, 19 May 2003 09:15:55 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19HkUX-0003Is-00 for midcom@ietf.org; Mon, 19 May 2003 09:15:49 -0400 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 h4JDFXBP004677 for ; Mon, 19 May 2003 06:15:33 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHJ80143; Mon, 19 May 2003 06:15:32 -0700 (PDT) Message-Id: <200305191315.AHJ80143@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 19 May 2003 09:15:31 -0400 Subject: [midcom] Wrapping up the semantics document 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: , I'd like to get the semantics document wrapped up and into WG last call within the next couple of weeks. If you look at section 8 in the new draft you'll see that there are only two open issues identified: 1) finish up security considerations, and 2) whether or not there should be specifiable resource limits for DOS resilience. We also need to make sure that there's WG agreement on what's in the rest of the document. Please take a look at the draft and raise any issues you find, and in particular if someone could volunteer to help out with the security section it would be very much appreciated. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue May 20 05:45:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04069 for ; Tue, 20 May 2003 05:45:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4K9Ej815817 for midcom-archive@odin.ietf.org; Tue, 20 May 2003 05:14:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K9DGB15755; Tue, 20 May 2003 05:13:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K9BRB15702 for ; Tue, 20 May 2003 05:11:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04013 for ; Tue, 20 May 2003 05:41:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19I3eV-0002xj-00 for midcom@ietf.org; Tue, 20 May 2003 05:43:23 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19I3eU-0002xX-00 for midcom@ietf.org; Tue, 20 May 2003 05:43:22 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h4K9i6VI084014 for ; Tue, 20 May 2003 11:44:06 +0200 (CEST) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 062D0A5D32 for ; Tue, 20 May 2003 11:34:28 +0200 (CEST) Date: Tue, 20 May 2003 11:45:58 +0200 From: Juergen Quittek To: midcom@ietf.org Message-ID: <8753116.1053431158@[10.1.1.128]> 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] multiple agents accessing the same policy rule 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 Dear all, After working again on the semantics for some days, I ran into a potential problem related to the point that multiple agents may access the same policy rule on a middlebox. An example scenario contains a 'regular' agent authorized to access just the policies rules created by itself and an 'administrator' agent authorized to access all policies created by any agent. Another exampe contains be a 'regular' agent and a 'fail-over' agent running stand-by until the regular one fails. In both scenarios (and several others) it is possible that at a time two or more agents have an open session with the middlebox and there is a set of policy rules that both may access. Let's now assume that an agent deletes a policy rule that is also accessible to another agent with an open session. The agent deleting the policy rule sends a request for deletion and gets a successful reply. What happens with the other agent? I think that according to requirement 2.1.5 (known and stable state) the middlebox must send an ARD (Asynchronous Rule Deletion) notification to the other agent in order to tell it that one of the policies it can access was terminated. IS THIS AGREED BY THE WORKING GROUP? Consequences would be that: 1. Everytime a policy rule is terminated, each agent with open sessions that can access this policy need to receive an individual notification about this event. 2. Not just termiation of policy rules, but also creation and modification need to be reported to all these agents. Besides our ARD notification we would have to add one or more notifications to the semantics covering at least policy rule creation and lifetime change. If we agree on this, here are suggestion for modifying the semantics: - Replace the Asynchronous Policy Rule Deletion (ARD) transaction (that so far just indicated policy rule termination) by a more general Asynchronous Policy Rule Lifetime Event (ALE) notification that notifies the agent about - policy rule lifetime changes initiatd by other agents, indicating the new remaining lifetime, - policy rule termination by other agents, indicating a new remaining lifetime of zero, - policy rule termination by the middlebox, indicating a new remaining lifetime of zero, - regular policy rule termination by lifetime expiration, indicating the remaining lifetime of zero, - Add a new Asynchronous Policy Rule Creation (APC) transaction that indicates the new policy with all its properties to all agents in open sessions that did not create the policy rule but that can access it. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon May 26 05:02:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06187 for ; Mon, 26 May 2003 05:02:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4Q92ZA20955 for midcom-archive@odin.ietf.org; Mon, 26 May 2003 05:02:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4Q91LB20909; Mon, 26 May 2003 05:01:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4Q8wXB20738 for ; Mon, 26 May 2003 04:58:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06125 for ; Mon, 26 May 2003 04:58:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KDmU-0004eh-00 for midcom@ietf.org; Mon, 26 May 2003 04:56:34 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with smtp (Exim 4.12) id 19KDmT-0004ed-00 for midcom@ietf.org; Mon, 26 May 2003 04:56:34 -0400 Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail2 with InterScan Messaging Security Suite; Mon, 26 May 2003 11:03:28 +0200 Received: from lanmhs10.rd.francetelecom.fr ([10.193.21.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 26 May 2003 10:57:07 +0200 Received: from CSIRPMASTAG ([10.193.193.242]) by lanmhs10.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.5329); Mon, 26 May 2003 10:57:06 +0200 Message-ID: <006401c32364$c8749090$f2c1c10a@rd.francetelecom.fr> From: "Ines Feki" To: "Jonathan Rosenberg" , References: <200303210052.h2L0q0Z20787@gamma.isi.edu> <3E7B7FFD.4070204@dynamicsoft.com> Date: Mon, 26 May 2003 10:57:05 +0200 Organization: France Telecom R&D MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01C32375.8BA4B940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 26 May 2003 08:57:06.0726 (UTC) FILETIME=[C8B12460:01C32364] Subject: [midcom] On STUN Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C32375.8BA4B940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have some questions about STUN : I would like to know why and how STUN does not adress outgoing = communications as mentionned in the Section 14.1 of the RFC. Once the client knows its public adress returned by the STUN Server, can = it use it to send UDP communications ? Am I right or wrong ? Can somebody explain me=20 Many thanks and Best regards, _______________________________________________________________________ Ines Feki Trainee = Phone : Office +33 (0) 2 31 75 91 86=20 France Telecom R&D =20 42, Rue des Coutures =20 14066 Caen FRANCE =20 www.francetelecom.com _______________________________________________________________________ ------=_NextPart_000_0061_01C32375.8BA4B940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I have some questions about STUN = :
 
I would like to know why and how STUN = does not=20 adress outgoing communications as mentionned in the Section 14.1 of the=20 RFC.
 
Once the client knows its = public adress=20 returned by the STUN Server, can it use it to send UDP communications=20 ?
Am I right or wrong ?
 
Can somebody explain me
Many thanks and
Best regards,
 
 
 
________________________________________________________________= _______
Ines=20 Feki
 
Trainee         &nb= sp;           &nbs= p;       =20             =    =20             =    =20     Phone : Office +33 (0) 2 31 75 91 86
France = Telecom=20 R&D           =          
42, Rue des Coutures   =
14066 Caen=20 FRANCE           &= nbsp; =20
www.francetelecom.com
______= _________________________________________________________________<= /DIV> ------=_NextPart_000_0061_01C32375.8BA4B940-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue May 27 05:16:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05476 for ; Tue, 27 May 2003 05:16:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4R9Fw700791 for midcom-archive@odin.ietf.org; Tue, 27 May 2003 05:15:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4R9EoB00720; Tue, 27 May 2003 05:14:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4R9DdB00671 for ; Tue, 27 May 2003 05:13:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05429 for ; Tue, 27 May 2003 05:13:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KaUc-0002Vt-00 for midcom@ietf.org; Tue, 27 May 2003 05:11:38 -0400 Received: from host217-45-197-114.in-addr.btopenworld.com ([217.45.197.114] helo=aegir.engineering.newport-networks.com) by ietf-mx with esmtp (Exim 4.12) id 19KaUb-0002Vk-00 for midcom@ietf.org; Tue, 27 May 2003 05:11:38 -0400 Received: from jholdsworth ([192.168.2.64]) (authenticated user holdswor@newport-networks.com) by aegir.engineering.newport-networks.com for midcom@ietf.org; Tue, 27 May 2003 10:12:38 +0100 Reply-To: From: "john Holdsworth" To: Date: Tue, 27 May 2003 10:12:37 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <20030526160001.18224.75941.Mailman@www1.ietf.org> Content-Transfer-Encoding: 7bit Subject: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg 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 only that was the only question about Stun!!. While a lot of soft and Hardphones do send and receive on the same port (both signalling and media streams (although different port numbers for signalling and media of course). Many sip phones do not. There are significant security benefits by having traffic source and sink on the same port, no to mention simpler network design. The RFC (3261) is wide open to interpretation on this issue. Some phones within the same SIP session use different transmit ports (e.g. when the SIP re try timeout occurs the phone transmits from a new port!), some use different ports for registration than for signalling etc etc. We have done some extensive testing of SIP phones and would be glad to share what we've found out. However its not documented in a form suitable for public distribution, and would be best shared face to face. The big issue for STUN is that it won't work with most (95%+?) of corporate NATs and firewalls which translate ports on a symmetric basis. That is if any of the source or destination details change a new NAT mapping is employed. This makes STUN useless. When the STUN server is sent the discovery message it reports a port on the public side of the NAT. Since the destination SIP client has a different address than the STUN server, the public side NAT port mapping changes when the media or signalling packet is sent to the actual Destination. We are producing a signalling and media proxy which avoids this issue by focussing all the traffic through it. This also provides a place to enforce quality, charge and perform legal intercept. Also if the phone transmits and receives media on the same port, we can avoid the need to alter the corporate NAT/Firewall at all and offer public service. This technique also offers enhanced security as well. We call this Automatic Channel Mapping. Please down load the "Solving the Firewall and NAT Traversal Issues for Multimedia over IP Services" White paper from our website (www.newport-networks.com), which contains a review of all the known Nat/Firewall traversal methods. Also please feel free to contact myself on +441291635830 or +44778606104 if I can help Regards JH -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of midcom-request@ietf.org Sent: 26 May 2003 17:00 To: midcom@ietf.org Subject: midcom digest, Vol 1 #688 - 1 msg Send midcom mailing list submissions to midcom@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/midcom or, via email, send a message with subject or body 'help' to midcom-request@ietf.org You can reach the person managing the list at midcom-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of midcom digest..." Today's Topics: 1. On STUN (Ines Feki) --__--__-- Message: 1 From: "Ines Feki" To: "Jonathan Rosenberg" , Date: Mon, 26 May 2003 10:57:05 +0200 Organization: France Telecom R&D Subject: [midcom] On STUN This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C32375.8BA4B940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have some questions about STUN : I would like to know why and how STUN does not adress outgoing = communications as mentionned in the Section 14.1 of the RFC. Once the client knows its public adress returned by the STUN Server, can = it use it to send UDP communications ? Am I right or wrong ? Can somebody explain me=20 Many thanks and Best regards, _______________________________________________________________________ Ines Feki Trainee = Phone : Office +33 (0) 2 31 75 91 86=20 France Telecom R&D =20 42, Rue des Coutures =20 14066 Caen FRANCE =20 www.francetelecom.com _______________________________________________________________________ ------=_NextPart_000_0061_01C32375.8BA4B940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I have some questions about STUN = :
 
I would like to know why and how STUN = does not=20 adress outgoing communications as mentionned in the Section 14.1 of the=20 RFC.
 
Once the client knows its = public adress=20 returned by the STUN Server, can it use it to send UDP communications=20 ?
Am I right or wrong ?
 
Can somebody explain me
Many thanks and
Best regards,
 
 
 
________________________________________________________________= _______
Ines=20 Feki
 
Trainee         &nb= sp;           &nbs= p;       =20             =    =20             =    =20     Phone : Office +33 (0) 2 31 75 91 86
France = Telecom=20 R&D           =          
42, Rue des Coutures   =
14066 Caen=20 FRANCE           &= nbsp; =20
www.francetelecom.com
______= _________________________________________________________________<= /DIV> ------=_NextPart_000_0061_01C32375.8BA4B940-- --__--__-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom End of midcom Digest _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue May 27 13:47:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21379 for ; Tue, 27 May 2003 13:47:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RHl4B06713 for midcom-archive@odin.ietf.org; Tue, 27 May 2003 13:47:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RHjlB06633; Tue, 27 May 2003 13:45:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RHitB06575 for ; Tue, 27 May 2003 13:44:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21112 for ; Tue, 27 May 2003 13:44:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KiTk-0006WJ-00 for midcom@ietf.org; Tue, 27 May 2003 13:43:16 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19KiTj-0006Vq-00 for midcom@ietf.org; Tue, 27 May 2003 13:43:15 -0400 Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4RHiNZE001478; Tue, 27 May 2003 13:44:24 -0400 (EDT) Message-ID: <3ED3A3EC.9020204@dynamicsoft.com> Date: Tue, 27 May 2003 13:44:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.holdsworth@newport-networks.com CC: midcom@ietf.org Subject: Re: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg References: In-Reply-To: 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 john Holdsworth wrote: > The RFC (3261) is wide open to interpretation on this issue. Some phones > within the same SIP session use different transmit ports (e.g. when the SIP > re try timeout occurs the phone transmits from a new port!), some use > different ports for registration than for signalling etc etc. We have done > some extensive testing of SIP phones and would be glad to share what we've > found out. However its not documented in a form suitable for public > distribution, and would be best shared face to face. This is an RTP/SDP issue, not a SIP issue per se. The specifications only mandate a destiantion port, not a source port. > > > The big issue for STUN is that it won't work with most (95%+?) of corporate > NATs and firewalls which translate ports on a symmetric basis. That is if > any of the source or destination details change a new NAT mapping is > employed. This makes STUN useless. The RFC is clear on this point. STUN does not help with these symmetric NATs. STUN can help discover that this NAT is present. Its main benefit is that when it does work, its very effective and very cheap for everyone involved. To cover all of the NAT cases, you will want to also use a protocol like TURN, which allows for a relay-type of box. The ICE protocol (http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-00.txt) talks about how STUN, TURN and other mechanisms all get used together to fall into the optimal solution for any particular network configuration. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Tue May 27 13:53:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21640 for ; Tue, 27 May 2003 13:53:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RHqCX06882 for midcom-archive@odin.ietf.org; Tue, 27 May 2003 13:52:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RHp3B06850; Tue, 27 May 2003 13:51:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RHoDB06830 for ; Tue, 27 May 2003 13:50:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21581 for ; Tue, 27 May 2003 13:50:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KiYs-0006eX-00 for midcom@ietf.org; Tue, 27 May 2003 13:48:34 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19KiYs-0006eO-00 for midcom@ietf.org; Tue, 27 May 2003 13:48:34 -0400 Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4RHnfZE001484; Tue, 27 May 2003 13:49:42 -0400 (EDT) Message-ID: <3ED3A52A.3000807@dynamicsoft.com> Date: Tue, 27 May 2003 13:49:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ines Feki CC: midcom@ietf.org References: <200303210052.h2L0q0Z20787@gamma.isi.edu> <3E7B7FFD.4070204@dynamicsoft.com> <006401c32364$c8749090$f2c1c10a@rd.francetelecom.fr> In-Reply-To: <006401c32364$c8749090$f2c1c10a@rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: On STUN 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 Ines Feki wrote: > Hello, > > I have some questions about STUN : > > I would like to know why and how STUN does not adress outgoing > communications as mentionned in the Section 14.1 of the RFC. STUN doesnt control NATs, so it can't guarantee any kind of behavior from them, in terms of sending addresses. See below though... > > Once the client knows its public adress returned by the STUN Server, can > it use it to send UDP communications ? > Am I right or wrong ? Yes, a client can send packets from the same socket it used to talk to the STUn server. Depending on the type of NAT, the packets on the public side of the NAT may have the same source IP/port as returned by STUN. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Tue May 27 20:30:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11293 for ; Tue, 27 May 2003 20:30:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4S0TwT04449 for midcom-archive@odin.ietf.org; Tue, 27 May 2003 20:29:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S0TVB04435; Tue, 27 May 2003 20:29:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S0SoB04409 for ; Tue, 27 May 2003 20:28:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11235 for ; Tue, 27 May 2003 20:28:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Komf-0003nY-00 for midcom@ietf.org; Tue, 27 May 2003 20:27:13 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 19Kome-0003nO-00 for midcom@ietf.org; Tue, 27 May 2003 20:27:12 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 27 May 2003 17:28:16 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 27 May 2003 17:28:16 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 27 May 2003 17:28:16 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 27 May 2003 17:28:15 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 27 May 2003 17:28:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg Date: Tue, 27 May 2003 17:28:14 -0700 Message-ID: Thread-Topic: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg Thread-Index: AcMkeENOYg+s9UHMTGOwwf9Mv2V3UgANx6Zg From: "Christian Huitema" To: "Jonathan Rosenberg" , Cc: X-OriginalArrivalTime: 28 May 2003 00:28:15.0311 (UTC) FILETIME=[07606DF0:01C324B0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4S0SoB04410 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > The RFC is clear on this point. STUN does not help with these > symmetric NATs. STUN can help discover that this NAT is present. Its > main benefit is that when it does work, its very effective and very > cheap for everyone involved. Another benefit is that STUN can find out that the call will not work, which can avoid some stupid "ring and silence" scenarios. Our experience is that solutions like STUN work well on most residential NATs. But then, more and more of these NATs are UPNP capable, which is also quite practical. As for the enterprises NAT, they could easily be made STUN friendly if the enterprise actually wanted to enable VoIP -- the "protected cone" NAT is reasonably secure, and the deployment would be much easier than trying to pile up layers upon layers of relays and gateways. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue May 27 21:07:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12635 for ; Tue, 27 May 2003 21:07:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4S17NY07657 for midcom-archive@odin.ietf.org; Tue, 27 May 2003 21:07:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S16FB06850; Tue, 27 May 2003 21:06:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S15nB06813 for ; Tue, 27 May 2003 21:05:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12574 for ; Tue, 27 May 2003 21:05:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KpMR-0004AT-00 for midcom@ietf.org; Tue, 27 May 2003 21:04:11 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19KpMQ-0004A1-00 for midcom@ietf.org; Tue, 27 May 2003 21:04:10 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h4S158N09885; Wed, 28 May 2003 01:05:08 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Tue, 27 May 2003 20:07:47 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257AAF@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'john.holdsworth@newport-networks.com'" , midcom@ietf.org Subject: RE: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg Date: Tue, 27 May 2003 20:05:09 -0500 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Please do not use this mailing list, or other IETF mailing lists, for marketing purposes, especially when hawking proprietary solutions as an alternative to IETF standards. Jon Peterson NeuStar, Inc. (Transport Area co-Director) > -----Original Message----- > From: john Holdsworth [mailto:john.holdsworth@newport-networks.com] > Sent: Tuesday, May 27, 2003 2:13 AM > To: midcom@ietf.org > Subject: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg > [snip] > > We are producing a signalling and media proxy which avoids this issue by > focussing all the traffic through it. This also provides a place to enforce > quality, charge and perform legal intercept. > > Also if the phone transmits and receives media on the same port, we can > avoid the need to alter the corporate NAT/Firewall at all and offer public > service. This technique also offers enhanced security as well. We call this > Automatic Channel Mapping. > > Please down load the "Solving the Firewall and NAT Traversal Issues for > Multimedia over IP Services" White paper from our website [snip] _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed May 28 10:05:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03924 for ; Wed, 28 May 2003 10:05:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SE59J05313 for midcom-archive@odin.ietf.org; Wed, 28 May 2003 10:05:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SE3pB05262; Wed, 28 May 2003 10:03:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SE2nB05224 for ; Wed, 28 May 2003 10:02:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03643 for ; Wed, 28 May 2003 10:02:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L1UL-0003Fs-00 for midcom@ietf.org; Wed, 28 May 2003 10:01:09 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19L1UK-0003Fh-00 for midcom@ietf.org; Wed, 28 May 2003 10:01:08 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h4SE2DVI076974 for ; Wed, 28 May 2003 16:02:13 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EEFBF7C0F0 for ; Wed, 28 May 2003 15:51:17 +0200 (CEST) Message-ID: <3ED4C0B5.1020509@ccrle.nec.de> Date: Wed, 28 May 2003 15:59:17 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 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] Semantics: List of open issues 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 is the list of open semantics issues: - Further elaborate section on security considerations. Some text was added in the latest version, about the use of security credentials and possible threats due to wildcarding. - Shall the agent be able to specify parameters for protection against denial of service attacks? Examples are - maximum total number of TCP connection setups allowed - maximum number of TCP connection setups per minute - maximum number of UDP packets per minute - maximum bit rate Generally a good idea, but this may be to much, since the application level gateway is sometimes not aware of these facts. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom