From daemon@optimus.ietf.org Wed May 1 05:46:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13487 for ; Wed, 1 May 2002 05:46:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12385 for midcom-archive@odin.ietf.org; Wed, 1 May 2002 05:46:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10135; Wed, 1 May 2002 05:41:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10075 for ; Wed, 1 May 2002 05:41:26 -0400 (EDT) Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13158 for ; Wed, 1 May 2002 05:41:18 -0400 (EDT) Received: from host213-122-73-79.in-addr.btopenworld.com ([213.122.73.79] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 172qbn-0001KG-00; Wed, 01 May 2002 10:41:12 +0100 Message-ID: <009401c1f0f4$826491c0$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: "Melinda Shore" , References: <004b01c1ef5e$60654b60$0200000a@tkw> <3CCED7A4.634E6006@dynamicsoft.com> Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Date: Wed, 1 May 2002 10:42:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Some of this debate might be academic now as I quite like Christian's proposal, but ... ----- Original Message ----- From: "Jonathan Rosenberg" > Sorry for my absence on this thread.... my email back log is enormous at > the moment... > > Pete Cordell wrote: > > > > I see the problem a bit like this... > > > > If I have a message written in Chinese on a bit of paper and I want to > > know > > what it says I have two options: > > > > 1) I can take it to the Chinese Embassy (in my case in London) and ask > > them > > to give me an official translation, and sign it to say its authentic. > > > > 2) I can ask a number of Chinese people locally to translate it. If I > > get > > consistent results then I can be fairly sure that that's what the > > message > > says. > > > > (2) is what I'm suggesting here (simultaneously send 3 or 4 packets to 3 > > or > > 4 different servers and compare their results). In my case it saves me > > from > > going all the way to London. > > It is most certainly NOT the same thing. Each stun request will have a > different source port in many cases (symmetric NAT) because you are > going to a different destination. Depending on the nat, it might even > have a different source IP address. This approach is no substitute for > real security, and in fact, is much worse, since it will lull people > into a false sense that it provides it, when it doesnt. > Since STUN is not particularly useful in the symmetric NAT case, I don't consider this a problem. > > > > (2) may also be even more reliable than (1) if the message happens to be > > in > > something like Iraqi and I go to the Iraqi embassy for a translation! > > With an authenticated server, you know who you are talking to. I suggest > you don't send STUN requests to the iraqi stun servers. That solves the > problem. With your approach, since you don't know who you are talking > to, you might talk to an iraqi server, which happily reports false > mapped addresses. Without a lot of effort I'm not sure that you know that the server isn't really run by the Iraqis. They could advertise themselves as quiki-mart stun servers inc, and appear totally genuine unless you did a full background check. It may only be months later that they start syphoning off information. If the STUN servers are provided by people like Yahoo and Google maybe people can trust them as not being an Iraqi front. Is that enough to trust them? Would I trust a server run by Microsoft for example? > Indeed, your approach introduces a dos attack. I can > run a server that always hands out incorrect mapped addresses. A client > sends a real server, and then to me, trying to validate the answer. I > report a false answer. The client can't tell which is right, so it ends > up dropping the call. Nice DOS attack. This is the problem that was bothering me also. But then I didn't claim it was a completely worked out solution. The whole of security is about threat and counter-threat, so the discovery of a particular type of attack is no reason to stop looking for improvements. If that were the case there would be no cryptography today. My premise is that if there is a chance of finding a solution that is an order of magnitude simpler to do than a cryptographic one, then it is worth spending a little time looking for it. > The best way to provide security is to map your problem to other known > problems, and then apply known secure solutions. This is a known > problem, with multiple known solutions (each with known limitations and > issues). I suggest we use one rather than try to cook up some heuristic > which will only sometimes work. It all depends on whether the known limitations are considered problems or not. From discussions raised recently I got the distinct impression that the limitations were a problem. From what I see we do seem to be cooking up other solutions on the fly with a little bit of this and a little bit of that. I have no problem with that, but don't tell me that one way is simply selecting a standard solution from a manual and the other involves inventing things. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Thu May 2 22:18:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22175 for ; Thu, 2 May 2002 22:18:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA23377 for midcom-archive@odin.ietf.org; Thu, 2 May 2002 22:18:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23133; Thu, 2 May 2002 22:09:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23100 for ; Thu, 2 May 2002 22:09:43 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22116; Thu, 2 May 2002 22:09:37 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.172]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g432AZLC012252; Thu, 2 May 2002 22:10:36 -0400 (EDT) Message-ID: <3CD1F145.DA0C7D06@dynamicsoft.com> Date: Thu, 02 May 2002 22:09:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sipping@ietf.org, midcom@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] new draft on session policies in SIP Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Folks, I've just submitted a new I-D on "Supporting Intermediary Session Policies in SIP" that I think will be of interest to both MIDCOM and SIPPING. Until this draft appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt The draft is aiming to solve the paradox we have found ourselves in around "firewall control proxies". The sip spec forbids proxies from modifying the SDP, yet to be a MIDCOM-capable proxy, it may need to do that. The draft proposes a general framework for allowing proxies to have a say in session policies of all sorts, such as insertion of media intermediaries, codec grooming, and so on, without violating the SIP architecture, and with full cooperation and consent of end systems. It then provides details on an instantiation of the framework to support media intermediaries. Comments and questions are welcome, as always. Finally, as required of me by IETF policies, I must inform the group that I believe that dynamicsoft may have IPR associated with this draft. Fortunately, its being made available under our "free if you don't bug us" policy, documented at http://www.ietf.org/ietf/IPR/DYNAMICSOFT-SIP-UNIFY.txt. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 3 10:39:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15674 for ; Fri, 3 May 2002 10:39:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10255 for midcom-archive@odin.ietf.org; Fri, 3 May 2002 10:39:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10144; Fri, 3 May 2002 10:37:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10115 for ; Fri, 3 May 2002 10:37:00 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15438 for ; Fri, 3 May 2002 10:36:55 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g43EaY507006 for ; Fri, 3 May 2002 09:36:34 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 09:36:31 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE3A97@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Fri, 3 May 2002 09:36:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F2AF.E96ABE50" Subject: [midcom] FW: FINAL Reminder: WG Comments Requested for Individual Protocol Evaluation Documents Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F2AF.E96ABE50 Content-Type: text/plain; charset="iso-8859-1" Hi all, I apologize, but it looks like my email server decided to drop this on Wednesday afternoon, thus we're about 15 hours away from the cutoff for comments on the individual protocol evaluation documents. They are not lengthy documents, so at least take the time to read one or 2 of your preferred (or least preferred where you're likely to have more comments) and provide some feedback. Mary. -----Original Message----- From: Barnes, Mary [NGC:B601:EXCH] Sent: Wednesday, May 01, 2002 4:07 PM To: 'midcom@ietf.org' Subject: FINAL Reminder: WG Comments Requested for Individual Protocol Evaluation Documents Hi, A FINAL reminder that our review process for the individual protocol evaluation documents ends in about 48 hours (Midnite Pacific time on Friday, May 3rd). This is your opportunity to influence the protocol evaluations such that we have as objective of an analysis as possible going into the amalgamated WG Protocol Evaluation document. There's been some very constructive comments from one person (thanks to Joel Halpern) on the drafts, with an updated version of the DIAMETER draft now available. I've summarized the links below: SNMP Prime: Juergen Quittek [quittek@ccrle.nec.de]: http://www.ietf.org/internet-drafts/draft-quittek-midcom-snmp-eval-00.txt DIAMETER Prime: Tom Taylor [taylor@nortelnetworks.com] http://www.ietf.org/internet-drafts/draft-taylor-midcom-diameter-eval-01.txt RSIP Prime: James Renkel [James_Renkel@3com.com] http://www.ietf.org/internet-drafts/draft-renkel-rsip-midcom-eval-00.txt MEGACO Prime: Sanjoy Sen [sanjoy@nortelnetworks.com] http://www.ietf.org/internet-drafts/draft-sct-midcom-megaco-01.txt COPS Prime: Kwok Ho Chan [khchan@NortelNetworks.com] http://www.ietf.org/internet-drafts/draft-aoun-midcom-cops-01.txt --------------------- The individual authors will have one week (until May 10th) to make updates to the drafts to incorporate the comments. Following this phase, my role as editor becomes central to the process (my motivation for wanting lots of feedback during the next 48 hours rather than during the last 48 hours for feedback on my initial amalgamated draft), with the following timeline: ----------------------------------------- May 10th-May 24th Editor's primary task is underway. Information from the specific protocol drafts is synthesized into a consistent format, with an objective comparison of the various proposals based upon the drafts May 24th 1st version of Protocol evaluation draft available. May 24th-June 7th Mailing list discussion of the draft. Discussion of amalgamated pros/cons of the various proposals Any other issues with the draft. June 7th Conclusion of mailing list discussion. June 14th Second version of draft available. June 14th-June 21st Mailing list discussion June 28th Draft ready for WGLC July 19th WGLC ends July 26th Updated draft based upon WGLC comments available Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 ------_=_NextPart_001_01C1F2AF.E96ABE50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: FINAL Reminder: WG Comments Requested for Individual = Protocol Evaluation Documents

Hi all,

I apologize, but it looks like my email server = decided to drop this on Wednesday afternoon, thus we're about 15 hours = away from the cutoff for comments on the individual protocol evaluation = documents.  They are not lengthy documents, so at least take the = time to read one or 2 of your preferred (or least preferred where = you're likely to have more comments) and provide some feedback.  =

Mary.

-----Original Message-----
From: Barnes, Mary [NGC:B601:EXCH]
Sent: Wednesday, May 01, 2002 4:07 PM
To: 'midcom@ietf.org'
Subject: FINAL Reminder: WG Comments Requested for = Individual Protocol
Evaluation Documents


Hi,

A FINAL reminder that our review process for the = individual protocol evaluation documents ends in about 48 hours = (Midnite Pacific time on Friday, May 3rd). This is your opportunity to = influence the protocol evaluations such that we have as objective of an = analysis as possible going into the amalgamated WG Protocol Evaluation = document.

There's been some very constructive comments from one = person (thanks to Joel Halpern) on the drafts, with an updated version = of the DIAMETER draft now available. I've summarized the links = below:

SNMP Prime: Juergen Quittek = [quittek@ccrle.nec.de]:
http://www.ietf.org/internet-drafts/draft-quittek-midc= om-snmp-eval-00.txt

DIAMETER Prime: Tom Taylor = [taylor@nortelnetworks.com]
http://www.ietf.org/internet-drafts/draft-taylor-midco= m-diameter-eval-01.txt

RSIP Prime: James Renkel = [James_Renkel@3com.com]
http://www.ietf.org/internet-drafts/draft-renkel-rsip-= midcom-eval-00.txt

MEGACO Prime: Sanjoy Sen [sanjoy@nortelnetworks.com] =
http://www.ietf.org/internet-drafts/draft-sct-midcom-m= egaco-01.txt

COPS Prime: Kwok Ho Chan = [khchan@NortelNetworks.com]
http://www.ietf.org/internet-drafts/draft-aoun-midcom-= cops-01.txt


---------------------

The individual authors will have one week (until May = 10th) to make updates to the drafts to incorporate the comments.

Following this phase, my role as editor becomes = central to the process (my motivation for wanting lots of feedback = during the next 48 hours rather than during the last 48 hours for = feedback on my initial amalgamated draft), with the following = timeline:

-----------------------------------------

May 10th-May 24th       = Editor's primary task is underway.
          &nb= sp;       Information from the specific = protocol drafts is
          &nb= sp;       synthesized into a consistent = format, with an objective
          &nb= sp;       comparison of the various = proposals based upon the drafts

May 24th        = 1st version of Protocol evaluation draft available.

May 24th-June 7th       = Mailing list discussion of the draft.
          &nb= sp;       Discussion of amalgamated = pros/cons of the various proposals
          &nb= sp;       Any other issues with the = draft.

June 7th        = Conclusion of mailing list discussion.

June 14th       Second = version of draft available.
 
June 14th-June 21st     Mailing = list discussion

June 28th       Draft = ready for WGLC

July 19th       WGLC = ends

July 26th       Updated = draft based upon WGLC comments available



Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806

------_=_NextPart_001_01C1F2AF.E96ABE50-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon May 6 07:33:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13282 for ; Mon, 6 May 2002 07:33:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA13476 for midcom-archive@odin.ietf.org; Mon, 6 May 2002 07:33:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12930; Mon, 6 May 2002 07:29:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12899 for ; Mon, 6 May 2002 07:29:43 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13162 for ; Mon, 6 May 2002 07:29:36 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id HAA02248 for ; Mon, 6 May 2002 07:29:02 -0400 (EDT) To: "'midcom@ietf.org'" Cc: Tom_Gray@Mitel.COM Date: Mon, 6 May 2002 07:29:01 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 05/06/2002 07:29:02 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] STUN -- Types of Attacks Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Would it be possible to generate a list of the attacks that are being dealt with in the STUN security work. In Minneapolis, mention was made of a theft attack in which the attacker would subvert the protocol to insert itself in the call path. In the discussions on the list there seems to be a subtext about a form of denial of service attack in which the attacker would supply random addresses. Are there any other types of attack being considered? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue May 7 03:45:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29554 for ; Tue, 7 May 2002 03:45:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA05057 for midcom-archive@odin.ietf.org; Tue, 7 May 2002 03:45:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05017; Tue, 7 May 2002 03:43:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04986 for ; Tue, 7 May 2002 03:43:13 -0400 (EDT) Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29538 for ; Tue, 7 May 2002 03:43:03 -0400 (EDT) Received: from [80.128.85.164] (helo=wydad) by smtp.web.de with smtp (WEB.DE(Exim) 4.53 #1) id 174zcJ-0006r8-00 for midcom@ietf.org; Tue, 07 May 2002 09:42:35 +0200 Message-ID: <001401c1f59a$62b23760$b010960a@wydad> From: "Issam Elhaddioui" To: Date: Tue, 7 May 2002 09:39:54 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C1F5AB.248F2C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [midcom] MIDCOM deficiencies!! Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C1F5AB.248F2C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I am a new member of this mailing list , and intersted in the MIDCOM = solution for the SIP/NAT problem.All the doc I red right now shows only = advantages of this concept,but are they some deficiencies of this = solution?????? Regards, ------=_NextPart_000_0011_01C1F5AB.248F2C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I am a new member of this mailing list = , and=20 intersted in the MIDCOM solution for the SIP/NAT problem.All the doc I = red right=20 now shows only advantages of this concept,but are they some deficiencies = of this=20 solution??????
 
Regards,
------=_NextPart_000_0011_01C1F5AB.248F2C20-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue May 7 05:58:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01176 for ; Tue, 7 May 2002 05:58:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA11288 for midcom-archive@odin.ietf.org; Tue, 7 May 2002 05:58:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11020; Tue, 7 May 2002 05:51:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10991 for ; Tue, 7 May 2002 05:51:15 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01118 for ; Tue, 7 May 2002 05:51:08 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g479nsd28983; Tue, 7 May 2002 11:49:54 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 10:50:15 +0100 Message-ID: From: "Cedric Aoun" To: "'Peterson, Jon'" , "'Christian Huitema'" , Jonathan Rosenberg , Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Tue, 7 May 2002 10:50:04 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I agree with Jon, we should decouple the acquisition of the shared secret from its usage in STUN.Since there are 2 methods for the acquisition of the shared secret it should be negotiated thru STUN. I think that Sanjoy proposed to use the STUN flags for that, but didn't see any comments on it. Cedric -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: 30 April 2002 22:11 To: 'Christian Huitema'; Jonathan Rosenberg; Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Actually, I think STUN has applicability beyond SIP - if STUN were SIP-specific, I wouldn't have raised any concerns about CMS (since personally I would like to encourage all SIP entities to support S/MIME). But STUN is really targeted at a whole class of UDP applications - that suggests to me right off the bat that mandating TCP for STUN might limit the potential applicability of the protocol. I hope, Christian, that your ambitions for this protocol are also larger than just SIP. As far as I can tell (since this question was raised), the main difference between Christian's proposal and mine is that Christian wants to mandate a particular way of acquiring the shared secret, a way that I find a little too expensive (still comparable to the original CMS mechanism, really). I have a hard time seeing why the acquisition of the shared secret is not a separable issue - though I agree there is a requirement that the acquisition itself be appropriately secure. I see no immediate incentive to mandate any single way of acquiring a secret. But aside from that, I haven't detected any opposition to the actual use of the shared secret in STUN. I think agreement on how exactly this shared secret will be used (i.e. one-way or mutual auth, etc) should be our first important work item in exploring this proposal. I think this question of how you learn of keys should be a subsequent work item. In fact, I suspect a proposal along Christian's lines would best be designed as a separate protocol unrelated to STUN. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, April 30, 2002 12:40 PM > To: Jonathan Rosenberg; Melinda Shore > Cc: midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > > However, I am still confused about whether this proposal (TLS to obtain > > shared secrets) solves the problems Jon raised. It does not eliminate > > the need for TCP, certs, or any of the other "heavy" stuff. If you allow > > for provisioned shared secrets rather than using TLS to obtain a > > short-lived one, it does solve his objection of the need for PKI under > > all conditions, although all servers would need to implement it for > > sure... > > The main advantage of the TLS proposal is that you can reuse well known > software components, and also that you perform a lesser number of public > key operations. In a SIP context, TLS is pretty much a "must implement" > anyhow, so I don't think it creates a particular burden to > the endpoint. > > > I don't know whether Jon really believes that he can go away with a UDP > only implementation of SIP, but if that is the case the security of STUN > should be the least of his concerns. SIP over UDP can be attacked in > dozen of creative ways, without even having to resort to fake STUN > messages. > > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue May 7 06:20:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01481 for ; Tue, 7 May 2002 06:20:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA12788 for midcom-archive@odin.ietf.org; Tue, 7 May 2002 06:21:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12631; Tue, 7 May 2002 06:18:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12600 for ; Tue, 7 May 2002 06:18:13 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01439 for ; Tue, 7 May 2002 06:18:06 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g47AHfd18763 for ; Tue, 7 May 2002 12:17:42 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 11:18:03 +0100 Message-ID: From: "Cedric Aoun" To: "'midcom ietf'" Date: Tue, 7 May 2002 11:17:55 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] IPSEC ESP UDP encapsulation Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org While catching on my emails, I haven't noticed on the security threads usage of IPSEC ESP UDP encapsulation. We might want to leave it flexible enough to multimedia hosts securing their multimedia applications with IPSEC ESP, to reuse their IPSEC ESP stack to secure the STUN protocol. I've been monitoring the IPSEC ESP UDP encapsulation in the IPSEC WG and it seems to be going to WGLC. In case we think this option is viable, we'll need 3 options to be negotiated: -No STUN security, in which IPSEC ESP UDP encapsulation could be used (or we could imagine people not doing anything about it if they feel that the security threats are N/A) -Use shared secrets -Use TLS to get the shared secret We could use as default the shared secret method. Any comments? Thanks Cedric _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue May 7 10:24:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09477 for ; Tue, 7 May 2002 10:24:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28890 for midcom-archive@odin.ietf.org; Tue, 7 May 2002 10:24:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28353; Tue, 7 May 2002 10:15:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28324 for ; Tue, 7 May 2002 10:15:58 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09116 for ; Tue, 7 May 2002 10:15:49 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g47EFQ8M023029; Tue, 7 May 2002 07:15:26 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADU23268; Tue, 7 May 2002 07:12:30 -0700 (PDT) Message-Id: <5.1.0.14.0.20020507101546.01317350@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 May 2002 10:19:56 -0400 To: "Cedric Aoun" From: Melinda Shore Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Cc: midcom@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:50 AM 5/7/02 +0100, Cedric Aoun wrote: >I agree with Jon, we should decouple the acquisition of the shared secret >from its usage in STUN.Since there are 2 methods for the acquisition of the >shared >secret it should be negotiated thru STUN. If you're going to negotiate security mechanisms you need to provide protection against negotiation-down attacks. It also seems to me that putting in more protocol mechanism, more bits on the wire, and more round trips in order to avoid putting in more protocol mechanism, more bits on the wire, and more round trips while making the protocol less secure is probably not a good tradeoff. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed May 8 13:22:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17095 for ; Wed, 8 May 2002 13:22:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16225 for midcom-archive@odin.ietf.org; Wed, 8 May 2002 13:22:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15858; Wed, 8 May 2002 13:14:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15827 for ; Wed, 8 May 2002 13:14:34 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16936 for ; Wed, 8 May 2002 13:14:25 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g48HDqH16893; Wed, 8 May 2002 13:13:52 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 12:13:46 -0500 Message-ID: <70565611B164D511957A001083FCDD56018702D5@va02.va.neustar.com> From: "Peterson, Jon" To: "'Melinda Shore'" , Cedric Aoun Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Wed, 8 May 2002 12:13:44 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I also have a hard time understanding the need to negotiate a security mechanism within STUN if we adopt this shared secret approach. Acquiring the shared secret dynamically rather than statically would not require any negotiation within STUN as far as I can tell. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, May 07, 2002 7:20 AM > To: Cedric Aoun > Cc: midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > At 10:50 AM 5/7/02 +0100, Cedric Aoun wrote: > >I agree with Jon, we should decouple the acquisition of the shared secret > >from its usage in STUN.Since there are 2 methods for the acquisition of the > >shared > >secret it should be negotiated thru STUN. > > If you're going to negotiate security mechanisms you need to > provide protection against negotiation-down attacks. It also > seems to me that putting in more protocol mechanism, more bits > on the wire, and more round trips in order to avoid putting > in more protocol mechanism, more bits on the wire, and more > round trips while making the protocol less secure is probably > not a good tradeoff. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed May 8 15:54:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21979 for ; Wed, 8 May 2002 15:54:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23874 for midcom-archive@odin.ietf.org; Wed, 8 May 2002 15:54:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23772; Wed, 8 May 2002 15:52:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23746 for ; Wed, 8 May 2002 15:52:55 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21941 for ; Wed, 8 May 2002 15:52:46 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g48Jq7j06077; Wed, 8 May 2002 14:52:11 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 14:52:23 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B06@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Peterson, Jon'" , "'Melinda Shore'" , "Cedric Aoun" Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Wed, 8 May 2002 14:52:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6C9.DABEA0B0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F6C9.DABEA0B0 Content-Type: text/plain; charset="iso-8859-1" So, are you suggesting that the client can tell at the time of STUN server discovery whether it has a pre-shared secret or not with the server ( service provider domain)? > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Wednesday, May 08, 2002 12:14 PM > To: 'Melinda Shore'; Aoun, Cedric [QPD:MA01:EXCH] > Cc: midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > I also have a hard time understanding the need to negotiate a security > mechanism within STUN if we adopt this shared secret > approach. Acquiring the > shared secret dynamically rather than statically would not require any > negotiation within STUN as far as I can tell. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Tuesday, May 07, 2002 7:20 AM > > To: Cedric Aoun > > Cc: midcom@ietf.org > > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > > > > At 10:50 AM 5/7/02 +0100, Cedric Aoun wrote: > > >I agree with Jon, we should decouple the acquisition of > the shared secret > > >from its usage in STUN.Since there are 2 methods for the > acquisition of > the > > >shared > > >secret it should be negotiated thru STUN. > > > > If you're going to negotiate security mechanisms you need to > > provide protection against negotiation-down attacks. It also > > seems to me that putting in more protocol mechanism, more bits > > on the wire, and more round trips in order to avoid putting > > in more protocol mechanism, more bits on the wire, and more > > round trips while making the protocol less secure is probably > > not a good tradeoff. > > > > 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 > ------_=_NextPart_001_01C1F6C9.DABEA0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

So, are you suggesting that the client can tell at = the time of STUN server discovery whether it has a pre-shared secret or = not with the server ( service provider domain)?

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
> Sent: Wednesday, May 08, 2002 12:14 PM
> To: 'Melinda Shore'; Aoun, Cedric = [QPD:MA01:EXCH]
> Cc: midcom@ietf.org
> Subject: RE: [midcom] WGLC - Alternatives for = 'securing' STUN
>
>
> I also have a hard time understanding the need = to negotiate a security
> mechanism within STUN if we adopt this shared = secret
> approach. Acquiring the
> shared secret dynamically rather than = statically would not require any
> negotiation within STUN as far as I can = tell.
>
> Jon Peterson
> NeuStar, Inc.
>
> > -----Original Message-----
> > From: Melinda Shore [mailto:mshore@cisco.com]
> > Sent: Tuesday, May 07, 2002 7:20 AM
> > To: Cedric Aoun
> > Cc: midcom@ietf.org
> > Subject: RE: [midcom] WGLC - Alternatives = for 'securing' STUN
> >
> >
> > At 10:50 AM 5/7/02 +0100, Cedric Aoun = wrote:
> > >I agree with Jon, we should decouple = the acquisition of
> the shared secret
> > >from its usage in STUN.Since there are = 2 methods for the
> acquisition of
> the
> > >shared
> > >secret it should be negotiated thru = STUN.
> >
> > If you're going to negotiate security = mechanisms you need to
> > provide protection against = negotiation-down attacks.  It also
> > seems to me that putting in more protocol = mechanism, more bits
> > on the wire, and more round trips in order = to avoid putting
> > in more protocol mechanism, more bits on = the wire, and more
> > round trips while making the protocol less = secure is probably
> > not a good tradeoff.
> >
> > 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
>

------_=_NextPart_001_01C1F6C9.DABEA0B0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed May 8 16:31:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23023 for ; Wed, 8 May 2002 16:31:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25891 for midcom-archive@odin.ietf.org; Wed, 8 May 2002 16:31:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25302; Wed, 8 May 2002 16:28:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25274 for ; Wed, 8 May 2002 16:28:19 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22939 for ; Wed, 8 May 2002 16:28:10 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g48KRmj23501; Wed, 8 May 2002 15:27:48 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 15:28:04 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B07@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , midcom@ietf.org Cc: "'Peterson, Jon'" Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Wed, 8 May 2002 15:28:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6CE.DA4C3D90" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F6CE.DA4C3D90 Content-Type: text/plain; charset="iso-8859-1" Do we've a rough consensus on moving forward with the shared security approach for STUN? Echoing Jon, let's keep the dynamic/static download of shared secret separate from STUN and figure out the syntax/semantics for the new STUN attributes - realm, client/server nonce, response etc - that might be needed. Talking offline with Allison at the SIP/SIPPING Interim meeting this week, she seemed to think that the shared secret approach was perfectly reasonable solution for STUN security What I heard was that - from the IAB point of view, they would want to discourage STUN clients go hunt out arbitrary STUN servers in the public Internet in the absence of widescale PKI deployment. Allison, please correct me if I mis-represent your views in any way. Thanks, Sanjoy > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Wednesday, May 08, 2002 12:14 PM > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > I also have a hard time understanding the need to negotiate a security > mechanism within STUN if we adopt this shared secret > approach. Acquiring the ------_=_NextPart_001_01C1F6CE.DA4C3D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

Do we've a rough consensus on moving forward with the = shared security approach for STUN? Echoing Jon, let's keep the = dynamic/static download of shared secret separate from STUN and figure = out the syntax/semantics for the new STUN attributes - realm, = client/server nonce, response etc - that might be needed.

Talking offline with Allison at the SIP/SIPPING = Interim meeting this week, she seemed to think that the shared secret = approach was perfectly reasonable solution for STUN security What I = heard was that  - from the IAB point of view, they would want to = discourage STUN clients go hunt out arbitrary STUN servers in the = public Internet in the absence of widescale PKI deployment. Allison, = please correct me if I mis-represent your views in any way.

Thanks,
Sanjoy

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
> Sent: Wednesday, May 08, 2002 12:14 PM

> Subject: RE: [midcom] WGLC - Alternatives for = 'securing' STUN
>
>
> I also have a hard time understanding the need = to negotiate a security
> mechanism within STUN if we adopt this shared = secret
> approach. Acquiring the

------_=_NextPart_001_01C1F6CE.DA4C3D90-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed May 8 16:50:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23506 for ; Wed, 8 May 2002 16:50:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26630 for midcom-archive@odin.ietf.org; Wed, 8 May 2002 16:50:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26540; Wed, 8 May 2002 16:47:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26511 for ; Wed, 8 May 2002 16:47:06 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23465 for ; Wed, 8 May 2002 16:46:56 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g48KkZYM011110; Wed, 8 May 2002 13:46:35 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADU69974; Wed, 8 May 2002 13:43:38 -0700 (PDT) Message-Id: <5.1.0.14.0.20020508164929.00acca30@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 08 May 2002 16:51:05 -0400 To: "Sanjoy Sen", midcom@ietf.org From: Melinda Shore Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187B07@zrc2c012.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 03:28 PM 5/8/02 -0500, Sanjoy Sen wrote: >Do we've a rough consensus on moving forward with the shared security approach for STUN? No (if what you mean by "shared security" is pre-provisioned symmetric keys). Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed May 8 17:37:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24433 for ; Wed, 8 May 2002 17:37:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA29552 for midcom-archive@odin.ietf.org; Wed, 8 May 2002 17:37:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29513; Wed, 8 May 2002 17:34:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29485 for ; Wed, 8 May 2002 17:34:51 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24419 for ; Wed, 8 May 2002 17:34:41 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g48LYMj14238; Wed, 8 May 2002 16:34:22 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 16:34:39 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B08@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Wed, 8 May 2002 16:34:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6D8.246963E0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F6D8.246963E0 Content-Type: text/plain; charset="iso-8859-1" I just meant "shared secret". Whether it is statically provisioned or dynamically generated/downloaded is, IMO, outside the scope of STUN. I would prefer not to use STUN to download a shared secret. What I meant was if we agree on the shared secret part and on a challenge/response mechanism to do authentication, then the relevant attributes/semantics need to be added to draft-ietf-midcom-stun-00.txt. This work can be progressed independent of the shared secret provisioning mechanism. Thanks, Sanjoy > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, May 08, 2002 3:51 PM > To: Sen, Sanjoy [NGC:B692:EXCH]; midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > At 03:28 PM 5/8/02 -0500, Sanjoy Sen wrote: > >Do we've a rough consensus on moving forward with the shared > security approach for STUN? > > No (if what you mean by "shared security" is pre-provisioned symmetric > keys). > > Melinda > > ------_=_NextPart_001_01C1F6D8.246963E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

I just meant "shared secret". Whether it is = statically provisioned or dynamically generated/downloaded is, IMO, = outside the scope of STUN. I would prefer not to use STUN to download a = shared secret.

What I meant was if we agree on the shared secret = part and on a challenge/response mechanism to do authentication, then = the relevant attributes/semantics need to be added to = draft-ietf-midcom-stun-00.txt. This work can be progressed independent = of the shared secret provisioning mechanism.

Thanks,
Sanjoy


> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, May 08, 2002 3:51 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]; = midcom@ietf.org
> Subject: RE: [midcom] WGLC - Alternatives for = 'securing' STUN
>
>
> At 03:28 PM 5/8/02 -0500, Sanjoy Sen = wrote:
> >Do we've a rough consensus on moving = forward with the shared
> security approach for STUN?
>
> No (if what you mean by "shared = security" is pre-provisioned symmetric
> keys).
>
> Melinda
>
>

------_=_NextPart_001_01C1F6D8.246963E0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed May 8 18:41:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25589 for ; Wed, 8 May 2002 18:41:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03469 for midcom-archive@odin.ietf.org; Wed, 8 May 2002 18:41:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03126; Wed, 8 May 2002 18:33:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03090 for ; Wed, 8 May 2002 18:33:31 -0400 (EDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25432 for ; Wed, 8 May 2002 18:33:22 -0400 (EDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 8 May 2002 15:32:59 -0700 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 08 May 2002 15:32:59 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 8 May 2002 15:32:59 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 8 May 2002 15:32:58 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 8 May 2002 15:32:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Wed, 8 May 2002 15:32:55 -0700 Message-ID: Thread-Topic: [midcom] WGLC - Alternatives for 'securing' STUN thread-index: AcH22n4au7PiJSjQTlK0Nx5419o+pAABZHkA From: "Christian Huitema" To: "Sanjoy Sen" , "Melinda Shore" , X-OriginalArrivalTime: 08 May 2002 22:32:56.0477 (UTC) FILETIME=[4CCE24D0:01C1F6E0] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6E0.4C5797EF" ------_=_NextPart_001_01C1F6E0.4C5797EF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that using a pre-existing shared secret in STUN is very unsafe. We must have a procedure within STUN to download a secret. Without a safe way to download the secret, then I would rather stick with the current text, i.e. CMS. =20 -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com]=20 Sent: Wednesday, May 08, 2002 2:35 PM To: 'Melinda Shore'; midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN =20 I just meant "shared secret". Whether it is statically provisioned or dynamically generated/downloaded is, IMO, outside the scope of STUN. I would prefer not to use STUN to download a shared secret.=20 What I meant was if we agree on the shared secret part and on a challenge/response mechanism to do authentication, then the relevant attributes/semantics need to be added to draft-ietf-midcom-stun-00.txt. This work can be progressed independent of the shared secret provisioning mechanism.=20 Thanks,=20 Sanjoy=20 =20 > -----Original Message-----=20 > From: Melinda Shore [mailto:mshore@cisco.com]=20 > Sent: Wednesday, May 08, 2002 3:51 PM=20 > To: Sen, Sanjoy [NGC:B692:EXCH]; midcom@ietf.org=20 > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN=20 >=20 >=20 > At 03:28 PM 5/8/02 -0500, Sanjoy Sen wrote:=20 > >Do we've a rough consensus on moving forward with the shared=20 > security approach for STUN?=20 >=20 > No (if what you mean by "shared security" is pre-provisioned symmetric > keys).=20 >=20 > Melinda=20 >=20 >=20 ------_=_NextPart_001_01C1F6E0.4C5797EF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

I believe that using a pre-existing = shared secret in STUN is very unsafe. We must have a procedure within STUN to = download a secret. Without a safe way to download the secret, then I would rather = stick with the current text, i.e. CMS.

 

-----Original Message-----
From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com]
Sent: Wednesday, May 08, = 2002 2:35 PM
To: 'Melinda Shore'; midcom@ietf.org
Subject: RE: [midcom] = WGLC - Alternatives for 'securing' STUN

 

I just meant "shared secret". Whether it is statically provisioned or dynamically generated/downloaded is, IMO, outside the scope of STUN. I = would prefer not to use STUN to download a shared secret.

What I meant was if we agree on the shared secret part and on a = challenge/response mechanism to do authentication, then the relevant attributes/semantics = need to be added to draft-ietf-midcom-stun-00.txt. This work can be progressed independent of the shared secret provisioning mechanism. =

Thanks,
Sanjoy =

 

> -----Original Message-----
> From: Melinda Shore = [mailto:mshore@cisco.com]
> Sent: Wednesday, = May 08, 2002 3:51 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]; midcom@ietf.org
> Subject: RE: = [midcom] WGLC - Alternatives for 'securing' STUN
>
>
> At 03:28 PM 5/8/02 = -0500, Sanjoy Sen wrote:
> >Do we've a = rough consensus on moving forward with the shared
> security approach = for STUN?
>
> No (if what you = mean by "shared security" is pre-provisioned symmetric =
> = keys).
>
> = Melinda
>
>

=00 ------_=_NextPart_001_01C1F6E0.4C5797EF-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 04:46:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14198 for ; Thu, 9 May 2002 04:46:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA10801 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 04:46:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10387; Thu, 9 May 2002 04:37:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10300 for ; Thu, 9 May 2002 04:37:49 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14052 for ; Thu, 9 May 2002 04:37:34 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g498amY10567; Thu, 9 May 2002 10:36:52 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 09:37:18 +0100 Message-ID: From: "Cedric Aoun" To: "'Peterson, Jon'" , "'Melinda Shore'" Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 9 May 2002 09:37:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F734.B3F1477E" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F734.B3F1477E Content-Type: text/plain; charset="iso-8859-1" Melinda, You have a valid point, that introducing negotiation mechanisms within STUN will introduce more threats to deal with. The decision on whether to use TLS or not could happen at other layers, i.e. the STUN client could know in other ways that it doesn't have any shared secret with a particular STUN server and therefore decides to use TLS to download the shared secret from it; if it doesn't support TLS nothing happens (that's life !). I think we need to look at the scenarios where STUN will/could be deployed (at least imagine them): -All network based free multimedia apps combined with instant messaging S/W(Yahoo IM, MSN, AOL ...), a pre-shared secret is defined by the user -Internet content sharing communities (Limewire, Kazaa, Bearshare, Morpheus ...), currently don't require STUN; they may in the future and nothing prevents that they create user profiles at some point and therefore a pre-shared secret will need to be configured to secure the access to the profile (same one to be used in the context of STUN security) -Enterprise apps, pre-shared secret will be used when enterprise owns the STUN server -Carrier managed services, service provider will provide the shared secret during service registration and web based application allows renewal of the shared secret Again since the acquisition of the shared secret is decoupled from its usage, nothing prevents TLS to be used in the above scenarios. Cedric -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: 08 May 2002 19:14 To: 'Melinda Shore'; Aoun, Cedric [QPD:MA01:EXCH] Cc: midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN I also have a hard time understanding the need to negotiate a security mechanism within STUN if we adopt this shared secret approach. Acquiring the shared secret dynamically rather than statically would not require any negotiation within STUN as far as I can tell. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, May 07, 2002 7:20 AM > To: Cedric Aoun > Cc: midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > At 10:50 AM 5/7/02 +0100, Cedric Aoun wrote: > >I agree with Jon, we should decouple the acquisition of the shared secret > >from its usage in STUN.Since there are 2 methods for the acquisition of the > >shared > >secret it should be negotiated thru STUN. > > If you're going to negotiate security mechanisms you need to > provide protection against negotiation-down attacks. It also > seems to me that putting in more protocol mechanism, more bits > on the wire, and more round trips in order to avoid putting > in more protocol mechanism, more bits on the wire, and more > round trips while making the protocol less secure is probably > not a good tradeoff. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1F734.B3F1477E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

Melinda,
You have a valid point, that introducing negotiation = mechanisms within STUN will introduce more threats to deal with.
The decision on whether to use TLS or not could = happen at other layers, i.e. the STUN client could know in other ways = that it doesn't have any shared secret with a particular STUN server = and therefore decides to use TLS to download the shared secret from it; = if it doesn't support TLS nothing happens (that's life !).

I think we need to look at the scenarios where STUN = will/could be deployed (at least imagine them):

-All network based free multimedia apps combined with = instant messaging S/W(Yahoo IM, MSN, AOL ...), a pre-shared secret is = defined by the user

-Internet content sharing communities (Limewire, = Kazaa, Bearshare, Morpheus ...), currently don't require STUN; they may = in the future and nothing prevents that they create user profiles at = some point and therefore a pre-shared secret will need to be configured = to secure the access to the profile (same one to be used in the context = of STUN security)

-Enterprise apps, pre-shared secret will be used when = enterprise owns the STUN server

-Carrier managed services, service provider will = provide the shared secret during service registration and web based = application allows renewal of the shared secret


Again since the acquisition of the shared secret is = decoupled from its usage, nothing prevents TLS to be used in the above = scenarios.

Cedric

-----Original Message-----
From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
Sent: 08 May 2002 19:14
To: 'Melinda Shore'; Aoun, Cedric = [QPD:MA01:EXCH]
Cc: midcom@ietf.org
Subject: RE: [midcom] WGLC - Alternatives for = 'securing' STUN


I also have a hard time understanding the need to = negotiate a security
mechanism within STUN if we adopt this shared secret = approach. Acquiring the
shared secret dynamically rather than statically = would not require any
negotiation within STUN as far as I can tell.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Tuesday, May 07, 2002 7:20 AM
> To: Cedric Aoun
> Cc: midcom@ietf.org
> Subject: RE: [midcom] WGLC - Alternatives for = 'securing' STUN
>
>
> At 10:50 AM 5/7/02 +0100, Cedric Aoun = wrote:
> >I agree with Jon, we should decouple the = acquisition of the shared secret
> >from its usage in STUN.Since there are 2 = methods for the acquisition of
the
> >shared
> >secret it should be negotiated thru STUN. =
>
> If you're going to negotiate security = mechanisms you need to
> provide protection against negotiation-down = attacks.  It also
> seems to me that putting in more protocol = mechanism, more bits
> on the wire, and more round trips in order to = avoid putting
> in more protocol mechanism, more bits on the = wire, and more
> round trips while making the protocol less = secure is probably
> not a good tradeoff.
>
> Melinda
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1F734.B3F1477E-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 05:18:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14538 for ; Thu, 9 May 2002 05:18:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12149 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 05:19:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11902; Thu, 9 May 2002 05:12:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11859 for ; Thu, 9 May 2002 05:11:13 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14448 for ; Thu, 9 May 2002 05:11:03 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g499AXY23450; Thu, 9 May 2002 11:10:34 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4999n303901; Thu, 9 May 2002 10:09:49 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 10:11:02 +0100 Message-ID: From: "Cedric Aoun" To: "'Christian Huitema'" , "Sanjoy Sen", Melinda Shore , midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 9 May 2002 10:10:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F739.69D40A28" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F739.69D40A28 Content-Type: text/plain; charset="iso-8859-1" why do we need the download of the shared secret to happen within the STUN protocol? The main thing is to have the shared secret but not how we get it (TLS, from a manual, human interaction, secured personalized content web pages ....). Cedric -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: 09 May 2002 00:33 To: Sen, Sanjoy [NGC:B692:EXCH]; Melinda Shore; midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN I believe that using a pre-existing shared secret in STUN is very unsafe. We must have a procedure within STUN to download a secret. Without a safe way to download the secret, then I would rather stick with the current text, i.e. CMS. -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Wednesday, May 08, 2002 2:35 PM To: 'Melinda Shore'; midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN I just meant "shared secret". Whether it is statically provisioned or dynamically generated/downloaded is, IMO, outside the scope of STUN. I would prefer not to use STUN to download a shared secret. What I meant was if we agree on the shared secret part and on a challenge/response mechanism to do authentication, then the relevant attributes/semantics need to be added to draft-ietf-midcom-stun-00.txt. This work can be progressed independent of the shared secret provisioning mechanism. Thanks, Sanjoy > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, May 08, 2002 3:51 PM > To: Sen, Sanjoy [NGC:B692:EXCH]; midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > At 03:28 PM 5/8/02 -0500, Sanjoy Sen wrote: > >Do we've a rough consensus on moving forward with the shared > security approach for STUN? > > No (if what you mean by "shared security" is pre-provisioned symmetric > keys). > > Melinda > > ------_=_NextPart_001_01C1F739.69D40A28 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

why do we need the download of the shared secret to = happen within the STUN protocol?
The main thing is to have the shared secret but not = how we get it (TLS, from a manual, human interaction, secured = personalized content web pages ....).

Cedric
-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
Sent: 09 May 2002 00:33
To: Sen, Sanjoy [NGC:B692:EXCH]; Melinda Shore; = midcom@ietf.org
Subject: RE: [midcom] WGLC - Alternatives for = 'securing' STUN


I believe that using a pre-existing shared secret in = STUN is very unsafe. We must have a procedure within STUN to download a = secret. Without a safe way to download the secret, then I would rather = stick with the current text, i.e. CMS.

 
-----Original Message-----
From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.c= om]
Sent: Wednesday, May 08, 2002 2:35 PM
To: 'Melinda Shore'; midcom@ietf.org
Subject: RE: [midcom] WGLC - Alternatives for = 'securing' STUN
 
I just meant "shared secret". Whether it = is statically provisioned or dynamically generated/downloaded is, IMO, = outside the scope of STUN. I would prefer not to use STUN to download a = shared secret.

What I meant was if we agree on the shared secret = part and on a challenge/response mechanism to do authentication, then = the relevant attributes/semantics need to be added to = draft-ietf-midcom-stun-00.txt. This work can be progressed independent = of the shared secret provisioning mechanism.

Thanks,
Sanjoy
 
> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, May 08, 2002 3:51 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]; = midcom@ietf.org
> Subject: RE: [midcom] WGLC - Alternatives for = 'securing' STUN
>
>
> At 03:28 PM 5/8/02 -0500, Sanjoy Sen wrote: =
> >Do we've a rough consensus on moving = forward with the shared
> security approach for STUN?
>
> No (if what you mean by "shared = security" is pre-provisioned symmetric
> keys).
>
> Melinda
>
>

------_=_NextPart_001_01C1F739.69D40A28-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 10:31:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23947 for ; Thu, 9 May 2002 10:31:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00316 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 10:31:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29725; Thu, 9 May 2002 10:27:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29685 for ; Thu, 9 May 2002 10:27:25 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23781 for ; Thu, 9 May 2002 10:27:15 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g49EQqxf027468; Thu, 9 May 2002 07:26:53 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADU92891; Thu, 9 May 2002 07:23:55 -0700 (PDT) Message-Id: <5.1.0.14.0.20020509102207.00a72cd0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 May 2002 10:31:20 -0400 To: "Sanjoy Sen", midcom@ietf.org From: Melinda Shore Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187B08@zrc2c012.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 04:34 PM 5/8/02 -0500, Sanjoy Sen wrote: >I just meant "shared secret". Whether it is statically provisioned or dynamically generated/downloaded is, IMO, outside the scope of STUN. I would prefer not to use STUN to download a shared secret. Here's the problem: you have the plaintext and you have the hash. In that context reusing keys is a very, very bad idea. We also should care about interoperable implementations. IETF protocols typically do try to specify how keying is to be performed. If security were easy the world would be a very different place, and if you all were putting as much effort into securing STUN as you are into avoiding securing STUN we'd end up with something pretty good. In the meantime, I feel very strongly that if we're going to knowingly create a security exposure it's our responsibility to try to protect the user against it (particularly when it's a high-value attack, like being able to eavesdrop on every telephone call someone makes). We can strike a balance between complexity and convenience, and I think the notion of reaching key agreement or even just a key download over a TLS-secured channel is something that's relatively easy to implement and provides reasonable key protection. We're still open to alternatives, but they have to provide a degree of security that isn't trivial to compromise. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 17:35:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10328 for ; Thu, 9 May 2002 17:35:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25938 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 17:35:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25788; Thu, 9 May 2002 17:32:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25759 for ; Thu, 9 May 2002 17:32:38 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10193 for ; Thu, 9 May 2002 17:32:28 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49LW3511821; Thu, 9 May 2002 16:32:03 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 16:32:22 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B0D@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Christian Huitema'" , Melinda Shore , midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 9 May 2002 16:32:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F7A0.FDC0BEE0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F7A0.FDC0BEE0 Content-Type: text/plain; charset="iso-8859-1" I still don't see how this prevents us from working on STUN extensions needed for the challenge/response mechanism with shared secret. What I'm asking is to create the placeholder in STUN to allow this mechanism - i.e., nonce, realm, response - all these attributes. This is orthogonal (in my mind) to how the secret is shared. Later on, if we agree (have a consensus) to add the 'secret download' capability in STUN, that would be one more STUN extension (probably another new attribute). -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Wednesday, May 08, 2002 5:33 PM To: Sen, Sanjoy [NGC:B692:EXCH]; Melinda Shore; midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN I believe that using a pre-existing shared secret in STUN is very unsafe. We must have a procedure within STUN to download a secret. Without a safe way to download the secret, then I would rather stick with the current text, i.e. CMS. -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Wednesday, May 08, 2002 2:35 PM To: 'Melinda Shore'; midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN I just meant "shared secret". Whether it is statically provisioned or dynamically generated/downloaded is, IMO, outside the scope of STUN. I would prefer not to use STUN to download a shared secret. What I meant was if we agree on the shared secret part and on a challenge/response mechanism to do authentication, then the relevant attributes/semantics need to be added to draft-ietf-midcom-stun-00.txt. This work can be progressed independent of the shared secret provisioning mechanism. Thanks, Sanjoy > -----Original Message----- > From: Melinda Shore [ mailto:mshore@cisco.com ] > Sent: Wednesday, May 08, 2002 3:51 PM > To: Sen, Sanjoy [NGC:B692:EXCH]; midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > At 03:28 PM 5/8/02 -0500, Sanjoy Sen wrote: > >Do we've a rough consensus on moving forward with the shared > security approach for STUN? > > No (if what you mean by "shared security" is pre-provisioned symmetric > keys). > > Melinda > > ------_=_NextPart_001_01C1F7A0.FDC0BEE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN
I=20 still don't see how this prevents us from working on STUN extensions = needed for=20 the challenge/response mechanism with shared secret. What I'm asking is = to=20 create the placeholder in STUN to allow this mechanism - i.e., nonce, = realm,=20 response - all these attributes. This is orthogonal (in my mind) to how = the=20 secret is shared. Later on, if we agree (have a consensus) to add the = 'secret=20 download' capability in STUN, that would be one more STUN = extension=20 (probably another new attribute).
-----Original Message-----
From: Christian Huitema = [mailto:huitema@windows.microsoft.com]
Sent: Wednesday, May = 08, 2002=20 5:33 PM
To: Sen, Sanjoy [NGC:B692:EXCH]; Melinda Shore;=20 midcom@ietf.org
Subject: RE: [midcom] WGLC - Alternatives = for=20 'securing' STUN

I believe = that using=20 a pre-existing shared secret in STUN is very unsafe. We must have a = procedure=20 within STUN to download a secret. Without a safe way to download the = secret,=20 then I would rather stick with the current text, i.e. = CMS.

 

-----Original=20 Message-----
From: = Sanjoy Sen=20 [mailto:sanjoy@nortelnetworks.com]
Sent: Wednesday, May 08, 2002 = 2:35=20 PM
To: 'Melinda = Shore';=20 midcom@ietf.org
Subject: RE:=20 [midcom] WGLC - Alternatives for 'securing' STUN

 

I just=20 meant "shared secret". Whether it is statically provisioned or = dynamically=20 generated/downloaded is, IMO, outside the scope of STUN. I would = prefer not to=20 use STUN to download a shared secret.

What I=20 meant was if we agree on the shared secret part and on a = challenge/response=20 mechanism to do authentication, then the relevant = attributes/semantics need to=20 be added to draft-ietf-midcom-stun-00.txt. This work can be = progressed=20 independent of the shared secret provisioning mechanism. =

Thanks,
Sanjoy

 

>=20 -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]=20
> Sent: = Wednesday, May 08,=20 2002 3:51 PM
>=20 To: Sen, Sanjoy [NGC:B692:EXCH]; midcom@ietf.org =
> Subject: RE: [midcom] = WGLC -=20 Alternatives for 'securing' STUN
>
>
> At 03:28 PM 5/8/02 -0500, Sanjoy Sen=20 wrote:
>=20 >Do we've a rough consensus on moving forward with the shared=20
> = security=20 approach for STUN?
>
> No (if what you mean by "shared = security" is=20 pre-provisioned symmetric
> keys).
>
> Melinda
>
>=20

------_=_NextPart_001_01C1F7A0.FDC0BEE0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 17:46:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10798 for ; Thu, 9 May 2002 17:46:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26472 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 17:47:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26406; Thu, 9 May 2002 17:45:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26378 for ; Thu, 9 May 2002 17:45:01 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10724 for ; Thu, 9 May 2002 17:44:45 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49LiM513491; Thu, 9 May 2002 16:44:23 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 16:44:42 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B0E@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 9 May 2002 16:44:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F7A2.BAA08850" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F7A2.BAA08850 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, May 09, 2002 9:31 AM > > > At 04:34 PM 5/8/02 -0500, Sanjoy Sen wrote: > >I just meant "shared secret". Whether it is statically > provisioned or dynamically generated/downloaded is, IMO, > outside the scope of STUN. I would prefer not to use STUN to > download a shared secret. > > Here's the problem: you have the plaintext and you have the hash. > In that context reusing keys is a very, very bad idea. Can you articulate what are the possible threats that you see? You gave an example threat of 'known plaintext attack' in your message: http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02189.htm l which can be countered using both client side and server side (sufficiently-randomly-generated) nonces as described by Jonathan's message flow in the message: http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02200.htm l and as also discussed in RFC 2617 Section 4.9. So what're the other threats? Thanks, Sanjoy ------_=_NextPart_001_01C1F7A2.BAA08850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Thursday, May 09, 2002 9:31 AM
>
>
> At 04:34 PM 5/8/02 -0500, Sanjoy Sen = wrote:
> >I just meant "shared secret". = Whether it is statically
> provisioned or dynamically generated/downloaded = is, IMO,
> outside the scope of STUN. I would prefer not = to use STUN to
> download a shared secret.
>
> Here's the problem:  you have the = plaintext and you have the hash.
> In that context reusing keys is a very, very = bad idea. 

Can you articulate what are the possible threats that = you see? You gave an example threat of 'known plaintext attack' in your = message:

http://www1.ietf.org/mail-archive/working-groups/midco= m/current/msg02189.html

which can be countered using both client side and = server side (sufficiently-randomly-generated) nonces as described by = Jonathan's message flow in the message:

http://www1.ietf.org/mail-archive/working-groups/midco= m/current/msg02200.html
and as also discussed in RFC 2617 Section = 4.9.

So what're the other threats?

Thanks,
Sanjoy



------_=_NextPart_001_01C1F7A2.BAA08850-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 17:58:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11321 for ; Thu, 9 May 2002 17:58:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26950 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 17:58:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26911; Thu, 9 May 2002 17:56:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26882 for ; Thu, 9 May 2002 17:56:38 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11261 for ; Thu, 9 May 2002 17:56:28 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g49Lu1uF015938; Thu, 9 May 2002 14:56:01 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADV09527; Thu, 9 May 2002 14:53:10 -0700 (PDT) Message-Id: <5.1.0.14.0.20020509175349.00a74150@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 May 2002 18:00:33 -0400 To: "Sanjoy Sen", midcom@ietf.org From: Melinda Shore Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187B0E@zrc2c012.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 04:44 PM 5/9/02 -0500, Sanjoy Sen wrote: >which can be countered using both client side and server side (sufficiently-randomly-generated) nonces as described by Jonathan's message flow in the message: I'm still not clear on why you'd want to send down a nonce but not a password, and why you want to do a handshake in STUN but not in a password-sharing mechanism. If you've got a good key HTTP digest is overkill and if you've got a crappy key no mechanism is good enough. Melinda -- Melinda Shore Strategic Cryptographic Development Cisco Systems mshore@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 18:22:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12036 for ; Thu, 9 May 2002 18:22:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28784 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 18:23:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28731; Thu, 9 May 2002 18:21:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28703 for ; Thu, 9 May 2002 18:21:03 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12003 for ; Thu, 9 May 2002 18:20:52 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49MKW525587; Thu, 9 May 2002 17:20:32 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 17:20:52 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B0F@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 9 May 2002 17:20:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F7A7.C66D8570" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F7A7.C66D8570 Content-Type: text/plain; charset="iso-8859-1" Because, we want to avoid the TLS handshake that would add more roundtrips, avoid the DH or RSA key exchange and avoid any Certificate download. Actually, if I use TLS (or in the same matter IPSec tunnel, as Cedric has proposed), then I would create the secure transport/tunnel and send all STUN messages using that. That's surely an overkill, but an option. Sanjoy > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, May 09, 2002 5:01 PM > To: Sen, Sanjoy [NGC:B692:EXCH]; midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > At 04:44 PM 5/9/02 -0500, Sanjoy Sen wrote: > >which can be countered using both client side and server > side (sufficiently-randomly-generated) nonces as described by > Jonathan's message flow in the message: > > I'm still not clear on why you'd want to send down a nonce but > not a password, and why you want to do a handshake in STUN but > not in a password-sharing mechanism. If you've got a good key HTTP > digest is overkill and if you've got a crappy key no mechanism is > good enough. > > Melinda > -- > Melinda Shore > Strategic Cryptographic Development > Cisco Systems > mshore@cisco.com > > ------_=_NextPart_001_01C1F7A7.C66D8570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

Because, we want to avoid the TLS handshake that = would add more roundtrips, avoid the DH or RSA key exchange and avoid = any Certificate download.

Actually, if I use TLS (or in the same matter IPSec = tunnel, as Cedric has proposed), then I would create the secure = transport/tunnel and send all STUN messages using that.  That's = surely an overkill, but an option.

Sanjoy

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Thursday, May 09, 2002 5:01 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]; = midcom@ietf.org
> Subject: RE: [midcom] WGLC - Alternatives for = 'securing' STUN
>
>
> At 04:44 PM 5/9/02 -0500, Sanjoy Sen = wrote:
> >which can be countered using both client = side and server
> side (sufficiently-randomly-generated) nonces = as described by
> Jonathan's message flow in the message:
>
> I'm still not clear on why you'd want to send = down a nonce but
> not a password, and why you want to do a = handshake in STUN but
> not in a password-sharing mechanism.  If = you've got a good key HTTP
> digest is overkill and if you've got a crappy = key no mechanism is
> good enough.
>
> Melinda
> --
> Melinda Shore
> Strategic Cryptographic Development
> Cisco Systems
> mshore@cisco.com
>
>

------_=_NextPart_001_01C1F7A7.C66D8570-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 18:36:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12292 for ; Thu, 9 May 2002 18:36:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29637 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 18:36:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29602; Thu, 9 May 2002 18:35:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29571 for ; Thu, 9 May 2002 18:35:12 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12277 for ; Thu, 9 May 2002 18:35:01 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g49MYDHT004055; Thu, 9 May 2002 15:34:14 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADV10911; Thu, 9 May 2002 15:31:17 -0700 (PDT) Message-Id: <5.1.0.14.0.20020509183133.00a85690@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 May 2002 18:38:38 -0400 To: "Sanjoy Sen", midcom@ietf.org From: Melinda Shore Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187B0F@zrc2c012.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 05:20 PM 5/9/02 -0500, Sanjoy Sen wrote: >Because, we want to avoid the TLS handshake that would add more roundtrips, avoid the DH or RSA key exchange and avoid any Certificate download. You're still assuming pre-provisioned symmetric keys. That's not a reasonable assumption. >Actually, if I use TLS (or in the same matter IPSec tunnel, as Cedric has proposed), then I would create the secure transport/tunnel and send all STUN messages using that. That's surely an overkill, but an option. You can't use TLS for this. Also, with regard to IPSec, 1) ESP NULL does no source authentication, and 2) it brings us back to the keying problem - how would you key SAs between a STUN server and an unaffiliated client absent a PKI? Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 19:23:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13584 for ; Thu, 9 May 2002 19:23:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01283 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 19:24:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01255; Thu, 9 May 2002 19:22:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01227 for ; Thu, 9 May 2002 19:22:48 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13538 for ; Thu, 9 May 2002 19:22:38 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49NMF505230; Thu, 9 May 2002 18:22:16 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 18:22:36 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B11@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 9 May 2002 18:22:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F7B0.67BABA80" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F7B0.67BABA80 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, May 09, 2002 5:39 PM > > > At 05:20 PM 5/9/02 -0500, Sanjoy Sen wrote: > >Because, we want to avoid the TLS handshake that would add > more roundtrips, avoid the DH or RSA key exchange and avoid > any Certificate download. > > You're still assuming pre-provisioned symmetric keys. That's > not a reasonable assumption. > I don't understand. The exchanges required as described above are unavoidable if you use TLS. The TLS handshake protocol itself comprises of at least 8 messages exchanged (& depending on situations, it can be more) - clientHello, serverHello, serverHelloDone, clientKeyExchange (RSA or DH), clientChangeCipherSpec, clientFinished, serverChangeCipherSpec, serverFinished. ------_=_NextPart_001_01C1F7B0.67BABA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUN

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Thursday, May 09, 2002 5:39 PM

>
>
> At 05:20 PM 5/9/02 -0500, Sanjoy Sen = wrote:
> >Because, we want to avoid the TLS handshake = that would add
> more roundtrips, avoid the DH or RSA key = exchange and avoid
> any Certificate download.
>
> You're still assuming pre-provisioned symmetric = keys.  That's
> not a reasonable assumption.
>
I don't understand. The exchanges required as = described above are unavoidable if you use TLS. The TLS handshake = protocol itself comprises of at least 8 messages exchanged (& = depending on situations, it can be more) - clientHello, serverHello, = serverHelloDone, clientKeyExchange (RSA or DH), clientChangeCipherSpec, = clientFinished, serverChangeCipherSpec, serverFinished.

------_=_NextPart_001_01C1F7B0.67BABA80-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 20:02:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14996 for ; Thu, 9 May 2002 20:02:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA03195 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 20:03:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02678; Thu, 9 May 2002 19:59:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02649 for ; Thu, 9 May 2002 19:59:38 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14885 for ; Thu, 9 May 2002 19:59:28 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49Nx6507387; Thu, 9 May 2002 18:59:06 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 18:59:27 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B14@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 9 May 2002 18:59:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F7B5.8D5D5590" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F7B5.8D5D5590 Content-Type: text/plain; charset="iso-8859-1" And, you haven't yet told me what are the other threats to the STUN service that the Digest-ish 4-way handshake (w/ client, server nonce etc) cannot mitigate, for which you need TLS (w/ all its expensive bells and whistles)-based secret download. And, TLS is useless for UDP devices, which many, many IP phone vendors (including yourselves and ourselves) wouldn't presumably throw away in the time-span of pre-Midcom. And, Allison (and the IAB) doesn't want us to deploy STUN servers all over the public Internet & doesn't see any issue with the shared secret approach. And, finally, I don't see the reason for not being able to add the necessary STUN attributes and worry about the secret download later (or in parallel). So, what's the problem? -----Original Message----- From: Sen, Sanjoy [NGC:B692:EXCH] Sent: Thursday, May 09, 2002 6:23 PM To: 'Melinda Shore'; midcom@ietf.org Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > -----Original Message----- > From: Melinda Shore [ mailto:mshore@cisco.com ] > Sent: Thursday, May 09, 2002 5:39 PM > > > At 05:20 PM 5/9/02 -0500, Sanjoy Sen wrote: > >Because, we want to avoid the TLS handshake that would add > more roundtrips, avoid the DH or RSA key exchange and avoid > any Certificate download. > > You're still assuming pre-provisioned symmetric keys. That's > not a reasonable assumption. > I don't understand. The exchanges required as described above are unavoidable if you use TLS. The TLS handshake protocol itself comprises of at least 8 messages exchanged (& depending on situations, it can be more) - clientHello, serverHello, serverHelloDone, clientKeyExchange (RSA or DH), clientChangeCipherSpec, clientFinished, serverChangeCipherSpec, serverFinished. ------_=_NextPart_001_01C1F7B5.8D5D5590 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] WGLC - Alternatives for 'securing' STUN
 
And, you haven't yet told me what are the other threats to the STUN service that the Digest-ish 4-way handshake (w/ client, server nonce etc) cannot mitigate, for which you need TLS (w/ all its expensive bells and whistles)-based secret download.
 
And, TLS is useless for UDP devices, which many, many IP phone vendors (including yourselves and ourselves) wouldn't presumably throw away in the time-span of pre-Midcom.
 
And, Allison (and the IAB) doesn't want us to deploy STUN servers all over the public Internet & doesn't see any issue with the shared secret approach.
 
And, finally, I don't see the reason for not being able to add the necessary STUN attributes and worry about the secret download later (or in parallel).
 
So, what's the problem?
 
 
-----Original Message-----
From: Sen, Sanjoy [NGC:B692:EXCH]
Sent: Thursday, May 09, 2002 6:23 PM
To: 'Melinda Shore'; midcom@ietf.org
Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN


> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Thursday, May 09, 2002 5:39 PM

>
>
> At 05:20 PM 5/9/02 -0500, Sanjoy Sen wrote:
> >Because, we want to avoid the TLS handshake that would add
> more roundtrips, avoid the DH or RSA key exchange and avoid
> any Certificate download.
>
> You're still assuming pre-provisioned symmetric keys.  That's
> not a reasonable assumption.
>
I don't understand. The exchanges required as described above are unavoidable if you use TLS. The TLS handshake protocol itself comprises of at least 8 messages exchanged (& depending on situations, it can be more) - clientHello, serverHello, serverHelloDone, clientKeyExchange (RSA or DH), clientChangeCipherSpec, clientFinished, serverChangeCipherSpec, serverFinished.

------_=_NextPart_001_01C1F7B5.8D5D5590-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 20:32:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16230 for ; Thu, 9 May 2002 20:32:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04604 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 20:32:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04038; Thu, 9 May 2002 20:29:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03945 for ; Thu, 9 May 2002 20:29:19 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16114 for ; Thu, 9 May 2002 20:29:08 -0400 (EDT) Received: by shell.nominum.com (Postfix, from userid 11089) id EB1093190C; Thu, 9 May 2002 17:28:45 -0700 (PDT) Date: Thu, 9 May 2002 17:28:45 -0700 From: Ted Hardie To: Sanjoy Sen Cc: "'Melinda Shore'" , midcom@ietf.org Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Message-ID: <20020509172845.A12401@shell.nominum.com> Reply-To: Ted.Hardie@nominum.com References: <933FADF5E673D411B8A30002A5608A0E01187B14@zrc2c012.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187B14@zrc2c012.us.nortel.com>; from sanjoy@nortelnetworks.com on Thu, May 09, 2002 at 06:59:27PM -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, May 09, 2002 at 06:59:27PM -0500, Sanjoy Sen wrote: > And, Allison (and the IAB) doesn't want us to deploy STUN servers all over > the public Internet & doesn't see any issue with the shared secret approach. > I have not seen any discussion on the IAB list about STUN that discussed the shared secret approach. Note that I am not speaking for the IAB, but I do not personally see a reason why you would draw the conclusion of IAB consensus around "doesn't see any issue with the shared secret approach". The UNSAF document represents the last public document of IAB consensus and it does not mention that approach by name or (to my reading) implication. If Allison has made a statement about the shared secret approach, I also missed that in my reading of the mailing list and would be happy to have a pointer. regards, Ted Hardie _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 9 20:34:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16313 for ; Thu, 9 May 2002 20:34:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04656 for midcom-archive@odin.ietf.org; Thu, 9 May 2002 20:34:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04587; Thu, 9 May 2002 20:31:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04548 for ; Thu, 9 May 2002 20:31:33 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16199 for ; Thu, 9 May 2002 20:31:23 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 9 May 2002 17:31:01 -0700 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 May 2002 17:31:01 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 9 May 2002 17:31:01 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 May 2002 17:31:00 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Thu, 9 May 2002 17:32:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 9 May 2002 17:30:51 -0700 Message-ID: Thread-Topic: [midcom] WGLC - Alternatives for 'securing' STUN thread-index: AcH3t6ODgq3/ZyX1REicVL4amZXecQAARwWA From: "Christian Huitema" To: "Sanjoy Sen" , "Melinda Shore" , X-OriginalArrivalTime: 10 May 2002 00:32:44.0111 (UTC) FILETIME=[3361CDF0:01C1F7BA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA04549 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > And, TLS is useless for UDP devices, which many, many IP phone vendors > (including yourselves and ourselves) wouldn't presumably throw away in the > time-span of pre-Midcom. UDP only devices are basically unsafe, unless you use IPSEC, or strong encryption inside the UDP payload. In order to use strong encryption, you basically need to do some public key operation -- relying on a shared secret exposes you to dictionary attacks. So, if you want any kind of secure operation, you will need TLS equivalent or greater complexity. Indeed, if you accept to run an insecure UDP device, then all this discussion is moot -- you don't need to worry yourself with the attacks against the STUN servers.   > And, finally, I don't see the reason for not being able to add the > necessary STUN attributes and worry about the secret download later (or in > parallel). I don't think that the IETF should endorse an option that we know will lead to people exposing their passwords to third parties. Today, I only use my SIP password over a secure TLS connection to our server; using the same password within STUN would expose me to a dictionary attack, which instead of merely compromising a single phone call would compromise my entire account. This does not look very defendable. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 00:25:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26969 for ; Fri, 10 May 2002 00:25:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA13783 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 00:25:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA13539; Fri, 10 May 2002 00:18:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA13508 for ; Fri, 10 May 2002 00:18:10 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26630 for ; Fri, 10 May 2002 00:18:01 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4A4HXuH026047 for ; Thu, 9 May 2002 21:17:33 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACW56807; Thu, 9 May 2002 21:17:52 -0700 (PDT) From: "Cullen Jennings" To: Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN Date: Thu, 9 May 2002 21:17:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Christian Huitema > Sent: Thursday, May 09, 2002 5:31 PM > To: Sanjoy Sen; Melinda Shore; midcom@ietf.org > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN > > > > And, TLS is useless for UDP devices, which many, many IP phone vendors > > (including yourselves and ourselves) wouldn't presumably throw > away in the > > time-span of pre-Midcom. > > UDP only devices are basically unsafe, unless you use IPSEC, or > strong encryption inside the UDP payload. In order to use strong > encryption, you basically need to do some public key operation -- > relying on a shared secret exposes you to dictionary attacks. So, > if you want any kind of secure operation, you will need TLS > equivalent or greater complexity. > I think it is possible to have situations where this is not true, for example, one time password systems. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 07:31:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14676 for ; Fri, 10 May 2002 07:31:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA10807 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 07:31:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10343; Fri, 10 May 2002 07:29:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10314 for ; Fri, 10 May 2002 07:29:50 -0400 (EDT) Received: from carbon (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14609 for ; Fri, 10 May 2002 07:29:36 -0400 (EDT) Received: from host213-122-120-13.in-addr.btopenworld.com ([213.122.120.13] helo=tkw) by carbon with smtp (Exim 3.22 #8) id 1768Zo-0002zN-00; Fri, 10 May 2002 12:28:45 +0100 Message-ID: <000501c1f815$ea7dd000$0200000a@tkw> From: "Pete Cordell" To: "Cedric Aoun" , "'Christian Huitema'" , "Sanjoy Sen" , "Melinda Shore" , References: Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Date: Fri, 10 May 2002 10:04:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01C1F80A.0EB9BEE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0071_01C1F80A.0EB9BEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' STUNTo ease = implementation, would it be possible to wrap the server's public key in = an HTTP wrapper. That way the server's side of the operation could be = done by deploying Apache or IIS listening on the STUN port. The URL = could simply be /. This should be easy for most ISPs to deploy. On the client side, worst case the user can manually enter the STUN URL = (https://stun-servers.com:3478) into a standard web browser, read the = base64 encoded key that comes back (probably as text/plain?) and type it = into their client. Some standalone phones have HTTP configuration. = This would allow a copy and paste operation to be used. Best case would = of course be for the actual client to do the HTTP request. Such a strategy would seem to be easy to deploy, and shouldn't be too = difficult for the user to do. It also doesn't hinder slicker = implementations. Pete. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ----- Original Message -----=20 From: Cedric Aoun=20 To: 'Christian Huitema' ; Sanjoy Sen ; Melinda Shore ; midcom@ietf.org = Sent: 09 May 2002 10:10 Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN why do we need the download of the shared secret to happen within the = STUN protocol?=20 The main thing is to have the shared secret but not how we get it = (TLS, from a manual, human interaction, secured personalized content web = pages ....). Cedric=20 -----Original Message-----=20 From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20 Sent: 09 May 2002 00:33=20 To: Sen, Sanjoy [NGC:B692:EXCH]; Melinda Shore; midcom@ietf.org=20 Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN=20 I believe that using a pre-existing shared secret in STUN is very = unsafe. We must have a procedure within STUN to download a secret. = Without a safe way to download the secret, then I would rather stick = with the current text, i.e. CMS. =20 -----Original Message-----=20 From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com]=20 Sent: Wednesday, May 08, 2002 2:35 PM=20 To: 'Melinda Shore'; midcom@ietf.org=20 Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN=20 =20 I just meant "shared secret". Whether it is statically provisioned or = dynamically generated/downloaded is, IMO, outside the scope of STUN. I = would prefer not to use STUN to download a shared secret.=20 What I meant was if we agree on the shared secret part and on a = challenge/response mechanism to do authentication, then the relevant = attributes/semantics need to be added to draft-ietf-midcom-stun-00.txt. = This work can be progressed independent of the shared secret = provisioning mechanism.=20 Thanks,=20 Sanjoy=20 =20 > -----Original Message-----=20 > From: Melinda Shore [mailto:mshore@cisco.com]=20 > Sent: Wednesday, May 08, 2002 3:51 PM=20 > To: Sen, Sanjoy [NGC:B692:EXCH]; midcom@ietf.org=20 > Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN=20 >=20 >=20 > At 03:28 PM 5/8/02 -0500, Sanjoy Sen wrote:=20 > >Do we've a rough consensus on moving forward with the shared=20 > security approach for STUN?=20 >=20 > No (if what you mean by "shared security" is pre-provisioned = symmetric=20 > keys).=20 >=20 > Melinda=20 >=20 >=20 ------=_NextPart_000_0071_01C1F80A.0EB9BEE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] WGLC - Alternatives for 'securing' = STUN
To ease implementation, would it be possible to wrap = the=20 server's public key in an HTTP wrapper.  That way the server's side = of the=20 operation could be done by deploying Apache or IIS listening on the STUN = port.  The URL could simply be /.  This should be easy = for most=20 ISPs to deploy.
 
On the client side, worst case the user can manually = enter the=20 STUN URL (https://stun-servers.com:3478) into a standard web browser, read the base64 encoded = key that=20 comes back (probably as text/plain?) and type it into their = client. =20 Some standalone phones have HTTP configuration.  This would allow a = copy=20 and paste operation to be used.  Best case would of course be for = the=20 actual client to do the HTTP request.
 
Such a strategy would seem to be easy to = deploy, and=20 shouldn't be too difficult for the user to do.  It also doesn't = hinder=20 slicker implementations.

Pete.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pet= e=20 Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+4= 4 1473=20 635863
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= BR>
----- Original Message -----
From:=20 Cedric Aoun
To: 'Christian Huitema' = ; Sanjoy=20 Sen ; Melinda=20 Shore ; midcom@ietf.org
Sent: 09 May 2002 10:10
Subject: RE: [midcom] WGLC - = Alternatives=20 for 'securing' STUN

why do we need the download of the shared secret to = happen=20 within the STUN protocol?
The main thing is = to have=20 the shared secret but not how we get it (TLS, from a manual, human=20 interaction, secured personalized content web pages ....).

Cedric
-----Original=20 Message-----
From: Christian Huitema [mailto:huitema@windows.micr= osoft.com]=20
Sent: 09 May 2002 00:33
To: Sen,=20 Sanjoy [NGC:B692:EXCH]; Melinda Shore; midcom@ietf.org
Subject: RE: [midcom] WGLC - Alternatives for 'securing' = STUN=20


I believe that using a pre-existing shared secret in = STUN is=20 very unsafe. We must have a procedure within STUN to download a = secret.=20 Without a safe way to download the secret, then I would rather stick = with the=20 current text, i.e. CMS.


-----Original = Message-----=20
From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.co= m]=20
Sent: Wednesday, May 08, 2002 2:35 PM =
To: 'Melinda Shore'; midcom@ietf.org
Subject:=20 RE: [midcom] WGLC - Alternatives for 'securing' STUN
 
I just meant "shared = secret". Whether it=20 is statically provisioned or dynamically generated/downloaded is, IMO, = outside=20 the scope of STUN. I would prefer not to use STUN to download a shared = secret.=20

What I meant was if we agree on the shared secret = part and on=20 a challenge/response mechanism to do authentication, then the relevant = attributes/semantics need to be added to = draft-ietf-midcom-stun-00.txt. This=20 work can be progressed independent of the shared secret provisioning=20 mechanism.

Thanks,
Sanjoy =
 
> -----Original = Message-----=20
> From: Melinda Shore [mailto:mshore@cisco.com] =
> Sent: Wednesday, May 08, 2002 3:51 PM
>=20 To: Sen, Sanjoy [NGC:B692:EXCH]; midcom@ietf.org
>=20 Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN =
>
>
> At 03:28=20 PM 5/8/02 -0500, Sanjoy Sen wrote:
> = >Do we've a=20 rough consensus on moving forward with the shared
>=20 security approach for STUN?
> =
> No (if what you mean by "shared security" is = pre-provisioned=20 symmetric
> keys).
>=20
> Melinda
>=20
>

------=_NextPart_000_0071_01C1F80A.0EB9BEE0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 10:00:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23290 for ; Fri, 10 May 2002 10:00:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17767 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 10:00:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17428; Fri, 10 May 2002 09:54:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17399 for ; Fri, 10 May 2002 09:54:58 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22982 for ; Fri, 10 May 2002 09:54:43 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4ADsMHT009240; Fri, 10 May 2002 06:54:22 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADV26002; Fri, 10 May 2002 06:51:26 -0700 (PDT) Message-Id: <5.1.0.14.0.20020510095029.00aabec0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 May 2002 09:58:52 -0400 To: Ted.Hardie@nominum.com From: Melinda Shore Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN Cc: midcom@ietf.org In-Reply-To: <20020509172845.A12401@shell.nominum.com> References: <933FADF5E673D411B8A30002A5608A0E01187B14@zrc2c012.us.nortel.com> <933FADF5E673D411B8A30002A5608A0E01187B14@zrc2c012.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 05:28 PM 5/9/02 -0700, Ted Hardie wrote: >I have not seen any discussion on the IAB list about STUN that >discussed the shared secret approach. Note that I am not speaking for >the IAB, but I do not personally see a reason why you would draw the >conclusion of IAB consensus around "doesn't see any issue with the >shared secret approach". The UNSAF document represents the last >public document of IAB consensus and it does not mention that approach >by name or (to my reading) implication. If Allison has made a >statement about the shared secret approach, I also missed that in my >reading of the mailing list and would be happy to have a pointer. In conversation with me and, apparently, with Sanjoy Allison said that because STUN is to be a short-lived protocol (my other .sig is "Software longa hardware brevis") and because we don't want to encourage ubiquitous deployment we don't want to add features to it that would tend to do that. NOTE THAT I AM REPEATING MY UNDERSTANDING OF WHAT WAS SAID, NOT WHAT WAS ACTUALLY SAID. If Allison wants to weigh in on this that would be great, but I don't think that attempting to bolster an argument in favor of a poor security solution by paraphrasing what was said in a conversation none of us was privy to is a very good idea. In the meantime, we already know of one large vendor who is planning on a large STUN deployment and whose needs would not be met by pre-provisioned keys. That, I think, needs to be the acid test here, not a third-hand report of a casual conversation with an Area Director. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 11:16:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27921 for ; Fri, 10 May 2002 11:16:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22131 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 11:16:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21859; Fri, 10 May 2002 11:11:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21830 for ; Fri, 10 May 2002 11:11:04 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27658 for ; Fri, 10 May 2002 11:10:54 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g4AFAX818699 for ; Fri, 10 May 2002 17:10:33 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA26963 for ; Fri, 10 May 2002 17:08:13 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A70FC45217 for ; Fri, 10 May 2002 17:08:12 +0200 (CEST) Message-ID: <3CDBE25B.2050607@ccrle.nec.de> Date: Fri, 10 May 2002 17:08:11 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 Cc: midcom@ietf.org Subject: Re: [midcom] I-D ACTION:draft-aoun-midcom-cops-01.txt References: <200204231113.HAA11788@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hello, here are some comments to the cops-midcom comparison draft. Here the issues: a) Do you talk about COPS or COPS-PR? I assume COPS-PR. b) Section 5.3, "2.1.1" -COPS does not meet the directionality part of the requirement. COPS was defined to allow a PEP to establish communication with a PDP. However, nothing precludes a PDP to establish communication with a PEP. The PEP could have local policies dictating what action to take when it is contacted by an unknown PDP. These actions, defined in the local policies, would ensure the proper establishment of an authorized association. As far as I see, precludes the client/server principle of COPS* the PDP (server) to establish a connection to the PEP (client). Another pratical point: Imaging a middle box (the PEP), which has a lot of PDPs to serve. These PDPs don't have to be switched on all the time and so the middle box will be forced to poll whether a specific PDP is online or not. In my opinion the middle box must not poll any device. c) Section 5, "2.1.3" -The COPS framework specifies that a PEP should have a unique PDP, this was specified in order to achieve effective policy control. A single middlebox may have multiple instances of PEPs, with each instance of PEP communicating to a specific PDP. This can be used when applying COPS to a Midcom scenario. Nice solution to have multiple instances of PEPs, but doesn't the requirement say "The Midcom protocol must allow a middlebox to communicate with more than one Midcom agent simultaneously."? COPS does *NOT* allow this, so I would suggest to move this point to section 5.3. d) A minor point: The midcom framework document mentions in section 4, page 10, that "MIDCOM shall be a client-server protocol, initiated by the agent". In COPS* the initiator is the middlebox. However, it is only a "shall" requirement. Regards Martin Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : COPS applicability as the MIDCOM protocol > Author(s) : C. Aoun et al. > Filename : draft-aoun-midcom-cops-01.txt > Pages : 12 > Date : 22-Apr-02 > > This draft discusses the applicability of the COPS protocol as the > MIDCOM protocol, in the context of the current protocol evaluations > within the MIDCOM working group. > It discusses the architectural similarities between COPS and Midcom > and how COPS meets most of the MIDCOM protocol requirements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-aoun-midcom-cops-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-aoun-midcom-cops-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-aoun-midcom-cops-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- 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 daemon@optimus.ietf.org Fri May 10 12:03:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00965 for ; Fri, 10 May 2002 12:03:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26333 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 12:03:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25724; Fri, 10 May 2002 12:00:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25507 for ; Fri, 10 May 2002 12:00:27 -0400 (EDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00748 for ; Fri, 10 May 2002 12:00:15 -0400 (EDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 08:59:54 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 May 2002 08:59:54 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 08:59:53 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 08:59:53 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Fri, 10 May 2002 08:59:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 May 2002 08:59:53 -0700 Message-ID: Thread-Topic: STUN security showstopper thread-index: AcH4Kmx+1IYvRVIZRRK4p1A4vzwFAAADf8Bg From: "Christian Huitema" To: "Melinda Shore" , Cc: X-OriginalArrivalTime: 10 May 2002 15:59:53.0292 (UTC) FILETIME=[B8F530C0:01C1F83B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA25509 Subject: [midcom] STUN security showstopper Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit I am afraid I have found an attack that invalidates both the current CMS approach and the proposed protected hash approach. Let's first restate the threat we want to protect against: an attacker observes the STUN request, provides a fake response to the STUN client, and uses that fake response as a way to either deny service to the STUN user, or insert itself between the STUN user and its peer. The denial of service is achieved by providing a response that contains an entirely bogus address; the man-in-the-middle attack is achieved by providing the address of the attacker itself. The current proposals try to protect against that by letting the server sign the responses. The problem is that the server has no way to ensure that what it is signing is genuine. Suppose that the attacker, instead of merely responding to the request, simply forwards it to the server, giving the following flow: 1) Client prepares request, including signature request. 2) Attacker intercepts request, and somehow manages to prevent it from reaching the server. 3) Attacker replaces the source IP address and source UDP port of the request by one of its own addresses and port, and forwards the request to the server. 4) Server dutifully note the address from which the packet is received, prepare a response, signs it, and send it back to the incoming address, i.e. the attacker. 5) Attacker receives the response, takes note of the mapping, replaces the address and port by the original values in the intercepted message, and sends the response to the client. 6) Client receives the response, note that the signature is present and is actually correct, and uses the proposed mapping. The root cause of the problem is that we cannot sign the request. More precisely, we cannot include the source IP address and UDP port of the request in the fields covered by a signature. This pretty much by construct: we are trying to deal with NAT traversal, and what NAT do is precisely rewrite the source address and port to some value that the client cannot predict. An attacker who manages to intercept the message and change the source IP address and source port behaves in fact exactly like a NAT; no amount of cryptography and signatures will protect us against that. This makes be believe that cryptographic signatures are not practical defenses against the attack we fear most. If we look at the flow, a critical part is that the attacker has to somehow prevent the message from reaching the server, or prevent the genuine responses from reaching the client. If an attacker can do that, it can by definition mount a denial of attack against the STUN service; it can also place itself as a man in the middle, also pretty much by definition. If the attacker cannot do that, then the client will receive several responses to a STUN request, and will be able to detect that something fishy is going on. This may be the basis for a protection. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 12:14:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01732 for ; Fri, 10 May 2002 12:14:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26834 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 12:15:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26782; Fri, 10 May 2002 12:13:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26753 for ; Fri, 10 May 2002 12:13:17 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01627 for ; Fri, 10 May 2002 12:13:06 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id MAA11012; Fri, 10 May 2002 12:12:16 -0400 (EDT) Subject: Re: [midcom] STUN security showstopper To: "Christian Huitema" Cc: Date: Fri, 10 May 2002 12:12:15 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 05/10/2002 12:12:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org How would the atttacker guarantee that it could prevent the server from receiving the original message? "Christian Huitema" @ietf.org on 05/10/2002 11:59:53 AM Sent by: midcom-admin@ietf.org To: "Melinda Shore" , cc: Subject: [midcom] STUN security showstopper I am afraid I have found an attack that invalidates both the current CMS approach and the proposed protected hash approach. Let's first restate the threat we want to protect against: an attacker observes the STUN request, provides a fake response to the STUN client, and uses that fake response as a way to either deny service to the STUN user, or insert itself between the STUN user and its peer. The denial of service is achieved by providing a response that contains an entirely bogus address; the man-in-the-middle attack is achieved by providing the address of the attacker itself. The current proposals try to protect against that by letting the server sign the responses. The problem is that the server has no way to ensure that what it is signing is genuine. Suppose that the attacker, instead of merely responding to the request, simply forwards it to the server, giving the following flow: 1) Client prepares request, including signature request. 2) Attacker intercepts request, and somehow manages to prevent it from reaching the server. 3) Attacker replaces the source IP address and source UDP port of the request by one of its own addresses and port, and forwards the request to the server. 4) Server dutifully note the address from which the packet is received, prepare a response, signs it, and send it back to the incoming address, i.e. the attacker. 5) Attacker receives the response, takes note of the mapping, replaces the address and port by the original values in the intercepted message, and sends the response to the client. 6) Client receives the response, note that the signature is present and is actually correct, and uses the proposed mapping. The root cause of the problem is that we cannot sign the request. More precisely, we cannot include the source IP address and UDP port of the request in the fields covered by a signature. This pretty much by construct: we are trying to deal with NAT traversal, and what NAT do is precisely rewrite the source address and port to some value that the client cannot predict. An attacker who manages to intercept the message and change the source IP address and source port behaves in fact exactly like a NAT; no amount of cryptography and signatures will protect us against that. This makes be believe that cryptographic signatures are not practical defenses against the attack we fear most. If we look at the flow, a critical part is that the attacker has to somehow prevent the message from reaching the server, or prevent the genuine responses from reaching the client. If an attacker can do that, it can by definition mount a denial of attack against the STUN service; it can also place itself as a man in the middle, also pretty much by definition. If the attacker cannot do that, then the client will receive several responses to a STUN request, and will be able to detect that something fishy is going on. This may be the basis for a protection. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 12:27:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02549 for ; Fri, 10 May 2002 12:27:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27381 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 12:27:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27258; Fri, 10 May 2002 12:25:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27229 for ; Fri, 10 May 2002 12:25:37 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02445 for ; Fri, 10 May 2002 12:25:26 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 09:25:06 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 May 2002 09:25:06 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 09:25:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 09:25:06 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Fri, 10 May 2002 09:25:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 09:25:06 -0700 Message-ID: Thread-Topic: [midcom] STUN security showstopper thread-index: AcH4PXm2QjFJniBPR+2kOb7PNaWmfQAAa/GQ From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 10 May 2002 16:25:05.0639 (UTC) FILETIME=[3E630770:01C1F83F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA27230 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit A classic way is to mount a short duration DOS attack against the server. > -----Original Message----- > From: Tom_Gray@Mitel.COM [mailto:Tom_Gray@Mitel.COM] > Sent: Friday, May 10, 2002 9:12 AM > To: Christian Huitema > Cc: midcom@ietf.org > Subject: Re: [midcom] STUN security showstopper > > > > How would the atttacker guarantee that it could prevent the server from > receiving the original message? > > > > > > "Christian Huitema" @ietf.org on 05/10/2002 > 11:59:53 AM > > Sent by: midcom-admin@ietf.org > > > To: "Melinda Shore" , > cc: > Subject: [midcom] STUN security showstopper > > > I am afraid I have found an attack that invalidates both the current CMS > approach and the proposed protected hash approach. > > Let's first restate the threat we want to protect against: an attacker > observes the STUN request, provides a fake response to the STUN client, > and uses that fake response as a way to either deny service to the STUN > user, or insert itself between the STUN user and its peer. The denial of > service is achieved by providing a response that contains an entirely > bogus address; the man-in-the-middle attack is achieved by providing the > address of the attacker itself. The current proposals try to protect > against that by letting the server sign the responses. > > The problem is that the server has no way to ensure that what it is > signing is genuine. Suppose that the attacker, instead of merely > responding to the request, simply forwards it to the server, giving the > following flow: > > 1) Client prepares request, including signature request. > 2) Attacker intercepts request, and somehow manages to prevent it from > reaching the server. > 3) Attacker replaces the source IP address and source UDP port of the > request by one of its own addresses and port, and forwards the request > to the server. > 4) Server dutifully note the address from which the packet is received, > prepare a response, signs it, and send it back to the incoming address, > i.e. the attacker. > 5) Attacker receives the response, takes note of the mapping, replaces > the address and port by the original values in the intercepted message, > and sends the response to the client. > 6) Client receives the response, note that the signature is present and > is actually correct, and uses the proposed mapping. > > The root cause of the problem is that we cannot sign the request. More > precisely, we cannot include the source IP address and UDP port of the > request in the fields covered by a signature. This pretty much by > construct: we are trying to deal with NAT traversal, and what NAT do is > precisely rewrite the source address and port to some value that the > client cannot predict. An attacker who manages to intercept the message > and change the source IP address and source port behaves in fact exactly > like a NAT; no amount of cryptography and signatures will protect us > against that. > > This makes be believe that cryptographic signatures are not practical > defenses against the attack we fear most. If we look at the flow, a > critical part is that the attacker has to somehow prevent the message > from reaching the server, or prevent the genuine responses from reaching > the client. If an attacker can do that, it can by definition mount a > denial of attack against the STUN service; it can also place itself as a > man in the middle, also pretty much by definition. If the attacker > cannot do that, then the client will receive several responses to a STUN > request, and will be able to detect that something fishy is going on. > This may be the basis for a protection. > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 13:16:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05779 for ; Fri, 10 May 2002 13:16:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00503 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 13:16:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00383; Fri, 10 May 2002 13:12:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00355 for ; Fri, 10 May 2002 13:12:36 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05612 for ; Fri, 10 May 2002 13:12:24 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 2EB388107 for ; Fri, 10 May 2002 12:12:35 -0500 (CDT) Received: by isis.visi.com (Postfix, from userid 2286) id F0F8C76C27; Fri, 10 May 2002 12:12:34 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by isis.visi.com (Postfix) with ESMTP id ED70076C26 for ; Fri, 10 May 2002 12:12:34 -0500 (CDT) Date: Fri, 10 May 2002 12:12:34 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] STUN security showstopper In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 10 May 2002, Christian Huitema wrote: I'm a little sleepy yet, but.. > 1) Client prepares request, including signature request. > 2) Attacker intercepts request, and somehow manages to prevent it from > reaching the server. > 3) Attacker replaces the source IP address and source UDP port of the > request by one of its own addresses and port, and forwards the request > to the server. > 4) Server dutifully note the address from which the packet is received, > prepare a response, signs it, and send it back to the incoming address, > i.e. the attacker. > 5) Attacker receives the response, takes note of the mapping, replaces > the address and port by the original values in the intercepted message, > and sends the response to the client. Doesn't the server signature cover the address and port? Sure, they're not signed in the request, but surely the server signs the entire message it returns (including a length field and probably some other junk like a client supplied nonce). I confess I haven't been following STUN, but this seems basic it me. > 6) Client receives the response, note that the signature is present and > is actually correct, and uses the proposed mapping. Client notes that the signature is wrong and dumps the response, surely.. Of course, if you only get to step 2, you have implemented the DOS already. Preventing that sort of thing is surely outside the scope of MIDCOM, thankfully. Feel free to tell me why I'm stupid :) Andrew _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 13:33:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06825 for ; Fri, 10 May 2002 13:33:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01911 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 13:33:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01144; Fri, 10 May 2002 13:27:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01117 for ; Fri, 10 May 2002 13:27:58 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06482 for ; Fri, 10 May 2002 13:27:48 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 10:27:26 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 May 2002 10:27:26 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 10:27:25 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 10:27:26 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Fri, 10 May 2002 10:27:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 10:27:15 -0700 Message-ID: Thread-Topic: [midcom] STUN security showstopper thread-index: AcH4Ri8YUv+P0jObT0iFFKBomzcAbgAAUkMA From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 10 May 2002 17:27:18.0873 (UTC) FILETIME=[EF915490:01C1F847] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA01118 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > I'm a little sleepy yet, but.. > > > 1) Client prepares request, including signature request. > > 2) Attacker intercepts request, and somehow manages to prevent it from > > reaching the server. > > 3) Attacker replaces the source IP address and source UDP port of the > > request by one of its own addresses and port, and forwards the request > > to the server. > > 4) Server dutifully note the address from which the packet is received, > > prepare a response, signs it, and send it back to the incoming address, > > i.e. the attacker. > > 5) Attacker receives the response, takes note of the mapping, replaces > > the address and port by the original values in the intercepted message, > > and sends the response to the client. > > Doesn't the server signature cover the address and > port? Sure, they're not signed in the request, but surely the > server signs the entire message it returns (including a length > field and probably some other junk like a client supplied > nonce). I confess I haven't been following STUN, but this > seems basic it me. The server signs the payload of the UDP message. It cannot sign the content of the IP and UDP header, since that content will be modified by the NAT. > > 6) Client receives the response, note that the signature is present and > > is actually correct, and uses the proposed mapping. > > Client notes that the signature is wrong and dumps the > response, surely.. NOPE. The signature only applies to the UDP payload, and nobody touched that. > Of course, if you only get to step 2, you have implemented > the DOS already. Preventing that sort of thing is surely outside > the scope of MIDCOM, thankfully. Yes. In fact, in the "shared LAN" scenario that people talk about most, it is probably easier to mount a rogue-DHCP or a spoofed-ARP attack than the STUN attack. > Feel free to tell me why I'm stupid :) Let's say sleepy... -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 13:33:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06842 for ; Fri, 10 May 2002 13:33:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01925 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 13:33:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01100; Fri, 10 May 2002 13:27:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01074 for ; Fri, 10 May 2002 13:27:40 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06464 for ; Fri, 10 May 2002 13:27:30 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4AHR9HT007509; Fri, 10 May 2002 10:27:09 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADV32053; Fri, 10 May 2002 10:24:13 -0700 (PDT) Message-Id: <5.1.0.14.0.20020510132513.00a99090@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 May 2002 13:31:38 -0400 To: Andrew Molitor , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] STUN security showstopper In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:12 PM 5/10/02 -0500, Andrew Molitor wrote: > Doesn't the server signature cover the address and >port? Right, but the client doesn't know its external address - that's why it's using STUN - so has no way to know that it's receiving a response to a bogus request. It leaves us facing the prospect of protecting the client request, and all that implies. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 13:33:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06848 for ; Fri, 10 May 2002 13:33:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01939 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 13:33:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01218; Fri, 10 May 2002 13:29:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01190 for ; Fri, 10 May 2002 13:29:56 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06548 for ; Fri, 10 May 2002 13:29:47 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 10:29:21 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 May 2002 10:29:21 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 10:29:21 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 10:29:20 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Fri, 10 May 2002 10:29:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 10:29:17 -0700 Message-ID: Thread-Topic: [midcom] STUN security showstopper thread-index: AcH4Ri8YUv+P0jObT0iFFKBomzcAbgAAcvHA From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 10 May 2002 17:29:20.0129 (UTC) FILETIME=[37D78710:01C1F848] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA01191 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > Of course, if you only get to step 2, you have implemented > the DOS already. Preventing that sort of thing is surely outside > the scope of MIDCOM, thankfully. If we make the hypothesis that the attacker can see the client's traffic, then it is easy to predict the time at which the client will start using STUN -- for example, just after receiving a SIP INVITE. That offers interesting possibilities. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 13:36:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07108 for ; Fri, 10 May 2002 13:36:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02022 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 13:36:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01851; Fri, 10 May 2002 13:32:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01815 for ; Fri, 10 May 2002 13:32:13 -0400 (EDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06745 for ; Fri, 10 May 2002 13:32:04 -0400 (EDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 10:31:42 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 May 2002 10:31:42 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 10:31:42 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 10:31:42 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Fri, 10 May 2002 10:31:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 10:31:30 -0700 Message-ID: Thread-Topic: [midcom] STUN security showstopper thread-index: AcH4SCMFZtUAYl/oQbijm4ti3E/EMQAACieg From: "Christian Huitema" To: "Melinda Shore" , "Andrew Molitor" , X-OriginalArrivalTime: 10 May 2002 17:31:33.0611 (UTC) FILETIME=[876743B0:01C1F848] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA01816 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > From: Melinda Shore [mailto:mshore@cisco.com] > > At 12:12 PM 5/10/02 -0500, Andrew Molitor wrote: > > Doesn't the server signature cover the address and > >port? > > Right, but the client doesn't know its external address - > that's why it's using STUN - so has no way to know that > it's receiving a response to a bogus request. It leaves > us facing the prospect of protecting the client request, > and all that implies. Problem is, the client cannot sign its own IP address and port either, since the NAT is going to change them. As I said in the original message, the root cause is that there is no functional difference between a NAT and an attacker that does address spoofing. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 13:36:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07140 for ; Fri, 10 May 2002 13:36:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02036 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 13:36:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01809; Fri, 10 May 2002 13:32:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01776 for ; Fri, 10 May 2002 13:32:10 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06742 for ; Fri, 10 May 2002 13:32:01 -0400 (EDT) Received: from airborne.cisco.com (IDENT:mirapoint@airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4AHVdkc003736 for ; Fri, 10 May 2002 10:31:39 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-1007.cisco.com [10.21.99.239]) by airborne.cisco.com (Mirapoint) with SMTP id ABC73918; Fri, 10 May 2002 10:31:28 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 10 May 2002 13:31:38 -0400 Date: Fri, 10 May 2002 13:31:38 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] STUN security showstopper Message-ID: <20020510133137.C2692@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from amolitor@isis.visi.com on Fri, May 10, 2002 at 12:12:34PM -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, May 10, 2002 12:12:34PM -0500, Andrew Molitor wrote: > > 1) Client prepares request, including signature request. > > 2) Attacker intercepts request, and somehow manages to prevent it from > > reaching the server. > > 3) Attacker replaces the source IP address and source UDP port of the > > request by one of its own addresses and port, and forwards the request > > to the server. > > 4) Server dutifully note the address from which the packet is received, > > prepare a response, signs it, and send it back to the incoming address, > > i.e. the attacker. > > 5) Attacker receives the response, takes note of the mapping, replaces > > the address and port by the original values in the intercepted message, > > and sends the response to the client. > > Doesn't the server signature cover the address and > port? Sure, they're not signed in the request, but surely the > server signs the entire message it returns (including a length > field and probably some other junk like a client supplied > nonce). I confess I haven't been following STUN, but this > seems basic it me. View from a casual observer: What could the server sign that would be different it it was intercepted? The server is going to respond to the interceptor with the interceptor's global address/port, and the interceptor is going to pass that along to the client to get the desired behavior. The interceptor doesn't have to change anything at all in what the client originally provided -- and all will be signed. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 13:49:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07837 for ; Fri, 10 May 2002 13:49:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02692 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 13:49:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02585; Fri, 10 May 2002 13:46:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02549 for ; Fri, 10 May 2002 13:46:17 -0400 (EDT) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07709 for ; Fri, 10 May 2002 13:46:08 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id AAC1D8221; Fri, 10 May 2002 12:46:04 -0500 (CDT) Received: by isis.visi.com (Postfix, from userid 2286) id 5711376C27; Fri, 10 May 2002 12:46:04 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by isis.visi.com (Postfix) with ESMTP id 493C176C26; Fri, 10 May 2002 12:46:04 -0500 (CDT) Date: Fri, 10 May 2002 12:46:04 -0500 (CDT) From: Andrew Molitor To: Christian Huitema Cc: midcom@ietf.org Subject: RE: [midcom] STUN security showstopper In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Oh, I see! The attacker doesn't smash the mapping itself, he causes the server to invent a bad one -- pointing back to the attacker -- and then forwards that on to the client. As an added bonus, the attacker can now intercept media to the client, if this is a phone call. I think it might be a good idea to fix this :) I'm following, now, I think. On Fri, 10 May 2002, Christian Huitema wrote: > > Feel free to tell me why I'm stupid :) > Let's say sleepy... You may be overly generous! _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 14:11:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09279 for ; Fri, 10 May 2002 14:11:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04040 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 14:11:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03932; Fri, 10 May 2002 14:08:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03653 for ; Fri, 10 May 2002 14:03:02 -0400 (EDT) Received: from web14104.mail.yahoo.com (web14104.mail.yahoo.com [216.136.172.134]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08742 for ; Fri, 10 May 2002 14:02:52 -0400 (EDT) Message-ID: <20020510180301.41636.qmail@web14104.mail.yahoo.com> Received: from [216.191.234.70] by web14104.mail.yahoo.com via HTTP; Fri, 10 May 2002 11:03:01 PDT Date: Fri, 10 May 2002 11:03:01 -0700 (PDT) From: Mark Taylor Subject: RE: [midcom] STUN security showstopper To: midcom@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Christian Huitema wrote: >In fact, in the "shared LAN" scenario that people talk about most, >it is probably easier to mount a rogue-DHCP or a spoofed-ARP attack than the STUN attack. If it is a shared LAN, why wouldn't the attacker just use some sort of packet sniffer applicaion to eqavesdrop and be done with it __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 15:22:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13363 for ; Fri, 10 May 2002 15:22:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06978 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 15:23:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06701; Fri, 10 May 2002 15:09:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06670 for ; Fri, 10 May 2002 15:09:27 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12683 for ; Fri, 10 May 2002 15:09:05 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 12:08:44 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 May 2002 12:08:44 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 12:08:44 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 12:08:44 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Fri, 10 May 2002 12:08:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 12:08:47 -0700 Message-ID: Thread-Topic: [midcom] STUN security showstopper thread-index: AcH4SCMFZtUAYl/oQbijm4ti3E/EMQACUWyw From: "Christian Huitema" To: "Melinda Shore" Cc: X-OriginalArrivalTime: 10 May 2002 19:08:39.0466 (UTC) FILETIME=[17E230A0:01C1F856] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA06671 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit I wonder where we go from here. I believe that the attack scenario demonstrates that the "protected" version of STUN is not much better than the nonce-protected version. The attack the nonce protection requires that the attacker be able to listen to the client's traffic; the attack against the protected version is enabled if the attacker is able to listen to the client's traffic. The client will detect the attack against the nonce because it will receive two responses; the client will also receive two responses in the attack against the protected version; in both cases, the attack will only go undetected if the attacker succeeds in blocking either the direct request, or its response. A first possibility is to re-assess the domain of applicability of STUN. For example, if I use STUN on my home network which is directly connected to reputable ISP, I may not be too concerned by the attack scenario. If we follow this logic, we should keep STUN simple by just removing the cryptographic part, but restrict its application to "physically secure" attachment networks, such as home networks directly connected to an ISP, or even shared access networks that use a "per-client" encryption key, i.e. in which the clients cannot look at each other traffic. Unprotected open networks, such as for example the IETF WIFI network, would be left out of the domain of application. The problem with this "domain of applicability" option is that it is a bit of a cope-out, since it is very hard for the software in a mobile device to determine whether the local network is or is not physically secure -- the safe assumption being that it is never secure. In that case, the better security is probably to complement STUN with other solutions, which may or may not use cryptography. We have heard of many partial solutions, such as: 1) Wait for some time after the first response is received, in order to detect duplicate responses, possibly contradictory responses. 2) Renew the mapping requests at random, unpredictable intervals, in order to make interception difficult. 3) Ask mappings from several different servers. 4) Ask for a mapping response over a TLS channel. Neither of these responses is perfect. The first solution raises an alarm when a weird event happens, but does not tell which of the responses is to be believed. The second an third responses make the attack harder by using time diversity and/or special diversity: the attacker must catch all the attempts, to diverse servers; OTOH, a dedicated attacker near the client could do just that. The TLS channel will provide a reference mapping to a TLS connection, not the UDP connection that the will be use for VoIP; it can only be used for some plausibility control, and is a poor defense against an attacker on the same subnet; in any case, a dedicated attacker could also insert itself in the middle of a TLS connection. In short, none of that is terribly appealing. We may want to consider another line of defense that defends against the attacks that a false mapping enables, instead of trying to make sure that the mapping is genuine. For example, we could say that if you use STUN to set up an RTP connection, you should consider that the network connection is unsafe, and you should encrypt the RTC traffic, thus effectively thwarting the man in the middle attack. Or, if we have received several candidate mappings, we could conduct a continuity test to check the mapping that are usable, thus thwarting the denial of service attack. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 15:30:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13697 for ; Fri, 10 May 2002 15:30:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07275 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 15:29:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06954; Fri, 10 May 2002 15:22:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06924 for ; Fri, 10 May 2002 15:22:43 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13342 for ; Fri, 10 May 2002 15:22:33 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id D1EEA81EB for ; Fri, 10 May 2002 14:22:30 -0500 (CDT) Received: by isis.visi.com (Postfix, from userid 2286) id 5350C76C27; Fri, 10 May 2002 14:22:27 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by isis.visi.com (Postfix) with ESMTP id 1032776C26 for ; Fri, 10 May 2002 14:22:27 -0500 (CDT) Date: Fri, 10 May 2002 14:22:26 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] STUN security showstopper In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 10 May 2002, Christian Huitema wrote: > I wonder where we go from here. Hey, I know. Maybe we could go to work to develop a system by which the signaling infrastructure could securely communicate directly with the NAT device, and via that secure authenticated channel, establish and discover NAT bindings? This sort of thing may actually be sort of moot, though. If I can intercept STUN messages, I can probably intercept SIP or MGCP messages, which are far more interesting. Directly hammering on signaling is easier and more powerful. In fact, I don't even have to be a man in the middle. I can simply snoop for call setup attempts, and forge rejects back as fast as I can. Fixing STUN, or creating a secure alternative, is a worthy goal. In the final analysis it may simply not matter. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 15:31:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13814 for ; Fri, 10 May 2002 15:31:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07845 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 15:32:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07180; Fri, 10 May 2002 15:27:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07089 for ; Fri, 10 May 2002 15:27:08 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13532 for ; Fri, 10 May 2002 15:26:58 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4AJQb820529; Fri, 10 May 2002 14:26:37 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 14:27:00 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B1B@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Christian Huitema'" , Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 14:26:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F858.A6619CB0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F858.A6619CB0 Content-Type: text/plain; charset="iso-8859-1" I'm wondering whether its possible to build a profile at the STUN server based on the received (mapped) addresses over a sufficient period of time and compare any new arrival against the profile. Similar ideas are used in Intrusion Detection software. In a very limiting deployment scenario, the STUN service may be configured with the possible (expected) IP addresses of all NATs in the serving domain. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Friday, May 10, 2002 2:09 PM > To: Melinda Shore > Cc: midcom@ietf.org > Subject: RE: [midcom] STUN security showstopper > > > I wonder where we go from here. I believe that the attack scenario > demonstrates that the "protected" version of STUN is not much better > than the nonce-protected version. The attack the nonce protection > requires that the attacker be able to listen to the client's traffic; > the attack against the protected version is enabled if the attacker is > able to listen to the client's traffic. The client will detect the > attack against the nonce because it will receive two responses; the > client will also receive two responses in the attack against the > protected version; in both cases, the attack will only go > undetected if > the attacker succeeds in blocking either the direct request, or its > response. > > A first possibility is to re-assess the domain of > applicability of STUN. > For example, if I use STUN on my home network which is directly > connected to reputable ISP, I may not be too concerned by the attack > scenario. If we follow this logic, we should keep STUN simple by just > removing the cryptographic part, but restrict its application to > "physically secure" attachment networks, such as home > networks directly > connected to an ISP, or even shared access networks that use a > "per-client" encryption key, i.e. in which the clients cannot look at > each other traffic. Unprotected open networks, such as for example the > IETF WIFI network, would be left out of the domain of application. > > The problem with this "domain of applicability" option is that it is a > bit of a cope-out, since it is very hard for the software in a mobile > device to determine whether the local network is or is not physically > secure -- the safe assumption being that it is never secure. In that > case, the better security is probably to complement STUN with other > solutions, which may or may not use cryptography. We have > heard of many > partial solutions, such as: > > 1) Wait for some time after the first response is received, > in order to > detect duplicate responses, possibly contradictory responses. > > 2) Renew the mapping requests at random, unpredictable intervals, in > order to make interception difficult. > > 3) Ask mappings from several different servers. > > 4) Ask for a mapping response over a TLS channel. > > Neither of these responses is perfect. The first solution raises an > alarm when a weird event happens, but does not tell which of the > responses is to be believed. The second an third responses make the > attack harder by using time diversity and/or special diversity: the > attacker must catch all the attempts, to diverse servers; OTOH, a > dedicated attacker near the client could do just that. The TLS channel > will provide a reference mapping to a TLS connection, not the UDP > connection that the will be use for VoIP; it can only be used for some > plausibility control, and is a poor defense against an attacker on the > same subnet; in any case, a dedicated attacker could also > insert itself > in the middle of a TLS connection. In short, none of that is terribly > appealing. > > We may want to consider another line of defense that defends > against the > attacks that a false mapping enables, instead of trying to make sure > that the mapping is genuine. For example, we could say that if you use > STUN to set up an RTP connection, you should consider that the network > connection is unsafe, and you should encrypt the RTC traffic, thus > effectively thwarting the man in the middle attack. Or, if we have > received several candidate mappings, we could conduct a > continuity test > to check the mapping that are usable, thus thwarting the denial of > service attack. > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1F858.A6619CB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] STUN security showstopper

I'm wondering whether its possible to build a profile = at the STUN server based on the received (mapped) addresses over a = sufficient period of time and compare any new arrival against the = profile. Similar ideas are used in Intrusion Detection = software.

In a very limiting deployment scenario, the STUN = service may be configured with the possible (expected) IP addresses of = all NATs in the serving domain.

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> Sent: Friday, May 10, 2002 2:09 PM
> To: Melinda Shore
> Cc: midcom@ietf.org
> Subject: RE: [midcom] STUN security = showstopper
>
>
> I wonder where we go from here. I believe that = the attack scenario
> demonstrates that the "protected" = version of STUN is not much better
> than the nonce-protected version. The attack = the nonce protection
> requires that the attacker be able to listen to = the client's traffic;
> the attack against the protected version is = enabled if the attacker is
> able to listen to the client's traffic. The = client will detect the
> attack against the nonce because it will = receive two responses; the
> client will also receive two responses in the = attack against the
> protected version; in both cases, the attack = will only go
> undetected if
> the attacker succeeds in blocking either the = direct request, or its
> response.
>
> A first possibility is to re-assess the domain = of
> applicability of STUN.
> For example, if I use STUN on my home network = which is directly
> connected to reputable ISP, I may not be too = concerned by the attack
> scenario. If we follow this logic, we should = keep STUN simple by just
> removing the cryptographic part, but restrict = its application to
> "physically secure" attachment = networks, such as home
> networks directly
> connected to an ISP, or even shared access = networks that use a
> "per-client" encryption key, i.e. in = which the clients cannot look at
> each other traffic. Unprotected open networks, = such as for example the
> IETF WIFI network, would be left out of the = domain of application.
>
> The problem with this "domain of = applicability" option is that it is a
> bit of a cope-out, since it is very hard for = the software in a mobile
> device to determine whether the local network = is or is not physically
> secure -- the safe assumption being that it is = never secure. In that
> case, the better security is probably to = complement STUN with other
> solutions, which may or may not use = cryptography. We have
> heard of many
> partial solutions, such as:
>
> 1) Wait for some time after the first response = is received,
> in order to
> detect duplicate responses, possibly = contradictory responses.
>
> 2) Renew the mapping requests at random, = unpredictable intervals, in
> order to make interception difficult.
>
> 3) Ask mappings from several different = servers.
>
> 4) Ask for a mapping response over a TLS = channel.
>
> Neither of these responses is perfect. The = first solution raises an
> alarm when a weird event happens, but does not = tell which of the
> responses is to be believed. The second an = third responses make the
> attack harder by using time diversity and/or = special diversity: the
> attacker must catch all the attempts, to = diverse servers; OTOH, a
> dedicated attacker near the client could do = just that. The TLS channel
> will provide a reference mapping to a TLS = connection, not the UDP
> connection that the will be use for VoIP; it = can only be used for some
> plausibility control, and is a poor defense = against an attacker on the
> same subnet; in any case, a dedicated attacker = could also
> insert itself
> in the middle of a TLS connection. In short, = none of that is terribly
> appealing.
>
> We may want to consider another line of defense = that defends
> against the
> attacks that a false mapping enables, instead = of trying to make sure
> that the mapping is genuine. For example, we = could say that if you use
> STUN to set up an RTP connection, you should = consider that the network
> connection is unsafe, and you should encrypt = the RTC traffic, thus
> effectively thwarting the man in the middle = attack. Or, if we have
> received several candidate mappings, we could = conduct a
> continuity test
> to check the mapping that are usable, thus = thwarting the denial of
> service attack.
>
> -- Christian Huitema
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1F858.A6619CB0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 15:36:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13994 for ; Fri, 10 May 2002 15:36:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07953 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 15:36:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07786; Fri, 10 May 2002 15:31:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07755 for ; Fri, 10 May 2002 15:31:21 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13765 for ; Fri, 10 May 2002 15:31:11 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 12:30:50 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 May 2002 12:30:50 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 12:30:50 -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(5.0.2195.4905); Fri, 10 May 2002 12:30:49 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Fri, 10 May 2002 12:30:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 12:30:45 -0700 Message-ID: Thread-Topic: [midcom] STUN security showstopper thread-index: AcH4WD8/lzrTks/cRSe+jQUfPMTM2gAAEX9A From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 10 May 2002 19:30:34.0280 (UTC) FILETIME=[2792E280:01C1F859] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA07756 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > Hey, I know. Maybe we could go to work to develop a system > by which the signaling infrastructure could securely communicate > directly with the NAT device, and via that secure authenticated > channel, establish and discover NAT bindings? Or deploy IPv6, and be done with address translation... > This sort of thing may actually be sort of moot, though. > If I can intercept STUN messages, I can probably intercept SIP > or MGCP messages, which are far more interesting. Directly > hammering on signaling is easier and more powerful. That is not correct, at least not for SIP. The client has the option to connect to the SIP server using TLS, which effectively prevents this kind of attacks. > In fact, I don't even have to be a man in the middle. > I can simply snoop for call setup attempts, and forge rejects > back as fast as I can. You can only do that if the client insists on using an insecure communication channel with the server. On of the reason we should phase out SIP over UDP. > Fixing STUN, or creating a secure alternative, is a worthy > goal. In the final analysis it may simply not matter. Don't think so. Whatever new stuff we design will take several years to deploy. In the meantime we will have to use solutions like STUN. (Or IPv6 through Shipworm/Teredo, but the security issues are exactly the same.) -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 15:41:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14266 for ; Fri, 10 May 2002 15:41:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08499 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 15:42:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07996; Fri, 10 May 2002 15:36:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07967 for ; Fri, 10 May 2002 15:36:32 -0400 (EDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14009 for ; Fri, 10 May 2002 15:36:22 -0400 (EDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 12:33:40 -0700 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 May 2002 12:33:40 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 12:33:40 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 12:33:40 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Fri, 10 May 2002 12:33:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 12:33:41 -0700 Message-ID: Thread-Topic: [midcom] STUN security showstopper thread-index: AcH4WJ1x21ATFQkbQqaq2SKctKWDQgAAJjfg From: "Christian Huitema" To: "Sanjoy Sen" , "Melinda Shore" Cc: X-OriginalArrivalTime: 10 May 2002 19:33:29.0939 (UTC) FILETIME=[90465230:01C1F859] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA07968 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > In a very limiting deployment scenario, the STUN service may be configured > with the possible (expected) IP addresses of all NATs in the serving > domain. That will certainly help against interception by 3rd parties that are on the path between the NAT and the server. It will not help in the shared access network scenario, since the attacker and the target are behind the same NAT, and thus use the same set of plausible IP addresses. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 15:47:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14519 for ; Fri, 10 May 2002 15:47:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08717 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 15:48:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08274; Fri, 10 May 2002 15:40:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08245 for ; Fri, 10 May 2002 15:40:52 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14168 for ; Fri, 10 May 2002 15:40:42 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4AJemD07571 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 10 May 2002 12:40:49 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4AJehh00044; Fri, 10 May 2002 12:40:47 -0700 (PDT) Subject: Re: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt To: "Joel M. Halpern" Cc: midcom@ietf.org Date: Fri, 10 May 2002 14:40:28 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Joel, Thank you for your comments on the evaluation of RSIP against the MIDCOM requirements. I did not respond to your comments earlier because I expected more comments and hoped to possibly respond to them all at once. Since yours are the only comments I received, I'll respond to all the comments I received all at once! :-) > My primary observation reading this document is that it would be > helpful if you clearly and early in the document indicated that > your proposal is to change the data handling behavior of te > middlebox. It is NOT my intention to change the data handling behavior of the middlebox. The intention of the I-D was to show how RSIP could be extended to cover middleboxes that are different from what RSIP anti- cipated when it was designed. > If this is not your intent, then significant attention is needed > to how RSIP would work without the currently required tunneling > (you merely say "null tunnel", but there is a lot more to it than > that. Yes and no. When I worked through the design of a "null" tunnel, it fit into RSIP very nicely and allowed RSIP to satisfy the MIDCOM require- ments as stated in the I-D. However, it also exposed a number of issues that I don't think are adequately addressed by the MIDCOM requirements. Maybe they are addressed, but I just don't see them. I could be wrong. Yes, I owe everybody a description of a "null" tunnel, how it would work, how RSIP then satisfies the MIDCOM requirements to the extent claimed in the evaluation I-D. I am preparing that as a separate I-D that also raises the other issues I think I have found. I should have that in a few weeks, hopefully before the cut-off for the Yokahama meeting. > The other issue is that as I understand it RSIP as currently > designed assumes that the requestor and the communicating party > are one and the same. If this is so, and is a behavior you intend > to retain, please say so. If it is a behavior you believe can be > changed, then some description of the complications and degree of > change to RSIP would be helpful. I wouldn't say that "RSIP ... assumes that the requestor and the communi- cating party are one and the same", it's more that it didn't admit to the possiblity that they might not be the same. Subtle, but important, dis- tinction. That said, what happens to RSIP if the application and the agent aren't the same? I guess that depends on your reading of the RSIP specification, as this is now a gray area not addressed by the specification. In check- ing this with some of my colleagues, we have found a way to read the specification that would allow the behavior intended by the MIDCOM requirements. But it's such a weird, obscure, perverse, etc., reading that I wouldn't propose it as "the right thing to do." So, yes, RSIP should be revised to explicitly account and allow for agents as well as applications. This change is really simple: if a client isn't "speaking for itself", then it identifies the client for which it is speaking. All it takes is one (maybe a few) additional parameters in the relevant RSIP messages. Extremely easy to do, with full backward com- patibility, because RSIP was designed to be extensible, in exactly this way! BTW, it was when we were exploring this "agent vs. application" issue that we discovered the other issues I mentioned above. Again, maybe they really aren't issues, or they are issues that have already been addressed, but I'll raise them anyhow in the new I-D. I have revised the evaluation I-D, hopefully addressing the issues you raised. The changes are basically what I described above. Again, thank you for your comments. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 15:58:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14873 for ; Fri, 10 May 2002 15:58:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09259 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 15:58:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08970; Fri, 10 May 2002 15:54:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08941 for ; Fri, 10 May 2002 15:54:03 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14697 for ; Fri, 10 May 2002 15:53:52 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4AJrW824772; Fri, 10 May 2002 14:53:32 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 14:53:55 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B1C@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Christian Huitema'" , Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 14:53:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F85C.686406B0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F85C.686406B0 Content-Type: text/plain; charset="iso-8859-1" I thought that we're always dealing with your first scenario - attacker between NAT and server. In the shared network scenario, anybody who can sniff packets can do this and the only way to prevent this is to encrypt all client packets. But this can happen with or without the use of STUN. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Friday, May 10, 2002 2:34 PM > To: Sen, Sanjoy [NGC:B692:EXCH]; Melinda Shore > Cc: midcom@ietf.org > Subject: RE: [midcom] STUN security showstopper > > > > In a very limiting deployment scenario, the STUN service may be > configured > > with the possible (expected) IP addresses of all NATs in > the serving > > domain. > > That will certainly help against interception by 3rd parties > that are on > the path between the NAT and the server. It will not help in > the shared > access network scenario, since the attacker and the target are behind > the same NAT, and thus use the same set of plausible IP addresses. > > -- Christian Huitema > > > ------_=_NextPart_001_01C1F85C.686406B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] STUN security showstopper

I thought that we're always dealing with your first = scenario - attacker between NAT and server.

In the shared network scenario, anybody who can sniff = packets can do this and the only way to prevent this is to encrypt all = client packets. But this can happen with or without the use of = STUN.

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> Sent: Friday, May 10, 2002 2:34 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]; Melinda = Shore
> Cc: midcom@ietf.org
> Subject: RE: [midcom] STUN security = showstopper
>
>
> > In a very limiting deployment scenario, = the STUN service may be
> configured
> > with the possible (expected) IP addresses = of all NATs in
> the serving
> > domain.
>
> That will certainly help against interception = by 3rd parties
> that are on
> the path between the NAT and the server. It = will not help in
> the shared
> access network scenario, since the attacker and = the target are behind
> the same NAT, and thus use the same set of = plausible IP addresses.
>
> -- Christian Huitema
>
> 
>

------_=_NextPart_001_01C1F85C.686406B0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 16:01:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15012 for ; Fri, 10 May 2002 16:01:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09964 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 16:01:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09167; Fri, 10 May 2002 15:57:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09138 for ; Fri, 10 May 2002 15:57:22 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14816 for ; Fri, 10 May 2002 15:57:10 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id PAA09182; Fri, 10 May 2002 15:56:12 -0400 (EDT) Subject: RE: [midcom] STUN security showstopper To: "Christian Huitema" Cc: "Sanjoy Sen" , "Melinda Shore" , Date: Fri, 10 May 2002 15:40:53 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 05/10/2002 03:56:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org If this is a theft attack from an internal attacker.,wouldn't the attacker have to supply an internal address? Attackers could mount DOS attacks by building profiles of reasonable addresses but I do not see how a theft attack would work. "Christian Huitema" @ietf.org on 05/10/2002 03:33:41 PM Sent by: midcom-admin@ietf.org To: "Sanjoy Sen" , "Melinda Shore" cc: Subject: RE: [midcom] STUN security showstopper > In a very limiting deployment scenario, the STUN service may be configured > with the possible (expected) IP addresses of all NATs in the serving > domain. That will certainly help against interception by 3rd parties that are on the path between the NAT and the server. It will not help in the shared access network scenario, since the attacker and the target are behind the same NAT, and thus use the same set of plausible IP addresses. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 16:01:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15039 for ; Fri, 10 May 2002 16:01:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10019 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 16:02:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09109; Fri, 10 May 2002 15:57:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09082 for ; Fri, 10 May 2002 15:57:02 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14796 for ; Fri, 10 May 2002 15:56:52 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id PAA09072; Fri, 10 May 2002 15:56:00 -0400 (EDT) Subject: RE: [midcom] STUN security showstopper To: "Sanjoy Sen" Cc: "'Christian Huitema'" , Melinda Shore , midcom@ietf.org Date: Fri, 10 May 2002 15:34:30 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 05/10/2002 03:56:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is the 'reasonable address' idea that was dicussed earlier and which was deprecated in favor of cryptogrphic methods. "Sanjoy Sen"@ietf.org on 05/10/2002 03:26:57 PM Sent by: midcom-admin@ietf.org To: "'Christian Huitema'" , Melinda Shore cc: midcom@ietf.org Subject: RE: [midcom] STUN security showstopper I'm wondering whether its possible to build a profile at the STUN server based on the received (mapped) addresses over a sufficient period of time and compare any new arrival against the profile. Similar ideas are used in Intrusion Detection software. In a very limiting deployment scenario, the STUN service may be configured with the possible (expected) IP addresses of all NATs in the serving domain. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Friday, May 10, 2002 2:09 PM > To: Melinda Shore > Cc: midcom@ietf.org > Subject: RE: [midcom] STUN security showstopper > > > I wonder where we go from here. I believe that the attack scenario > demonstrates that the "protected" version of STUN is not much better > than the nonce-protected version. The attack the nonce protection > requires that the attacker be able to listen to the client's traffic; > the attack against the protected version is enabled if the attacker is > able to listen to the client's traffic. The client will detect the > attack against the nonce because it will receive two responses; the > client will also receive two responses in the attack against the > protected version; in both cases, the attack will only go > undetected if > the attacker succeeds in blocking either the direct request, or its > response. > > A first possibility is to re-assess the domain of > applicability of STUN. > For example, if I use STUN on my home network which is directly > connected to reputable ISP, I may not be too concerned by the attack > scenario. If we follow this logic, we should keep STUN simple by just > removing the cryptographic part, but restrict its application to > "physically secure" attachment networks, such as home > networks directly > connected to an ISP, or even shared access networks that use a > "per-client" encryption key, i.e. in which the clients cannot look at > each other traffic. Unprotected open networks, such as for example the > IETF WIFI network, would be left out of the domain of application. > > The problem with this "domain of applicability" option is that it is a > bit of a cope-out, since it is very hard for the software in a mobile > device to determine whether the local network is or is not physically > secure -- the safe assumption being that it is never secure. In that > case, the better security is probably to complement STUN with other > solutions, which may or may not use cryptography. We have > heard of many > partial solutions, such as: > > 1) Wait for some time after the first response is received, > in order to > detect duplicate responses, possibly contradictory responses. > > 2) Renew the mapping requests at random, unpredictable intervals, in > order to make interception difficult. > > 3) Ask mappings from several different servers. > > 4) Ask for a mapping response over a TLS channel. > > Neither of these responses is perfect. The first solution raises an > alarm when a weird event happens, but does not tell which of the > responses is to be believed. The second an third responses make the > attack harder by using time diversity and/or special diversity: the > attacker must catch all the attempts, to diverse servers; OTOH, a > dedicated attacker near the client could do just that. The TLS channel > will provide a reference mapping to a TLS connection, not the UDP > connection that the will be use for VoIP; it can only be used for some > plausibility control, and is a poor defense against an attacker on the > same subnet; in any case, a dedicated attacker could also > insert itself > in the middle of a TLS connection. In short, none of that is terribly > appealing. > > We may want to consider another line of defense that defends > against the > attacks that a false mapping enables, instead of trying to make sure > that the mapping is genuine. For example, we could say that if you use > STUN to set up an RTP connection, you should consider that the network > connection is unsafe, and you should encrypt the RTC traffic, thus > effectively thwarting the man in the middle attack. Or, if we have > received several candidate mappings, we could conduct a > continuity test > to check the mapping that are usable, thus thwarting the denial of > service attack. > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 17:14:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18148 for ; Fri, 10 May 2002 17:14:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14322 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 17:14:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14086; Fri, 10 May 2002 17:04:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13995 for ; Fri, 10 May 2002 17:04:18 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17653 for ; Fri, 10 May 2002 17:04:07 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4AL3k825552; Fri, 10 May 2002 16:03:46 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 16:04:10 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B1F@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Tom_Gray@Mitel.COM'" Cc: "'Christian Huitema'" , "'Melinda Shore'" , "'midcom@ietf.org'" Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 16:04:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F866.3B748850" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F866.3B748850 Content-Type: text/plain; charset="iso-8859-1" The difference is server vs client. Pretty much the same idea. > -----Original Message----- > From: Tom_Gray@Mitel.COM [mailto:Tom_Gray@Mitel.COM] > Sent: Friday, May 10, 2002 2:35 PM > To: Sen, Sanjoy [NGC:B692:EXCH] > Cc: 'Christian Huitema'; Melinda Shore; midcom@ietf.org > Subject: RE: [midcom] STUN security showstopper > > > > This is the 'reasonable address' idea that was dicussed > earlier and which > was deprecated in favor of cryptogrphic methods. > > > > > > > "Sanjoy Sen"@ietf.org on > 05/10/2002 03:26:57 PM > > Sent by: midcom-admin@ietf.org > > > To: "'Christian Huitema'" , > Melinda Shore > > cc: midcom@ietf.org > Subject: RE: [midcom] STUN security showstopper > > > > > I'm wondering whether its possible to build a profile at the > STUN server > based on the received (mapped) addresses over a sufficient > period of time > and compare any new arrival against the profile. Similar > ideas are used in > Intrusion Detection software. > > In a very limiting deployment scenario, the STUN service may > be configured > with the possible (expected) IP addresses of all NATs in the serving > domain. > > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > Sent: Friday, May 10, 2002 2:09 PM > > To: Melinda Shore > > Cc: midcom@ietf.org > > Subject: RE: [midcom] STUN security showstopper > > > > > > I wonder where we go from here. I believe that the attack scenario > > demonstrates that the "protected" version of STUN is not much better > > than the nonce-protected version. The attack the nonce protection > > requires that the attacker be able to listen to the > client's traffic; > > the attack against the protected version is enabled if the > attacker is > > able to listen to the client's traffic. The client will detect the > > attack against the nonce because it will receive two responses; the > > client will also receive two responses in the attack against the > > protected version; in both cases, the attack will only go > > undetected if > > the attacker succeeds in blocking either the direct request, or its > > response. > > > > A first possibility is to re-assess the domain of > > applicability of STUN. > > For example, if I use STUN on my home network which is directly > > connected to reputable ISP, I may not be too concerned by the attack > > scenario. If we follow this logic, we should keep STUN > simple by just > > removing the cryptographic part, but restrict its application to > > "physically secure" attachment networks, such as home > > networks directly > > connected to an ISP, or even shared access networks that use a > > "per-client" encryption key, i.e. in which the clients > cannot look at > > each other traffic. Unprotected open networks, such as for > example the > > IETF WIFI network, would be left out of the domain of application. > > > > The problem with this "domain of applicability" option is > that it is a > > bit of a cope-out, since it is very hard for the software > in a mobile > > device to determine whether the local network is or is not > physically > > secure -- the safe assumption being that it is never secure. In that > > case, the better security is probably to complement STUN with other > > solutions, which may or may not use cryptography. We have > > heard of many > > partial solutions, such as: > > > > 1) Wait for some time after the first response is received, > > in order to > > detect duplicate responses, possibly contradictory responses. > > > > 2) Renew the mapping requests at random, unpredictable intervals, in > > order to make interception difficult. > > > > 3) Ask mappings from several different servers. > > > > 4) Ask for a mapping response over a TLS channel. > > > > Neither of these responses is perfect. The first solution raises an > > alarm when a weird event happens, but does not tell which of the > > responses is to be believed. The second an third responses make the > > attack harder by using time diversity and/or special diversity: the > > attacker must catch all the attempts, to diverse servers; OTOH, a > > dedicated attacker near the client could do just that. The > TLS channel > > will provide a reference mapping to a TLS connection, not the UDP > > connection that the will be use for VoIP; it can only be > used for some > > plausibility control, and is a poor defense against an > attacker on the > > same subnet; in any case, a dedicated attacker could also > > insert itself > > in the middle of a TLS connection. In short, none of that > is terribly > > appealing. > > > > We may want to consider another line of defense that defends > > against the > > attacks that a false mapping enables, instead of trying to make sure > > that the mapping is genuine. For example, we could say that > if you use > > STUN to set up an RTP connection, you should consider that > the network > > connection is unsafe, and you should encrypt the RTC traffic, thus > > effectively thwarting the man in the middle attack. Or, if we have > > received several candidate mappings, we could conduct a > > continuity test > > to check the mapping that are usable, thus thwarting the denial of > > service attack. > > > > -- Christian Huitema > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > > > > ------_=_NextPart_001_01C1F866.3B748850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] STUN security showstopper

The difference is server vs client. Pretty much the = same idea.

> -----Original Message-----
> From: Tom_Gray@Mitel.COM [mailto:Tom_Gray@Mitel.COM]=
> Sent: Friday, May 10, 2002 2:35 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]
> Cc: 'Christian Huitema'; Melinda Shore; = midcom@ietf.org
> Subject: RE: [midcom] STUN security = showstopper
>
>
>
> This is the 'reasonable address' idea that was = dicussed
> earlier and which
> was deprecated in favor of cryptogrphic = methods.
>
>
>
>
>
>
> "Sanjoy = Sen"<sanjoy@nortelnetworks.com>@ietf.org on
> 05/10/2002 03:26:57 PM
>
> Sent by:  midcom-admin@ietf.org
>
>
> To:   "'Christian Huitema'" = <huitema@windows.microsoft.com>,
> Melinda Shore
>        = <mshore@cisco.com>
> cc:   midcom@ietf.org
> Subject:  RE: [midcom] STUN security = showstopper
>
>
>
>
> I'm wondering whether its possible to build a = profile at the
> STUN server
> based on the received (mapped) addresses over a = sufficient
> period of time
> and compare any new arrival against the = profile. Similar
> ideas are used in
> Intrusion Detection software.
>
> In a very limiting deployment scenario, the = STUN service may
> be configured
> with the possible (expected) IP addresses of = all NATs in the serving
> domain.
>
> > -----Original Message-----
> > From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> > Sent: Friday, May 10, 2002 2:09 PM
> > To: Melinda Shore
> > Cc: midcom@ietf.org
> > Subject: RE: [midcom] STUN security = showstopper
> >
> >
> > I wonder where we go from here. I believe = that the attack scenario
> > demonstrates that the = "protected" version of STUN is not much better
> > than the nonce-protected version. The = attack the nonce protection
> > requires that the attacker be able to = listen to the
> client's traffic;
> > the attack against the protected version = is enabled if the
> attacker is
> > able to listen to the client's traffic. = The client will detect the
> > attack against the nonce because it will = receive two responses; the
> > client will also receive two responses in = the attack against the
> > protected version; in both cases, the = attack will only go
> > undetected if
> > the attacker succeeds in blocking either = the direct request, or its
> > response.
> >
> > A first possibility is to re-assess the = domain of
> > applicability of STUN.
> > For example, if I use STUN on my home = network which is directly
> > connected to reputable ISP, I may not be = too concerned by the attack
> > scenario. If we follow this logic, we = should keep STUN
> simple by just
> > removing the cryptographic part, but = restrict its application to
> > "physically secure" attachment = networks, such as home
> > networks directly
> > connected to an ISP, or even shared access = networks that use a
> > "per-client" encryption key, = i.e. in which the clients
> cannot look at
> > each other traffic. Unprotected open = networks, such as for
> example the
> > IETF WIFI network, would be left out of = the domain of application.
> >
> > The problem with this "domain of = applicability" option is
> that it is a
> > bit of a cope-out, since it is very hard = for the software
> in a mobile
> > device to determine whether the local = network is or is not
> physically
> > secure -- the safe assumption being that = it is never secure. In that
> > case, the better security is probably to = complement STUN with other
> > solutions, which may or may not use = cryptography. We have
> > heard of many
> > partial solutions, such as:
> >
> > 1) Wait for some time after the first = response is received,
> > in order to
> > detect duplicate responses, possibly = contradictory responses.
> >
> > 2) Renew the mapping requests at random, = unpredictable intervals, in
> > order to make interception = difficult.
> >
> > 3) Ask mappings from several different = servers.
> >
> > 4) Ask for a mapping response over a TLS = channel.
> >
> > Neither of these responses is perfect. The = first solution raises an
> > alarm when a weird event happens, but does = not tell which of the
> > responses is to be believed. The second an = third responses make the
> > attack harder by using time diversity = and/or special diversity: the
> > attacker must catch all the attempts, to = diverse servers; OTOH, a
> > dedicated attacker near the client could = do just that. The
> TLS channel
> > will provide a reference mapping to a TLS = connection, not the UDP
> > connection that the will be use for VoIP; = it can only be
> used for some
> > plausibility control, and is a poor = defense against an
> attacker on the
> > same subnet; in any case, a dedicated = attacker could also
> > insert itself
> > in the middle of a TLS connection. In = short, none of that
> is terribly
> > appealing.
> >
> > We may want to consider another line of = defense that defends
> > against the
> > attacks that a false mapping enables, = instead of trying to make sure
> > that the mapping is genuine. For example, = we could say that
> if you use
> > STUN to set up an RTP connection, you = should consider that
> the network
> > connection is unsafe, and you should = encrypt the RTC traffic, thus
> > effectively thwarting the man in the = middle attack. Or, if we have
> > received several candidate mappings, we = could conduct a
> > continuity test
> > to check the mapping that are usable, thus = thwarting the denial of
> > service attack.
> >
> > -- Christian Huitema
> >
> > = _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > https://www1.ietf.org/mailman/listinfo/midcom
> >
>
>
>
>
>

------_=_NextPart_001_01C1F866.3B748850-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 18:07:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20840 for ; Fri, 10 May 2002 18:07:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17372 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 18:07:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17209; Fri, 10 May 2002 18:02:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17181 for ; Fri, 10 May 2002 18:01:59 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20709 for ; Fri, 10 May 2002 18:01:43 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4AM1GuF003273; Fri, 10 May 2002 15:01:16 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADV42028; Fri, 10 May 2002 14:58:25 -0700 (PDT) Message-Id: <5.1.0.14.0.20020510180354.00ac05f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 May 2002 18:05:43 -0400 To: Tom_Gray@Mitel.COM From: Melinda Shore Subject: RE: [midcom] STUN security showstopper Cc: midcom@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 03:34 PM 5/10/02 -0400, Tom_Gray@Mitel.COM wrote: >This is the 'reasonable address' idea that was dicussed earlier and which >was deprecated in favor of cryptogrphic methods. Not really. The "reasonable address" suggestion is easily defeated, unfortunately, and that's why it hasn't been pursued. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 18:11:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20937 for ; Fri, 10 May 2002 18:11:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17505 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 18:11:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17337; Fri, 10 May 2002 18:06:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17306 for ; Fri, 10 May 2002 18:06:24 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20804 for ; Fri, 10 May 2002 18:06:10 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4AM5VuF005496; Fri, 10 May 2002 15:05:31 -0700 (PDT) Received: from ASIMU-W2K1.cisco.com (ams-clip-vpn-dhcp4112.cisco.com [10.50.16.15]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA04553; Fri, 10 May 2002 15:05:32 -0700 (PDT) Message-Id: <4.3.2.7.2.20020510144847.00b112b0@mira-sjcm-1.cisco.com> X-Sender: asimu@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 May 2002 15:05:33 -0700 To: huitema@windows.microsoft.com From: Adina Simu Subject: RE: [midcom] STUN security showstopper Cc: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org (this might have been already proposed and rejected, if this is the case I apologize) Once the client receives the STUN response containing a MAPPED ADDRESS, one way to verify that the address really points (belongs) to him is to ping a server in the Global space, using as source address the MAPPED ADDRESS. The ping packet should go through NATs untranslated, and it will hit the Global space with the same MAPPED address as source address. The reply will be destined to MAPPED address. If the client receives the reply, mapped-address is indeed his. The server should not be the STUN server (in case somebody snoops packets destined to the STUN server). It could be the client's proxy... or similar. -Adina >> In a very limiting deployment scenario, the STUN service may be configured >> with the possible (expected) IP addresses of all NATs in the serving >> domain. > That will certainly help against interception by 3rd parties that are on > the path between the NAT and the server. It will not help in the shared > access network scenario, since the attacker and the target are behind > the same NAT, and thus use the same set of plausible IP addresses. > -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 18:17:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21057 for ; Fri, 10 May 2002 18:17:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17658 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 18:17:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17550; Fri, 10 May 2002 18:12:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17519 for ; Fri, 10 May 2002 18:12:17 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20960 for ; Fri, 10 May 2002 18:12:06 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4AMBi809193; Fri, 10 May 2002 17:11:45 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 17:12:09 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187B21@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Adina Simu'" , "'huitema@windows.microsoft.com'" Cc: "'midcom@ietf.org'" Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 17:12:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F86F.BA756A80" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F86F.BA756A80 Content-Type: text/plain; charset="iso-8859-1" Will the packet be properly routed in the private domain (behind NAT)? > -----Original Message----- > From: Adina Simu [mailto:asimu@cisco.com] > Sent: Friday, May 10, 2002 5:06 PM > To: huitema@windows.microsoft.com > Cc: midcom@ietf.org > Subject: RE: [midcom] STUN security showstopper > > > (this might have been already proposed and rejected, if this > is the case I > apologize) > > Once the client receives the STUN response containing a > MAPPED ADDRESS, one > way to verify that the address really points (belongs) to him > is to ping a > server in the Global space, using as source address the > MAPPED ADDRESS. The > ping packet should go through NATs untranslated, and it will > hit the Global > space with the same MAPPED address as source address. The > reply will be > destined to MAPPED address. If the client receives the reply, > mapped-address is indeed his. > > The server should not be the STUN server (in case somebody > snoops packets > destined to the STUN server). It could be the client's > proxy... or similar. > > -Adina > > >> In a very limiting deployment scenario, the STUN service > may be configured > >> with the possible (expected) IP addresses of all NATs in > the serving > >> domain. > > > That will certainly help against interception by 3rd > parties that are on > > the path between the NAT and the server. It will not help > in the shared > > access network scenario, since the attacker and the target > are behind > > the same NAT, and thus use the same set of plausible IP addresses. > > > -- Christian Huitema > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1F86F.BA756A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] STUN security showstopper

Will the packet be properly routed in the private = domain (behind NAT)?

> -----Original Message-----
> From: Adina Simu [mailto:asimu@cisco.com]
> Sent: Friday, May 10, 2002 5:06 PM
> To: huitema@windows.microsoft.com
> Cc: midcom@ietf.org
> Subject: RE: [midcom] STUN security = showstopper
>
>
> (this might have been already proposed and = rejected, if this
> is the case I
> apologize)
>
> Once the client receives the STUN response = containing a
> MAPPED ADDRESS, one
> way to verify that the address really points = (belongs) to him
> is to ping a
> server in the Global space, using as source = address the
> MAPPED ADDRESS. The
> ping packet should go through NATs = untranslated, and it will
> hit the Global
> space with the same MAPPED address as source = address. The
> reply will be
> destined to MAPPED address. If the client = receives the reply,
> mapped-address is indeed his.
>
> The server should not be the STUN server (in = case somebody
> snoops packets
> destined to the STUN server). It could be the = client's
> proxy... or similar.
>
> -Adina
>
>  >> In a very limiting deployment = scenario, the STUN service
> may be configured
>  >> with the possible (expected) IP = addresses of all NATs in
> the serving
>  >> domain.
>
>  > That will certainly help against = interception by 3rd
> parties that are on
>  > the path between the NAT and the = server. It will not help
> in the shared
>  > access network scenario, since the = attacker and the target
> are behind
>  > the same NAT, and thus use the same = set of plausible IP addresses.
>
>  > -- Christian Huitema
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1F86F.BA756A80-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 18:49:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21680 for ; Fri, 10 May 2002 18:49:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA19050 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 18:50:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18941; Fri, 10 May 2002 18:45:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18910 for ; Fri, 10 May 2002 18:45:17 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21565 for ; Fri, 10 May 2002 18:45:06 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4AMikHT004994; Fri, 10 May 2002 15:44:46 -0700 (PDT) Received: from ASIMU-W2K1.cisco.com (ams-clip-vpn-dhcp4110.cisco.com [10.50.16.13]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA00639; Fri, 10 May 2002 15:44:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20020510153549.00b07260@mira-sjcm-1.cisco.com> X-Sender: asimu@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 May 2002 15:44:36 -0700 To: "Sanjoy Sen" From: Adina Simu Subject: RE: [midcom] STUN security showstopper Cc: "'huitema@windows.microsoft.com'" , "'midcom@ietf.org'" In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187B21@zrc2c012.us.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3823187==_.ALT" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --=====================_3823187==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:12 PM 5/10/2002 -0500, Sanjoy Sen wrote: >Will the packet be properly routed in the private domain (behind NAT)? This depends on how the routing is configured -- but, chances are it will be properly routed. BTW same routing is needed in case of 2 clients behind the same NAT wishing to talk to each other: Inside the local domain, there must be routes configured for the domain's Global addresses pointing to the Global Internet. (it might be a good idea to incorporate this routing config recommendation within the STUN doc). > > -----Original Message----- > > From: Adina Simu [mailto:asimu@cisco.com] > > Sent: Friday, May 10, 2002 5:06 PM > > To: huitema@windows.microsoft.com > > Cc: midcom@ietf.org > > Subject: RE: [midcom] STUN security showstopper > > > > > > (this might have been already proposed and rejected, if this > > is the case I > > apologize) > > > > Once the client receives the STUN response containing a > > MAPPED ADDRESS, one > > way to verify that the address really points (belongs) to him > > is to ping a > > server in the Global space, using as source address the > > MAPPED ADDRESS. The > > ping packet should go through NATs untranslated, and it will > > hit the Global > > space with the same MAPPED address as source address. The > > reply will be > > destined to MAPPED address. If the client receives the reply, > > mapped-address is indeed his. > > > > The server should not be the STUN server (in case somebody > > snoops packets > > destined to the STUN server). It could be the client's > > proxy... or similar. > > > > -Adina > > > > >> In a very limiting deployment scenario, the STUN service > > may be configured > > >> with the possible (expected) IP addresses of all NATs in > > the serving > > >> domain. > > > > > That will certainly help against interception by 3rd > > parties that are on > > > the path between the NAT and the server. It will not help > > in the shared > > > access network scenario, since the attacker and the target > > are behind > > > the same NAT, and thus use the same set of plausible IP addresses. > > > > > -- Christian Huitema > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > > https://www1.ietf.org/mailman/listinfo/midcom > > > --=====================_3823187==_.ALT Content-Type: text/html; charset="us-ascii" At 05:12 PM 5/10/2002 -0500, Sanjoy Sen wrote:

Will the packet be properly routed in the private domain (behind NAT)?

This depends on how the routing is configured -- but, chances are it will be properly routed. BTW same routing is needed in case of 2 clients behind the same NAT wishing to talk to each other:

Inside the local domain, there must be routes configured for the domain's Global addresses pointing to the Global Internet. (it might be a good idea to incorporate this routing config recommendation within the STUN doc).



> -----Original Message-----
> From: Adina Simu [mailto:asimu@cisco.com]
> Sent: Friday, May 10, 2002 5:06 PM
> To: huitema@windows.microsoft.com
> Cc: midcom@ietf.org
> Subject: RE: [midcom] STUN security showstopper
>
>
> (this might have been already proposed and rejected, if this
> is the case I
> apologize)
>
> Once the client receives the STUN response containing a
> MAPPED ADDRESS, one
> way to verify that the address really points (belongs) to him
> is to ping a
> server in the Global space, using as source address the
> MAPPED ADDRESS. The
> ping packet should go through NATs untranslated, and it will
> hit the Global
> space with the same MAPPED address as source address. The
> reply will be
> destined to MAPPED address. If the client receives the reply,
> mapped-address is indeed his.
>
> The server should not be the STUN server (in case somebody
> snoops packets
> destined to the STUN server). It could be the client's
> proxy... or similar.
>
> -Adina
>
>  >> In a very limiting deployment scenario, the STUN service
> may be configured
>  >> with the possible (expected) IP addresses of all NATs in
> the serving
>  >> domain.
>
>  > That will certainly help against interception by 3rd
> parties that are on
>  > the path between the NAT and the server. It will not help
> in the shared
>  > access network scenario, since the attacker and the target
> are behind
>  > the same NAT, and thus use the same set of plausible IP addresses.
>
>  > -- Christian Huitema
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>
--=====================_3823187==_.ALT-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 10 19:15:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22275 for ; Fri, 10 May 2002 19:15:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA20009 for midcom-archive@odin.ietf.org; Fri, 10 May 2002 19:15:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19835; Fri, 10 May 2002 19:10:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19804 for ; Fri, 10 May 2002 19:10:12 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22095 for ; Fri, 10 May 2002 19:10:01 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 16:09:41 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 10 May 2002 16:09:41 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 10 May 2002 16:09:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 10 May 2002 16:09:40 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Fri, 10 May 2002 16:09:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 16:09:43 -0700 Message-ID: Thread-Topic: [midcom] STUN security showstopper thread-index: AcH4bvebW+iYyOzJQZyixusVRxPb2AACJJtA From: "Christian Huitema" To: "Adina Simu" Cc: X-OriginalArrivalTime: 10 May 2002 23:09:40.0621 (UTC) FILETIME=[C36753D0:01C1F877] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA19805 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > Once the client receives the STUN response containing a MAPPED ADDRESS, > one > way to verify that the address really points (belongs) to him is to ping a > server in the Global space, using as source address the MAPPED ADDRESS. > The > ping packet should go through NATs untranslated, and it will hit the > Global > space with the same MAPPED address as source address. The reply will be > destined to MAPPED address. If the client receives the reply, > mapped-address is indeed his. That does not tell you whether there is a man in the middle. If there is a m-i-m, the reply will go to the attacker, which will forward it. > The server should not be the STUN server (in case somebody snoops packets > destined to the STUN server). It could be the client's proxy... or > similar. That will only work if the NAT is not a symmetric NAT, but this is indeed a generic STUN assumption. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat May 11 10:25:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00751 for ; Sat, 11 May 2002 10:25:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27496 for midcom-archive@odin.ietf.org; Sat, 11 May 2002 10:25:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27418; Sat, 11 May 2002 10:18:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24382 for ; Fri, 10 May 2002 21:01:05 -0400 (EDT) Received: from mail.nucleus.com (mail.nucleus.com [207.34.93.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26151 for ; Fri, 10 May 2002 21:00:50 -0400 (EDT) Received: from FLUX (unverified [207.34.112.222]) by mail.nucleus.com (Vircom SMTPRS 1.2.222) with ESMTP id for ; Fri, 10 May 2002 19:00:49 -0600 From: "Alan Hawrylyshen" To: Subject: RE: [midcom] STUN security showstopper Date: Fri, 10 May 2002 19:00:48 -0600 Organization: Jasomi Networks Message-ID: <000901c1f887$49b81a00$1310a8c0@FLUX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4.3.2.7.2.20020510153549.00b07260@mira-sjcm-1.cisco.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit At 05:12 PM 5/10/2002 -0500, Sanjoy Sen wrote: > > >Will the packet be properly routed in the private domain (behind NAT)? > >This depends on how the routing is configured -- but, chances are it will be properly >routed. Not at a site with reasonably strict router or firewall rules. It is not unusual to configure equipment to drop packets that are 'malformed'. A packet claiming to originate from the public address space which appears on the interface of a router / firewall that is in a closed private network will be dropped by many configurations.. Especially in networks configured with the ' deny all , explicitly permit' security policy. I do not think it is safe to count on this. Alan Hawrylyshen Jasomi Networks Inc _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat May 11 20:09:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18629 for ; Sat, 11 May 2002 20:09:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA17065 for midcom-archive@odin.ietf.org; Sat, 11 May 2002 20:09:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16876; Sat, 11 May 2002 20:01:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16847 for ; Sat, 11 May 2002 20:01:51 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18319 for ; Sat, 11 May 2002 20:01:38 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4C01Jkc008363; Sat, 11 May 2002 17:01:19 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACW85549; Sat, 11 May 2002 17:01:31 -0700 (PDT) From: "Cullen Jennings" To: "Christian Huitema" , "Melinda Shore" , Cc: Subject: RE: [midcom] STUN security showstopper Date: Sat, 11 May 2002 17:01:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Christian's attack is great and really helps straighten this stuff out. I think we need to discus the threat as well as solutions to the threat. Let's look at this threat carefully and decided how important it is to solve. It sounds to me like you have an attacker that can perform an attack that is pretty much a man in the middle attack on the traffic between the stun client and server. If it is successful in this attack, then it can perform a man in the middle attack on the traffic that the STUN was negotiating a port for. For sake of a concrete example, call this RTP. 1) Is the real solution to secure RTP against man in the middle attacks? 2) Is this attack against STUN easer than a man in the middle attack against RTP? 3) How possible is it to stop DOS attacks against low end non symmetric NAT devices regardless of it STUN is used or not? Stun is used like a routing protocol. If someone sends me a bad ARP that causes me to send traffic to the wrong place, the solution is to make sure that traffic does not contain information the attacker can use. We don't get to a viable solution by thinking we can control exactly who does or does not see our packets on a IP network or thinking that we can control what the topology of the network is. As Christian has pointed out, this problem may be impossible to solve, however, the questions is still open to if it needs to be solved or not. Cullen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon May 13 15:09:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27061 for ; Mon, 13 May 2002 15:09:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20074 for midcom-archive@odin.ietf.org; Mon, 13 May 2002 15:09:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19766; Mon, 13 May 2002 15:06:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26365 for ; Mon, 13 May 2002 07:34:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03618; Mon, 13 May 2002 07:33:56 -0400 (EDT) Message-Id: <200205131133.HAA03618@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: Mon, 13 May 2002 07:33:56 -0400 Subject: [midcom] I-D ACTION:draft-aoun-midcom-cops-02.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : COPS applicability as the MIDCOM protocol Author(s) : C. Aoun et al. Filename : draft-aoun-midcom-cops-02.txt Pages : 13 Date : 10-May-02 This draft discusses the applicability of the COPS protocol as the MIDCOM protocol, in the context of the current protocol evaluations within the MIDCOM working group. It discusses the architectural similarities between COPS and Midcom and how COPS meets most of the MIDCOM protocol requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aoun-midcom-cops-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-aoun-midcom-cops-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-aoun-midcom-cops-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: <20020510124132.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aoun-midcom-cops-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-aoun-midcom-cops-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020510124132.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon May 13 15:20:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27686 for ; Mon, 13 May 2002 15:20:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20602 for midcom-archive@odin.ietf.org; Mon, 13 May 2002 15:20:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20506; Mon, 13 May 2002 15:18:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28539 for ; Mon, 13 May 2002 08:21:14 -0400 (EDT) Received: from web13403.mail.yahoo.com (web13403.mail.yahoo.com [216.136.175.61]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06059 for ; Mon, 13 May 2002 08:21:01 -0400 (EDT) Message-ID: <20020513122112.92102.qmail@web13403.mail.yahoo.com> Received: from [216.209.239.71] by web13403.mail.yahoo.com via HTTP; Mon, 13 May 2002 05:21:12 PDT Date: Mon, 13 May 2002 05:21:12 -0700 (PDT) From: Tom Gray Subject: RE: [midcom] STUN security showstopper To: midcom@ietf.org, tom_gray_grc@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 03:34 PM 5/10/02 -0400, Tom_Gray@Mitel.COM wrote: >>This is the 'reasonable address' idea that was discussed earlier and which >>was deprecated in favor of cryptographic methods. >Not really. The "reasonable address" suggestion is easily >defeated, unfortunately, and that's why it hasn't been pursued. With the analysis that was provided at the beginning of this thread, a surmise can be made that cryptographic techniques can be defeated trivially. They provide no protection at all against DOS attacks from attacks supplying bogus addresses in requests they hijack and pass onto the server. Something like the 'reasonable address', 'duplicate reply detection'. 'server diversity' ... ideas could be part of a system that supplements the deficiencies in cryptographic solutions. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue May 14 11:20:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23141 for ; Tue, 14 May 2002 11:20:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17126 for midcom-archive@odin.ietf.org; Tue, 14 May 2002 11:20:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16884; Tue, 14 May 2002 11:16:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16845 for ; Tue, 14 May 2002 11:16:08 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22992 for ; Tue, 14 May 2002 11:15:55 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EFFYi20254 for ; Tue, 14 May 2002 17:15:35 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EFEmp07613 for ; Tue, 14 May 2002 16:14:48 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 16:16:23 +0100 Message-ID: From: "Mark Watson" To: midcom@ietf.org Date: Tue, 14 May 2002 16:15:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FB5A.2B996A6C" Subject: [midcom] Symmetric NAT definition Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FB5A.2B996A6C Content-Type: text/plain; charset="iso-8859-1" The definition of Symmetric NAT in the STUN draft states: Symmetric: A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, **a different mapping is used.** Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host. Where it says 'a different mapping is used', does this mean a different external source address/port is used ? It is characteristic of Symmetric NATs that a different source address/port MAY be used, but is it known that this is always the case ? I'm not sure what the rationalle for a NAT designer would be to check that the same source address/port is not already in use for another mapping for the same originating host. If not (i.e. if there is a possibility that a Symmetric NAT may choose a source address/port that happens to be the same as for another mapping for the same originating host), then the test to distinguish between Port Restricted Cone NAT and Symmetric NAT would fail, since it relies on these being different. Regards, Mark ------_=_NextPart_001_01C1FB5A.2B996A6C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Symmetric NAT definition

The definition of Symmetric NAT in the STUN draft = states:

Symmetric: A symmetric NAT is one where all requests = from the
          &nb= sp;  same internal IP address and port, to a specific
          &nb= sp;  destination IP address and port, are mapped to the = same
          &nb= sp;  external IP address and port. If the same host sends a
          &nb= sp;  packet with the same source address and port, but to a
          &nb= sp;  different destination, **a different mapping is = used.**
          &nb= sp;  Furthermore, only the external host that receives a = packet
          &nb= sp;  can send a UDP packet back to the internal host.

Where it says 'a different mapping is used', does = this mean a different external source address/port is used ?

It is characteristic of Symmetric NATs that a = different source address/port MAY be used, but is it known that this is = always the case ? I'm not sure what the rationalle for a NAT designer = would be to check that the same source address/port is not already in = use for another mapping for the same originating host.

If not (i.e. if there is a possibility that a = Symmetric NAT may choose a source address/port that happens to be the = same as for another mapping for the same originating host), then the = test to distinguish between Port Restricted Cone NAT and Symmetric NAT = would fail, since it relies on these being different.

Regards,

Mark

------_=_NextPart_001_01C1FB5A.2B996A6C-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue May 14 13:35:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27647 for ; Tue, 14 May 2002 13:35:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA04722 for midcom-archive@odin.ietf.org; Tue, 14 May 2002 13:35:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04186; Tue, 14 May 2002 13:30:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04131 for ; Tue, 14 May 2002 13:30:12 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27471 for ; Tue, 14 May 2002 13:29:58 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EHTni26586 for ; Tue, 14 May 2002 12:29:49 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 12:30:26 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03A6327C@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "Mark Watson", midcom@ietf.org Subject: RE: [midcom] Symmetric NAT definition Date: Tue, 14 May 2002 12:30:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FB6D.0809EDC0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FB6D.0809EDC0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Watson, Mark [MDN05:EP10:EXCH] Sent: Tuesday, May 14, 2002 10:15 AM To: midcom@ietf.org Subject: [midcom] Symmetric NAT definition The definition of Symmetric NAT in the STUN draft states: Symmetric: A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, **a different mapping is used.** Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host. Where it says 'a different mapping is used', does this mean a different external source address/port is used ? Yes. ------_=_NextPart_001_01C1FB6D.0809EDC0 Content-Type: text/html; charset="iso-8859-1" Symmetric NAT definition
 
-----Original Message-----
From: Watson, Mark [MDN05:EP10:EXCH]
Sent: Tuesday, May 14, 2002 10:15 AM
To: midcom@ietf.org
Subject: [midcom] Symmetric NAT definition

The definition of Symmetric NAT in the STUN draft states:

Symmetric: A symmetric NAT is one where all requests from the
             same internal IP address and port, to a specific
             destination IP address and port, are mapped to the same
             external IP address and port. If the same host sends a
             packet with the same source address and port, but to a
             different destination, **a different mapping is used.**
             Furthermore, only the external host that receives a packet
             can send a UDP packet back to the internal host.

Where it says 'a different mapping is used', does this mean a different external source address/port is used ?  

Yes. 

------_=_NextPart_001_01C1FB6D.0809EDC0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue May 14 15:05:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01095 for ; Tue, 14 May 2002 15:05:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12121 for midcom-archive@odin.ietf.org; Tue, 14 May 2002 15:05:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01787; Tue, 14 May 2002 08:01:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01743 for ; Tue, 14 May 2002 08:01:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14254; Tue, 14 May 2002 08:01:08 -0400 (EDT) Message-Id: <200205141201.IAA14254@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 14 May 2002 08:01:08 -0400 Subject: [midcom] I-D ACTION:draft-renkel-rsip-midcom-eval-01.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Evaluation of RSIP against MIDCOM requirements Author(s) : J. Renkel Filename : draft-renkel-rsip-midcom-eval-01.txt Pages : 12 Date : 13-May-02 This document provides an evaluation of the RSIP (Realm Specific IP) framework and protocol against the evaluation criteria provided by the MIDCOM working group for the evaluation of middle box control protocols. RSIP is defined in experimental RFCs 3102 (Realm Specific IP: Framework) [3] and 3103 (Realm Specific IP: Protocol Specification) [4]; see also RFCs 3104 (RSIP Support for End-to-end IPsec) [5] and 3105 (Finding an RSIP Server with SLP) [6] for more information on RSIP. The document has been updated based on comments made on the MIDCOM mailing list since the previous version of this document was distributed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-renkel-rsip-midcom-eval-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-renkel-rsip-midcom-eval-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-renkel-rsip-midcom-eval-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020513142046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-renkel-rsip-midcom-eval-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-renkel-rsip-midcom-eval-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020513142046.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed May 15 07:42:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26981 for ; Wed, 15 May 2002 07:42:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA07675 for midcom-archive@odin.ietf.org; Wed, 15 May 2002 07:42:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28582; Wed, 15 May 2002 04:53:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28553 for ; Wed, 15 May 2002 04:53:18 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22185 for ; Wed, 15 May 2002 04:53:03 -0400 (EDT) Received: from jku2.fokus.gmd.de (port-213-20-128-68.reverse.qdsl-home.de [213.20.128.68]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g4F8qiW31053 for ; Wed, 15 May 2002 10:52:44 +0200 Message-Id: <5.1.0.14.0.20020515102919.02335118@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 May 2002 10:47:01 +0200 To: From: Jiri Kuthan Subject: RE: [midcom] STUN security showstopper In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org How about the "Is it really you?" technique known from generating email accounts at public servers. After receiving a request, STUN server would send back a verification query "is it really you?" to the address. A STUN client would have to send an ack "yes it is me" with proper credentials. The server would only send a final reply if the verification ack was proper. It adds one more RTT, but mitigates the impersonation attack. -Jiri At 09:08 PM 5/10/2002, Christian Huitema wrote: >I wonder where we go from here. [...] _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed May 15 08:56:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01085 for ; Wed, 15 May 2002 08:56:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA14031 for midcom-archive@odin.ietf.org; Wed, 15 May 2002 08:56:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04013; Wed, 15 May 2002 06:33:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03987 for ; Wed, 15 May 2002 06:33:26 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24530 for ; Wed, 15 May 2002 06:33:12 -0400 (EDT) Received: from jku2.fokus.gmd.de (port-213-20-128-68.reverse.qdsl-home.de [213.20.128.68]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g4FAWsW31908 for ; Wed, 15 May 2002 12:32:54 +0200 Message-Id: <5.1.0.14.0.20020515123144.021a5368@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 May 2002 12:32:48 +0200 To: From: Jiri Kuthan Subject: RE: [midcom] STUN security showstopper In-Reply-To: <5.1.0.14.0.20020515102919.02335118@mailhost.fokus.gmd.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Forget it -- that does not help either, I did not understand the attack scenario previously. -Jiri At 10:47 AM 5/15/2002, midcom@ietf.org wrote: >How about the "Is it really you?" technique known from generating >email accounts at public servers. > >After receiving a request, STUN server would send back a verification >query "is it really you?" to the address. A STUN client would have to send an ack >"yes it is me" with proper credentials. The server would only send >a final reply if the verification ack was proper. > >It adds one more RTT, but mitigates the impersonation attack. > >-Jiri > >At 09:08 PM 5/10/2002, Christian Huitema wrote: >>I wonder where we go from here. >[...] _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 16 08:01:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21423 for ; Thu, 16 May 2002 08:01:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA08047 for midcom-archive@odin.ietf.org; Thu, 16 May 2002 08:02:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07464; Thu, 16 May 2002 07:57:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07434 for ; Thu, 16 May 2002 07:57:50 -0400 (EDT) Received: from web14108.mail.yahoo.com (web14108.mail.yahoo.com [216.136.172.138]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21301 for ; Thu, 16 May 2002 07:57:37 -0400 (EDT) Message-ID: <20020516115750.74092.qmail@web14108.mail.yahoo.com> Received: from [216.191.234.70] by web14108.mail.yahoo.com via HTTP; Thu, 16 May 2002 04:57:50 PDT Date: Thu, 16 May 2002 04:57:50 -0700 (PDT) From: Mark Taylor To: Mark Taylor , "'midcom@ietf.org'" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [midcom] Acceptable Security Solutions Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org The actions of STUN attackers that have been considered in the last few weeks bear a resemblance to the activities of packet sniffers. Packet sniffers are dealt with not in the protocols themselves but by the detection of their specific behaviors as they attempt to accomplish their goals. So, for example, packet sniffers can be detected by identifying who is performing reverse ARPs. Hypothetically the same sort of thing could be done for STUN attackers by, for example, detecting multiple replies, DOS attacks on servers etc. Individual transactions would not be protected but again hypothetically the attacker identity or location in respect to paths to specific STUN servers could be determined and dealt with on ongoing basis. My question is whether this sort of protocol-external security procedure, akin to that done for the similar packet sniffing attackers, would be considered to be a satisfactory solution to the issue of STUN security. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 16 14:15:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04862 for ; Thu, 16 May 2002 14:15:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04146 for midcom-archive@odin.ietf.org; Thu, 16 May 2002 14:16:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03868; Thu, 16 May 2002 14:12:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03837 for ; Thu, 16 May 2002 14:12:38 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04687 for ; Thu, 16 May 2002 14:12:24 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.184]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GIDZYH011290; Thu, 16 May 2002 14:13:35 -0400 (EDT) Message-ID: <3CE3F674.724CC6C7@dynamicsoft.com> Date: Thu, 16 May 2002 14:12:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cullen Jennings CC: Christian Huitema , Melinda Shore , Ted.Hardie@nominum.com, midcom@ietf.org Subject: Re: [midcom] STUN security showstopper References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit This is definitely a difficult threat to address. I agree with Cullen on many points. When you get down to it, the threat is very similar to the threat of a rogue router between you and a server. A rogue router could hijack any UDP traffic I send through it, modifying the source address so that it gets the responses instead of me. I think you will find that protecting against this attack in the face of NAT is exactly the problem we are trying to solve here, and it is a much bigger problem than just STUN. I also think that, on the list of attacks to worry about, a rogue router is the least likely kind of attack you'll see. DoS attacks, fraud, and eavesdropping attacks are much easier to launch, and those are the ones we should focus on. Thus, I would contend that the primary threat we are dealing with is still preventing an eavesdropper from seeing a STUN request fly by, and then sending a faked response back directing traffic towards it. The path we were going down previously - use of a short lived shared secret in a digest-like exchange - appears to protect against this, and I would propose we continue along that direction. Now, with regards to the issue of whether the mechanism for obtaining the shared secret should be orthogonal to STUN or not - I think it is a separate mechanism, but it cannot be decoupled. Christian is right that we cannot permit the usage of long-lived shared secrets because of the threat of off-line dictionary attacks. Therefore, STUN *must* use some kind of mechanism for the establishment of one-time passwords. This could be documented separately, but would be a mandatory dependency of STUN. That is, clients and servers MUST implement this other thing. We could allow for other things down the road too, but we need a baseline mechanism which is mandatory to implement, which provides high quality keying. I fear that just saying "you must use a shared secret with an entropy greater than 64 bits" within STUN is going to be ignored, and people will use low entropy passwords anyway. Thanks, Jonathan R. Cullen Jennings wrote: > > Christian's attack is great and really helps straighten this stuff out. > I > think we need to discus the threat as well as solutions to the threat. > > Let's look at this threat carefully and decided how important it is to > solve. It sounds to me like you have an attacker that can perform an > attack > that is pretty much a man in the middle attack on the traffic between > the > stun client and server. If it is successful in this attack, then it can > perform a man in the middle attack on the traffic that the STUN was > negotiating a port for. For sake of a concrete example, call this RTP. > > 1) Is the real solution to secure RTP against man in the middle attacks? > > 2) Is this attack against STUN easer than a man in the middle attack > against > RTP? > > 3) How possible is it to stop DOS attacks against low end non symmetric > NAT > devices regardless of it STUN is used or not? > > Stun is used like a routing protocol. If someone sends me a bad ARP that > causes me to send traffic to the wrong place, the solution is to make > sure > that traffic does not contain information the attacker can use. We don't > get > to a viable solution by thinking we can control exactly who does or does > not > see our packets on a IP network or thinking that we can control what the > topology of the network is. > > As Christian has pointed out, this problem may be impossible to solve, > however, the questions is still open to if it needs to be solved or not. > > Cullen > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 17 05:13:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06331 for ; Fri, 17 May 2002 05:13:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25365 for midcom-archive@odin.ietf.org; Fri, 17 May 2002 05:13:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25270; Fri, 17 May 2002 05:09:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25238 for ; Fri, 17 May 2002 05:09:51 -0400 (EDT) Received: from web14107.mail.yahoo.com (web14107.mail.yahoo.com [216.136.172.137]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06263 for ; Fri, 17 May 2002 05:09:36 -0400 (EDT) Message-ID: <20020517090947.81543.qmail@web14107.mail.yahoo.com> Received: from [209.226.117.5] by web14107.mail.yahoo.com via HTTP; Fri, 17 May 2002 02:09:47 PDT Date: Fri, 17 May 2002 02:09:47 -0700 (PDT) From: Mark Taylor To: Mark Taylor , "'midcom@ietf.org'" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [midcom] Rogue Routers and Compromised Servers Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Previously someone pointed out that a compromised STUN server could be used to eavesdrop on any connection that was enabled by it. The chair pointed out that this should not be a concern of any security discussion on STUN since this issue was not solvable within the protocol. Yesterday, it was pointed out that the 'Huitema' attack was really an issue of 'rogue routers' and again not solvable within the protocol and so should be excluded from STUN security consideration. However even with the un-solvability of this attack, it was urged that the possibility of an entity seeing STUN requests fly by and sending a false reply to insert itself into the path should remain under consideration. What entity would this be? If compromised STUN servers and rogue routers cannot be handled within the protocol, what entity in the network could be used to mount the false reply attack? How would they differ in principle for security than a router or server? It has been pointed out again previously that if the attacker is on the local LAN, it can use any number of techniques to both eavesdrop and mount DOS attacks outside of the STUN protocol. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun May 19 09:08:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06169 for ; Sun, 19 May 2002 09:08:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06735 for midcom-archive@odin.ietf.org; Sun, 19 May 2002 09:08:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06537; Sun, 19 May 2002 09:03:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17953 for ; Sun, 19 May 2002 01:11:07 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15524; Sun, 19 May 2002 01:10:50 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 179IyH-0003Xt-00; Sun, 19 May 2002 08:11:05 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15591.13289.638221.477909@harjus.eng.song.fi> Date: Sun, 19 May 2002 08:11:05 +0300 To: sipping@ietf.org CC: midcom@ietf.org X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Subject: [midcom] sip client with stun support available Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit we have incorporated Alan Hawrylyshen's stun client into kphone linux sip client: http://www.wirlab.net/kphone/index.html it seems to work fine behind the nats of local dsl providers. -- juha _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed May 22 14:25:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23544 for ; Wed, 22 May 2002 14:25:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13534 for midcom-archive@odin.ietf.org; Wed, 22 May 2002 14:25:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13375; Wed, 22 May 2002 14:22:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13347 for ; Wed, 22 May 2002 14:22:54 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23355 for ; Wed, 22 May 2002 14:22:34 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4MIMqm26554 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 22 May 2002 11:22:53 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4MIMp409374; Wed, 22 May 2002 11:22:51 -0700 (PDT) Subject: RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt To: "Mary Barnes" Cc: midcom@ietf.org Date: Wed, 22 May 2002 13:22:32 -0500 Message-ID: MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=86256BC10064F0DC8f9e8a93df938690918c86256BC10064F0DC" Content-Disposition: inline Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --0__=86256BC10064F0DC8f9e8a93df938690918c86256BC10064F0DC Content-type: text/plain; charset=us-ascii Mary, I am intending to submit two I-Ds before the Yokahama meeting, approxi- mately entitled: 1. NATs, tunnels, and the MIDCOM protocol; and 2. Requirements for supporting middleboxes in session control protocols. At this time, I see no problem with having the first one by 6/14/2002, so that it can be discussed via e-mail and then included as an appendix of the evaluation document. I'll follow with the second one ASAP after the first. Let me know if this is what you're looking for. Or not. Jim "Mary Barnes" on 05/22/2002 12:10:05 PM Sent by: "Mary Barnes" To: James Renkel/MW/US/3Com cc: Subject: RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt Jim, I'm in the middle of pulling the document together for Friday's deadline and was just doing a double-check that all email comments were fully incorporated and realized that I hadn't read your email in detail and I do have some questions wrt to your "null" tunnel-id as it appears you're proposing to have that available by June 21st (which is the Yokohama deadline for -00 drafts). The current timeline for the protocol evaluation draft would be to have the document ready for WGLC by June 28th. I think it would be extremely useful to have this information included as an appendix for the protocol evaluation draft (which is what I'm planning on doing with the appendix which is now in the Megaco draft). Is there anyway you could have that available for discussion by June 14th so that we can have mailing list discussion about including it in the appendix of the protocol evaluation document due out on the 28th? Given the level of interest and discussion these drafts have had on the mailing list, I think this is achievable, but understand you may have other constraints that I haven't considered. We do have some leaway, however, I had really wanted to have a fairly close to final version submitted prior to Yokohama so indeed if anyone had any issues they could be discussed during the session. So, I think that even if you can't get your draft out prior to the 21st, we could still discuss including this in the protocol evaluation document in Yokohama. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, May 10, 2002 2:40 PM To: Joel M. Halpern Cc: midcom@ietf.org Subject: Re: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt Joel, Thank you for your comments on the evaluation of RSIP against the MIDCOM requirements. I did not respond to your comments earlier because I expected more comments and hoped to possibly respond to them all at once. Since yours are the only comments I received, I'll respond to all the comments I received all at once! :-) > My primary observation reading this document is that it would be > helpful if you clearly and early in the document indicated that > your proposal is to change the data handling behavior of te > middlebox. It is NOT my intention to change the data handling behavior of the middlebox. The intention of the I-D was to show how RSIP could be extended to cover middleboxes that are different from what RSIP anti- cipated when it was designed. > If this is not your intent, then significant attention is needed > to how RSIP would work without the currently required tunneling > (you merely say "null tunnel", but there is a lot more to it than > that. Yes and no. When I worked through the design of a "null" tunnel, it fit into RSIP very nicely and allowed RSIP to satisfy the MIDCOM require- ments as stated in the I-D. However, it also exposed a number of issues that I don't think are adequately addressed by the MIDCOM requirements. Maybe they are addressed, but I just don't see them. I could be wrong. Yes, I owe everybody a description of a "null" tunnel, how it would work, how RSIP then satisfies the MIDCOM requirements to the extent claimed in the evaluation I-D. I am preparing that as a separate I-D that also raises the other issues I think I have found. I should have that in a few weeks, hopefully before the cut-off for the Yokahama meeting. > The other issue is that as I understand it RSIP as currently > designed assumes that the requestor and the communicating party > are one and the same. If this is so, and is a behavior you intend > to retain, please say so. If it is a behavior you believe can be > changed, then some description of the complications and degree of > change to RSIP would be helpful. I wouldn't say that "RSIP ... assumes that the requestor and the communi- cating party are one and the same", it's more that it didn't admit to the possiblity that they might not be the same. Subtle, but important, dis- tinction. That said, what happens to RSIP if the application and the agent aren't the same? I guess that depends on your reading of the RSIP specification, as this is now a gray area not addressed by the specification. In check- ing this with some of my colleagues, we have found a way to read the specification that would allow the behavior intended by the MIDCOM requirements. But it's such a weird, obscure, perverse, etc., reading that I wouldn't propose it as "the right thing to do." So, yes, RSIP should be revised to explicitly account and allow for agents as well as applications. This change is really simple: if a client isn't "speaking for itself", then it identifies the client for which it is speaking. All it takes is one (maybe a few) additional parameters in the relevant RSIP messages. Extremely easy to do, with full backward com- patibility, because RSIP was designed to be extensible, in exactly this way! BTW, it was when we were exploring this "agent vs. application" issue that we discovered the other issues I mentioned above. Again, maybe they really aren't issues, or they are issues that have already been addressed, but I'll raise them anyhow in the new I-D. I have revised the evaluation I-D, hopefully addressing the issues you raised. The changes are basically what I described above. Again, thank you for your comments. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom (See attached file: C.htm) --0__=86256BC10064F0DC8f9e8a93df938690918c86256BC10064F0DC Content-type: text/html; name="C.htm" Content-Disposition: attachment; filename="C.htm" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC44OSI+DQo8VElUTEU+UkU6IFtt aWRjb21dIFJlOiBkcmFmdC1yZW5rZWwtcnNpcC1taWRjb20tZXZhbC0wMC50eHQ8L1RJVExFPg0K PC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5KaW0sPC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTI+SSdtIGluIHRoZSBtaWRkbGUgb2YgcHVsbGluZyB0aGUgZG9jdW1lbnQg dG9nZXRoZXIgZm9yIEZyaWRheSdzIGRlYWRsaW5lIGFuZCB3YXMganVzdCBkb2luZyBhIGRvdWJs ZS1jaGVjayB0aGF0IGFsbCBlbWFpbCBjb21tZW50cyB3ZXJlIGZ1bGx5IGluY29ycG9yYXRlZCBh bmQgcmVhbGl6ZWQgdGhhdCBJIGhhZG4ndCByZWFkIHlvdXIgZW1haWwgaW4gZGV0YWlsIGFuZCBJ IGRvIGhhdmUgc29tZSBxdWVzdGlvbnMgd3J0IHRvIHlvdXIgJnF1b3Q7bnVsbCZxdW90OyB0dW5u ZWwtaWQgYXMgaXQgYXBwZWFycyB5b3UncmUgcHJvcG9zaW5nIHRvIGhhdmUgdGhhdCBhdmFpbGFi bGUgYnkgSnVuZSAyMXN0ICh3aGljaCBpcyB0aGUgWW9rb2hhbWEgZGVhZGxpbmUgZm9yIC0wMCBk cmFmdHMpLiZuYnNwOyBUaGUgY3VycmVudCB0aW1lbGluZSBmb3IgdGhlIHByb3RvY29sIGV2YWx1 YXRpb24gZHJhZnQgd291bGQgYmUgdG8gaGF2ZSB0aGUgZG9jdW1lbnQgcmVhZHkgZm9yIFdHTEMg YnkgSnVuZSAyOHRoLiZuYnNwOyBJIHRoaW5rIGl0IHdvdWxkIGJlIGV4dHJlbWVseSB1c2VmdWwg dG8gaGF2ZSB0aGlzIGluZm9ybWF0aW9uIGluY2x1ZGVkIGFzIGFuIGFwcGVuZGl4IGZvciB0aGUg cHJvdG9jb2wgZXZhbHVhdGlvbiBkcmFmdCAod2hpY2ggaXMgd2hhdCBJJ20gcGxhbm5pbmcgb24g ZG9pbmcgd2l0aCB0aGUgYXBwZW5kaXggd2hpY2ggaXMgbm93IGluIHRoZSBNZWdhY28gZHJhZnQp LiZuYnNwOyBJcyB0aGVyZSBhbnl3YXkgeW91IGNvdWxkIGhhdmUgdGhhdCBhdmFpbGFibGUgZm9y IGRpc2N1c3Npb24gYnkgSnVuZSAxNHRoIHNvIHRoYXQgd2UgY2FuIGhhdmUgbWFpbGluZyBsaXN0 IGRpc2N1c3Npb24gYWJvdXQgaW5jbHVkaW5nIGl0IGluIHRoZSBhcHBlbmRpeCBvZiB0aGUgcHJv dG9jb2wgZXZhbHVhdGlvbiBkb2N1bWVudCBkdWUgb3V0IG9uIHRoZSAyOHRoPyZuYnNwOyA8L0ZP TlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+R2l2ZW4gdGhlIGxldmVsIG9mIGludGVyZXN0IGFu ZCBkaXNjdXNzaW9uIHRoZXNlIGRyYWZ0cyBoYXZlIGhhZCBvbiB0aGUgbWFpbGluZyBsaXN0LCBJ IHRoaW5rIHRoaXMgaXMgYWNoaWV2YWJsZSwgYnV0IHVuZGVyc3RhbmQgeW91IG1heSBoYXZlIG90 aGVyIGNvbnN0cmFpbnRzIHRoYXQgSSBoYXZlbid0IGNvbnNpZGVyZWQuJm5ic3A7IFdlIGRvIGhh dmUgc29tZSBsZWF3YXksIGhvd2V2ZXIsIEkgaGFkIHJlYWxseSB3YW50ZWQgdG8gaGF2ZSBhIGZh aXJseSBjbG9zZSB0byBmaW5hbCB2ZXJzaW9uIHN1Ym1pdHRlZCBwcmlvciB0byBZb2tvaGFtYSBz byBpbmRlZWQgaWYgYW55b25lIGhhZCBhbnkgaXNzdWVzIHRoZXkgY291bGQgYmUgZGlzY3Vzc2Vk IGR1cmluZyB0aGUgc2Vzc2lvbi4mbmJzcDsgU28sIEkgdGhpbmsgdGhhdCBldmVuIGlmIHlvdSBj YW4ndCBnZXQgeW91ciBkcmFmdCBvdXQgcHJpb3IgdG8gdGhlIDIxc3QsIHdlIGNvdWxkIHN0aWxs IGRpc2N1c3MgaW5jbHVkaW5nIHRoaXMgaW4gdGhlIHByb3RvY29sIGV2YWx1YXRpb24gZG9jdW1l bnQgaW4gWW9rb2hhbWEuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlJlZ2FyZHMsPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5NYXJ5IEguIEJhcm5lczwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+bWJhcm5lc0Bub3J0ZWxuZXR3b3Jrcy5jb208L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y Pjk3Mi02ODQtNTQzMjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+V2lyZWxlc3MgODE3LTcwMy00 ODA2PC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkZyb206IEphbWVzX1JlbmtlbEAz Y29tLmNvbSBbPEEgSFJFRj0ibWFpbHRvOkphbWVzX1JlbmtlbEAzY29tLmNvbSI+bWFpbHRvOkph bWVzX1JlbmtlbEAzY29tLmNvbTwvQT5dPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TZW50OiBG cmlkYXksIE1heSAxMCwgMjAwMiAyOjQwIFBNPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Ubzog Sm9lbCBNLiBIYWxwZXJuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DYzogbWlkY29tQGlldGYu b3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSZTogW21pZGNvbV0gUmU6IGRy YWZ0LXJlbmtlbC1yc2lwLW1pZGNvbS1ldmFsLTAwLnR4dDwvRk9OVD4NCjwvUD4NCjxCUj4NCjxC Uj4NCg0KPFA+PEZPTlQgU0laRT0yPkpvZWwsPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpF PTI+VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzIG9uIHRoZSBldmFsdWF0aW9uIG9mIFJTSVAg YWdhaW5zdCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPk1JRENPTSByZXF1aXJlbWVudHMu IEkgZGlkIG5vdCByZXNwb25kIHRvIHlvdXIgY29tbWVudHMgZWFybGllcjwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+YmVjYXVzZSBJIGV4cGVjdGVkIG1vcmUgY29tbWVudHMgYW5kIGhvcGVkIHRv IHBvc3NpYmx5IHJlc3BvbmQgdG88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRoZW0gYWxsIGF0 IG9uY2UuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+U2luY2UgeW91cnMgYXJlIHRo ZSBvbmx5IGNvbW1lbnRzIEkgcmVjZWl2ZWQsIEknbGwgcmVzcG9uZCB0byBhbGwgdGhlPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5jb21tZW50cyBJIHJlY2VpdmVkIGFsbCBhdCBvbmNlISA6LSk8 L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE15 IHByaW1hcnkgb2JzZXJ2YXRpb24gcmVhZGluZyB0aGlzIGRvY3VtZW50IGlzIHRoYXQgaXQgd291 bGQgYmU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgaGVs cGZ1bCBpZiB5b3UgY2xlYXJseSBhbmQgZWFybHkgaW4gdGhlIGRvY3VtZW50IGluZGljYXRlZCB0 aGF0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHlvdXIg cHJvcG9zYWwgaXMgdG8gY2hhbmdlIHRoZSBkYXRhIGhhbmRsaW5nIGJlaGF2aW9yIG9mIHRlPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1pZGRsZWJveC48 L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JdCBpcyBOT1QgbXkgaW50ZW50aW9uIHRv IGNoYW5nZSB0aGUgZGF0YSBoYW5kbGluZyBiZWhhdmlvciBvZiB0aGU8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPm1pZGRsZWJveC4gVGhlIGludGVudGlvbiBvZiB0aGUgSS1EIHdhcyB0byBzaG93 IGhvdyBSU0lQIGNvdWxkIGJlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5leHRlbmRlZCB0byBj b3ZlciBtaWRkbGVib3hlcyB0aGF0IGFyZSBkaWZmZXJlbnQgZnJvbSB3aGF0IFJTSVAgYW50aS08 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmNpcGF0ZWQgd2hlbiBpdCB3YXMgZGVzaWduZWQuPC9G T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBJZiB0 aGlzIGlzIG5vdCB5b3VyIGludGVudCwgdGhlbiBzaWduaWZpY2FudCBhdHRlbnRpb24gaXMgbmVl ZGVkPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGhv dyBSU0lQIHdvdWxkIHdvcmsgd2l0aG91dCB0aGUgY3VycmVudGx5IHJlcXVpcmVkIHR1bm5lbGlu ZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAoeW91IG1l cmVseSBzYXkgJnF1b3Q7bnVsbCB0dW5uZWwmcXVvdDssIGJ1dCB0aGVyZSBpcyBhIGxvdCBtb3Jl IHRvIGl0IHRoYW48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsgdGhhdC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5ZZXMgYW5kIG5vLiBXaGVu IEkgd29ya2VkIHRocm91Z2ggdGhlIGRlc2lnbiBvZiBhICZxdW90O251bGwmcXVvdDsgdHVubmVs LCBpdCBmaXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmludG8gUlNJUCB2ZXJ5IG5pY2VseSBh bmQgYWxsb3dlZCBSU0lQIHRvIHNhdGlzZnkgdGhlIE1JRENPTSByZXF1aXJlLTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+bWVudHMgYXMgc3RhdGVkIGluIHRoZSBJLUQuIEhvd2V2ZXIsIGl0IGFs c28gZXhwb3NlZCBhIG51bWJlciBvZiBpc3N1ZXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRo YXQgSSBkb24ndCB0aGluayBhcmUgYWRlcXVhdGVseSBhZGRyZXNzZWQgYnkgdGhlIE1JRENPTSBy ZXF1aXJlbWVudHMuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5NYXliZSB0aGV5IGFyZSBhZGRy ZXNzZWQsIGJ1dCBJIGp1c3QgZG9uJ3Qgc2VlIHRoZW0uIEkgY291bGQgYmUgd3JvbmcuPC9GT05U Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+WWVzLCBJIG93ZSBldmVyeWJvZHkgYSBkZXNjcmlw dGlvbiBvZiBhICZxdW90O251bGwmcXVvdDsgdHVubmVsLCBob3cgaXQgd291bGQ8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPndvcmssIGhvdyBSU0lQIHRoZW4gc2F0aXNmaWVzIHRoZSBNSURDT00g cmVxdWlyZW1lbnRzIHRvIHRoZSBleHRlbnQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmNsYWlt ZWQgaW4gdGhlIGV2YWx1YXRpb24gSS1ELiBJIGFtIHByZXBhcmluZyB0aGF0IGFzIGEgc2VwYXJh dGUgSS1EPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50aGF0IGFsc28gcmFpc2VzIHRoZSBvdGhl ciBpc3N1ZXMgSSB0aGluayBJIGhhdmUgZm91bmQuIEkgc2hvdWxkIGhhdmU8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPnRoYXQgaW4gYSBmZXcgd2Vla3MsIGhvcGVmdWxseSBiZWZvcmUgdGhlIGN1 dC1vZmYgZm9yIHRoZSBZb2thaGFtYTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+bWVldGluZy48 L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSBvdGhlciBpc3N1ZSBpcyB0aGF0IGFzIEkgdW5kZXJzdGFuZCBpdCBSU0lQIGFzIGN1cnJlbnRs eTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNpZ25l ZCBhc3N1bWVzIHRoYXQgdGhlIHJlcXVlc3RvciBhbmQgdGhlIGNvbW11bmljYXRpbmcgcGFydHk8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJlIG9uZSBh bmQgdGhlIHNhbWUuJm5ic3A7IElmIHRoaXMgaXMgc28sIGFuZCBpcyBhIGJlaGF2aW9yIHlvdSBp bnRlbmQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8g cmV0YWluLCBwbGVhc2Ugc2F5IHNvLiZuYnNwOyBJZiBpdCBpcyBhIGJlaGF2aW9yIHlvdSBiZWxp ZXZlIGNhbiBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBjaGFuZ2VkLCB0aGVuIHNvbWUgZGVzY3JpcHRpb24gb2YgdGhlIGNvbXBsaWNhdGlvbnMgYW5k IGRlZ3JlZSBvZjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBjaGFuZ2UgdG8gUlNJUCB3b3VsZCBiZSBoZWxwZnVsLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPkkgd291bGRuJ3Qgc2F5IHRoYXQgJnF1b3Q7UlNJUCAuLi4gYXNzdW1lcyB0aGF0 IHRoZSByZXF1ZXN0b3IgYW5kIHRoZSBjb21tdW5pLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Y2F0aW5nIHBhcnR5IGFyZSBvbmUgYW5kIHRoZSBzYW1lJnF1b3Q7LCBpdCdzIG1vcmUgdGhhdCBp dCBkaWRuJ3QgYWRtaXQgdG8gdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5wb3NzaWJsaXR5 IHRoYXQgdGhleSBtaWdodCBub3QgYmUgdGhlIHNhbWUuIFN1YnRsZSwgYnV0IGltcG9ydGFudCwg ZGlzLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGluY3Rpb24uPC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTI+VGhhdCBzYWlkLCB3aGF0IGhhcHBlbnMgdG8gUlNJUCBpZiB0aGUgYXBw bGljYXRpb24gYW5kIHRoZSBhZ2VudCBhcmVuJ3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRo ZSBzYW1lPyBJIGd1ZXNzIHRoYXQgZGVwZW5kcyBvbiB5b3VyIHJlYWRpbmcgb2YgdGhlIFJTSVAg c3BlY2lmaWNhdGlvbiw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmFzIHRoaXMgaXMgbm93IGEg Z3JheSBhcmVhIG5vdCBhZGRyZXNzZWQgYnkgdGhlIHNwZWNpZmljYXRpb24uIEluIGNoZWNrLTwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+aW5nIHRoaXMgd2l0aCBzb21lIG9mIG15IGNvbGxlYWd1 ZXMsIHdlIGhhdmUgZm91bmQgYSB3YXkgdG8gcmVhZCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPnNwZWNpZmljYXRpb24gdGhhdCB3b3VsZCBhbGxvdyB0aGUgYmVoYXZpb3IgaW50ZW5kZWQg YnkgdGhlIE1JRENPTTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+cmVxdWlyZW1lbnRzLiBCdXQg aXQncyBzdWNoIGEgd2VpcmQsIG9ic2N1cmUsIHBlcnZlcnNlLCBldGMuLCByZWFkaW5nPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj50aGF0IEkgd291bGRuJ3QgcHJvcG9zZSBpdCBhcyAmcXVvdDt0 aGUgcmlnaHQgdGhpbmcgdG8gZG8uJnF1b3Q7PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpF PTI+U28sIHllcywgUlNJUCBzaG91bGQgYmUgcmV2aXNlZCB0byBleHBsaWNpdGx5IGFjY291bnQg YW5kIGFsbG93IGZvcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+YWdlbnRzIGFzIHdlbGwgYXMg YXBwbGljYXRpb25zLiBUaGlzIGNoYW5nZSBpcyByZWFsbHkgc2ltcGxlOiBpZiBhIGNsaWVudDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+aXNuJ3QgJnF1b3Q7c3BlYWtpbmcgZm9yIGl0c2VsZiZx dW90OywgdGhlbiBpdCBpZGVudGlmaWVzIHRoZSBjbGllbnQgZm9yIHdoaWNoIGl0PC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5pcyBzcGVha2luZy4gQWxsIGl0IHRha2VzIGlzIG9uZSAobWF5YmUg YSBmZXcpIGFkZGl0aW9uYWwgcGFyYW1ldGVycyBpbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ dGhlIHJlbGV2YW50IFJTSVAgbWVzc2FnZXMuIEV4dHJlbWVseSBlYXN5IHRvIGRvLCB3aXRoIGZ1 bGwgYmFja3dhcmQgY29tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+cGF0aWJpbGl0eSwgYmVj YXVzZSBSU0lQIHdhcyBkZXNpZ25lZCB0byBiZSBleHRlbnNpYmxlLCBpbiBleGFjdGx5IHRoaXM8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPndheSE8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ WkU9Mj5CVFcsIGl0IHdhcyB3aGVuIHdlIHdlcmUgZXhwbG9yaW5nIHRoaXMgJnF1b3Q7YWdlbnQg dnMuIGFwcGxpY2F0aW9uJnF1b3Q7IGlzc3VlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50aGF0 IHdlIGRpc2NvdmVyZWQgdGhlIG90aGVyIGlzc3VlcyBJIG1lbnRpb25lZCBhYm92ZS4gQWdhaW4s IG1heWJlIHRoZXk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnJlYWxseSBhcmVuJ3QgaXNzdWVz LCBvciB0aGV5IGFyZSBpc3N1ZXMgdGhhdCBoYXZlIGFscmVhZHkgYmVlbiBhZGRyZXNzZWQsPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5idXQgSSdsbCByYWlzZSB0aGVtIGFueWhvdyBpbiB0aGUg bmV3IEktRC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JIGhhdmUgcmV2aXNlZCB0 aGUgZXZhbHVhdGlvbiBJLUQsIGhvcGVmdWxseSBhZGRyZXNzaW5nIHRoZSBpc3N1ZXMgeW91PC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5yYWlzZWQuIFRoZSBjaGFuZ2VzIGFyZSBiYXNpY2FsbHkg d2hhdCBJIGRlc2NyaWJlZCBhYm92ZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5B Z2FpbiwgdGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPkppbTwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0y Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5taWRjb20gbWFpbGluZyBsaXN0PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5taWRjb21AaWV0Zi5vcmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPjxBIEhSRUY9Imh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZGNvbSIgVEFSR0VUPSJfYmxh bmsiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZGNvbTwvQT48L0ZP TlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4= --0__=86256BC10064F0DC8f9e8a93df938690918c86256BC10064F0DC-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Wed May 22 15:16:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26266 for ; Wed, 22 May 2002 15:16:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17202 for midcom-archive@odin.ietf.org; Wed, 22 May 2002 15:16:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16979; Wed, 22 May 2002 15:11:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16883 for ; Wed, 22 May 2002 15:11:20 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26017 for ; Wed, 22 May 2002 15:11:00 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MJAwq26991; Wed, 22 May 2002 14:10:58 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 14:11:06 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE3B44@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" Cc: midcom@ietf.org Subject: RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt Date: Wed, 22 May 2002 14:11:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201C4.6CBE3DE0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C201C4.6CBE3DE0 Content-Type: text/plain; charset="iso-8859-1" Jim, Well, it looks like your objective for the the first draft isn't necessarily specific to describing RSIP as applicable to the MIDCOM protocol, so I don't think it needs to be included as part of the MIDCOM protocol evaluation document. Mary. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Wednesday, May 22, 2002 1:23 PM To: Barnes, Mary [NGC:B601:EXCH] Cc: midcom@ietf.org Subject: RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt Mary, I am intending to submit two I-Ds before the Yokahama meeting, approxi- mately entitled: 1. NATs, tunnels, and the MIDCOM protocol; and 2. Requirements for supporting middleboxes in session control protocols. At this time, I see no problem with having the first one by 6/14/2002, so that it can be discussed via e-mail and then included as an appendix of the evaluation document. I'll follow with the second one ASAP after the first. Let me know if this is what you're looking for. Or not. Jim "Mary Barnes" on 05/22/2002 12:10:05 PM Sent by: "Mary Barnes" To: James Renkel/MW/US/3Com cc: Subject: RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt Jim, I'm in the middle of pulling the document together for Friday's deadline and was just doing a double-check that all email comments were fully incorporated and realized that I hadn't read your email in detail and I do have some questions wrt to your "null" tunnel-id as it appears you're proposing to have that available by June 21st (which is the Yokohama deadline for -00 drafts). The current timeline for the protocol evaluation draft would be to have the document ready for WGLC by June 28th. I think it would be extremely useful to have this information included as an appendix for the protocol evaluation draft (which is what I'm planning on doing with the appendix which is now in the Megaco draft). Is there anyway you could have that available for discussion by June 14th so that we can have mailing list discussion about including it in the appendix of the protocol evaluation document due out on the 28th? Given the level of interest and discussion these drafts have had on the mailing list, I think this is achievable, but understand you may have other constraints that I haven't considered. We do have some leaway, however, I had really wanted to have a fairly close to final version submitted prior to Yokohama so indeed if anyone had any issues they could be discussed during the session. So, I think that even if you can't get your draft out prior to the 21st, we could still discuss including this in the protocol evaluation document in Yokohama. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, May 10, 2002 2:40 PM To: Joel M. Halpern Cc: midcom@ietf.org Subject: Re: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt Joel, Thank you for your comments on the evaluation of RSIP against the MIDCOM requirements. I did not respond to your comments earlier because I expected more comments and hoped to possibly respond to them all at once. Since yours are the only comments I received, I'll respond to all the comments I received all at once! :-) > My primary observation reading this document is that it would be > helpful if you clearly and early in the document indicated that > your proposal is to change the data handling behavior of te > middlebox. It is NOT my intention to change the data handling behavior of the middlebox. The intention of the I-D was to show how RSIP could be extended to cover middleboxes that are different from what RSIP anti- cipated when it was designed. > If this is not your intent, then significant attention is needed > to how RSIP would work without the currently required tunneling > (you merely say "null tunnel", but there is a lot more to it than > that. Yes and no. When I worked through the design of a "null" tunnel, it fit into RSIP very nicely and allowed RSIP to satisfy the MIDCOM require- ments as stated in the I-D. However, it also exposed a number of issues that I don't think are adequately addressed by the MIDCOM requirements. Maybe they are addressed, but I just don't see them. I could be wrong. Yes, I owe everybody a description of a "null" tunnel, how it would work, how RSIP then satisfies the MIDCOM requirements to the extent claimed in the evaluation I-D. I am preparing that as a separate I-D that also raises the other issues I think I have found. I should have that in a few weeks, hopefully before the cut-off for the Yokahama meeting. > The other issue is that as I understand it RSIP as currently > designed assumes that the requestor and the communicating party > are one and the same. If this is so, and is a behavior you intend > to retain, please say so. If it is a behavior you believe can be > changed, then some description of the complications and degree of > change to RSIP would be helpful. I wouldn't say that "RSIP ... assumes that the requestor and the communi- cating party are one and the same", it's more that it didn't admit to the possiblity that they might not be the same. Subtle, but important, dis- tinction. That said, what happens to RSIP if the application and the agent aren't the same? I guess that depends on your reading of the RSIP specification, as this is now a gray area not addressed by the specification. In check- ing this with some of my colleagues, we have found a way to read the specification that would allow the behavior intended by the MIDCOM requirements. But it's such a weird, obscure, perverse, etc., reading that I wouldn't propose it as "the right thing to do." So, yes, RSIP should be revised to explicitly account and allow for agents as well as applications. This change is really simple: if a client isn't "speaking for itself", then it identifies the client for which it is speaking. All it takes is one (maybe a few) additional parameters in the relevant RSIP messages. Extremely easy to do, with full backward com- patibility, because RSIP was designed to be extensible, in exactly this way! BTW, it was when we were exploring this "agent vs. application" issue that we discovered the other issues I mentioned above. Again, maybe they really aren't issues, or they are issues that have already been addressed, but I'll raise them anyhow in the new I-D. I have revised the evaluation I-D, hopefully addressing the issues you raised. The changes are basically what I described above. Again, thank you for your comments. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom (See attached file: C.htm) ------_=_NextPart_001_01C201C4.6CBE3DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt

Jim,

Well, it looks like your objective for the the first = draft isn't necessarily specific to describing RSIP as applicable to = the MIDCOM protocol, so I don't think it needs to be included as part = of the MIDCOM protocol evaluation document.

Mary. 

-----Original Message-----
From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]<= /FONT>
Sent: Wednesday, May 22, 2002 1:23 PM
To: Barnes, Mary [NGC:B601:EXCH]
Cc: midcom@ietf.org
Subject: RE: [midcom] Re: = draft-renkel-rsip-midcom-eval-00.txt



Mary,

I am intending to submit two I-Ds before the Yokahama = meeting, approxi-
mately entitled:
1. NATs, tunnels, and the MIDCOM protocol; = and
2. Requirements for supporting middleboxes in = session control protocols.

At this time, I see no problem with having the first = one by 6/14/2002,
so that it can be discussed via e-mail and then = included as an appendix
of the evaluation document.

I'll follow with the second one ASAP after the = first.

Let me know if this is what you're looking for. Or = not.

Jim






"Mary = Barnes"<mbarnes@nortelnetworks.com> on 05/22/2002 12:10:05 = PM

Sent by:  "Mary = Barnes"<mbarnes@nortelnetworks.com>


To:   James Renkel/MW/US/3Com
cc:
Subject:  RE: [midcom] Re: = draft-renkel-rsip-midcom-eval-00.txt


Jim,

I'm in the middle of pulling the document together = for Friday's deadline
and
was just doing a double-check that all email = comments were fully
incorporated and realized that I hadn't read your = email in detail and I do
have some questions wrt to your "null" = tunnel-id as it appears you're
proposing to have that available by June 21st (which = is the Yokohama
deadline for -00 drafts).  The current timeline = for the protocol evaluation
draft would be to have the document ready for WGLC = by June 28th.  I think
it
would be extremely useful to have this information = included as an appendix
for the protocol evaluation draft (which is what I'm = planning on doing with
the appendix which is now in the Megaco = draft).  Is there anyway you could
have that available for discussion by June 14th so = that we can have mailing
list discussion about including it in the appendix = of the protocol
evaluation document due out on the 28th?

Given the level of interest and discussion these = drafts have had on the
mailing list, I think this is achievable, but = understand you may have other
constraints that I haven't considered.  We do = have some leaway, however, I
had really wanted to have a fairly close to final = version submitted prior
to
Yokohama so indeed if anyone had any issues they = could be discussed during
the session.  So, I think that even if you = can't get your draft out prior
to
the 21st, we could still discuss including this in = the protocol evaluation
document in Yokohama.

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806


-----Original Message-----
From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]<= /FONT>
Sent: Friday, May 10, 2002 2:40 PM
To: Joel M. Halpern
Cc: midcom@ietf.org
Subject: Re: [midcom] Re: = draft-renkel-rsip-midcom-eval-00.txt



Joel,

Thank you for your comments on the evaluation of RSIP = against the
MIDCOM requirements. I did not respond to your = comments earlier
because I expected more comments and hoped to = possibly respond to
them all at once.

Since yours are the only comments I received, I'll = respond to all the
comments I received all at once! :-)

>    My primary observation reading = this document is that it would be
>    helpful if you clearly and = early in the document indicated that
>    your proposal is to change = the data handling behavior of te
>    middlebox.

It is NOT my intention to change the data handling = behavior of the
middlebox. The intention of the I-D was to show how = RSIP could be
extended to cover middleboxes that are different = from what RSIP anti-
cipated when it was designed.

>    If this is not your intent, = then significant attention is needed
>    to how RSIP would work = without the currently required tunneling
>    (you merely say "null = tunnel", but there is a lot more to it than
>    that.

Yes and no. When I worked through the design of a = "null" tunnel, it fit
into RSIP very nicely and allowed RSIP to satisfy = the MIDCOM require-
ments as stated in the I-D. However, it also exposed = a number of issues
that I don't think are adequately addressed by the = MIDCOM requirements.
Maybe they are addressed, but I just don't see them. = I could be wrong.

Yes, I owe everybody a description of a = "null" tunnel, how it would
work, how RSIP then satisfies the MIDCOM = requirements to the extent
claimed in the evaluation I-D. I am preparing that = as a separate I-D
that also raises the other issues I think I have = found. I should have
that in a few weeks, hopefully before the cut-off = for the Yokahama
meeting.

>    The other issue is that as I = understand it RSIP as currently
>    designed assumes that the = requestor and the communicating party
>    are one and the same.  = If this is so, and is a behavior you intend
>    to retain, please say = so.  If it is a behavior you believe can be
>    changed, then some = description of the complications and degree of
>    change to RSIP would be = helpful.

I wouldn't say that "RSIP ... assumes that the = requestor and the communi-
cating party are one and the same", it's more = that it didn't admit to the
possiblity that they might not be the same. Subtle, = but important, dis-
tinction.

That said, what happens to RSIP if the application = and the agent aren't
the same? I guess that depends on your reading of = the RSIP specification,
as this is now a gray area not addressed by the = specification. In check-
ing this with some of my colleagues, we have found a = way to read the
specification that would allow the behavior intended = by the MIDCOM
requirements. But it's such a weird, obscure, = perverse, etc., reading
that I wouldn't propose it as "the right thing = to do."

So, yes, RSIP should be revised to explicitly account = and allow for
agents as well as applications. This change is = really simple: if a client
isn't "speaking for itself", then it = identifies the client for which it
is speaking. All it takes is one (maybe a few) = additional parameters in
the relevant RSIP messages. Extremely easy to do, = with full backward com-
patibility, because RSIP was designed to be = extensible, in exactly this
way!

BTW, it was when we were exploring this "agent = vs. application" issue
that we discovered the other issues I mentioned = above. Again, maybe they
really aren't issues, or they are issues that have = already been addressed,
but I'll raise them anyhow in the new I-D.

I have revised the evaluation I-D, hopefully = addressing the issues you
raised. The changes are basically what I described = above.

Again, thank you for your comments.

Jim



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

(See attached file: C.htm)


------_=_NextPart_001_01C201C4.6CBE3DE0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 23 12:07:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16227 for ; Thu, 23 May 2002 12:07:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01486 for midcom-archive@odin.ietf.org; Thu, 23 May 2002 12:07:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01154; Thu, 23 May 2002 12:03:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01123 for ; Thu, 23 May 2002 12:03:51 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16045 for ; Thu, 23 May 2002 12:03:31 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4NG3oE12619 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 23 May 2002 09:03:51 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4NG3m519584; Thu, 23 May 2002 09:03:48 -0700 (PDT) Subject: RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt To: "Mary Barnes" Cc: midcom@ietf.org Date: Thu, 23 May 2002 11:03:25 -0500 Message-ID: MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=86256BC20058345C8f9e8a93df938690918c86256BC20058345C" Content-Disposition: inline Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --0__=86256BC20058345C8f9e8a93df938690918c86256BC20058345C Content-type: text/plain; charset=us-ascii Mary, I guess I'm looking at the first I-D to do two things: 1. Back up my claim that NAT is "just another type of tunnel" and that, therefore, RSIP is a real serious candidate as the basis for the MIDCOM protocol; and 2. Point out the advantages of middlebox tunnels and suggest that the MIDCOM protocol specifically support them. One might say that, as a result of evaluating RSIP, we missed something in the MIDCOM requirements and that should be fixed. The second I-D will definitely point out some issues that the MIDCOM requirements didn't address, and start addressing those and also require- ments for other protocols (SIP / SDP, FTP, H.323, etc.) that will have to be met in order for applications and agents to be able to deal effectively with middleboxes. Hope this clarifies things. I'll have the first I-D by 6/14 and then we can decide whether or not parts of it need to go into your evaluaiton document. Jim "Mary Barnes" on 05/22/2002 02:11:06 PM Sent by: "Mary Barnes" To: James Renkel/MW/US/3Com cc: midcom@ietf.org Subject: RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt Jim, Well, it looks like your objective for the the first draft isn't necessarily specific to describing RSIP as applicable to the MIDCOM protocol, so I don't think it needs to be included as part of the MIDCOM protocol evaluation document. Mary. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Wednesday, May 22, 2002 1:23 PM To: Barnes, Mary [NGC:B601:EXCH] Cc: midcom@ietf.org Subject: RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt Mary, I am intending to submit two I-Ds before the Yokahama meeting, approxi- mately entitled: 1. NATs, tunnels, and the MIDCOM protocol; and 2. Requirements for supporting middleboxes in session control protocols. At this time, I see no problem with having the first one by 6/14/2002, so that it can be discussed via e-mail and then included as an appendix of the evaluation document. I'll follow with the second one ASAP after the first. Let me know if this is what you're looking for. Or not. Jim "Mary Barnes" on 05/22/2002 12:10:05 PM Sent by: "Mary Barnes" To: James Renkel/MW/US/3Com cc: Subject: RE: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt Jim, I'm in the middle of pulling the document together for Friday's deadline and was just doing a double-check that all email comments were fully incorporated and realized that I hadn't read your email in detail and I do have some questions wrt to your "null" tunnel-id as it appears you're proposing to have that available by June 21st (which is the Yokohama deadline for -00 drafts). The current timeline for the protocol evaluation draft would be to have the document ready for WGLC by June 28th. I think it would be extremely useful to have this information included as an appendix for the protocol evaluation draft (which is what I'm planning on doing with the appendix which is now in the Megaco draft). Is there anyway you could have that available for discussion by June 14th so that we can have mailing list discussion about including it in the appendix of the protocol evaluation document due out on the 28th? Given the level of interest and discussion these drafts have had on the mailing list, I think this is achievable, but understand you may have other constraints that I haven't considered. We do have some leaway, however, I had really wanted to have a fairly close to final version submitted prior to Yokohama so indeed if anyone had any issues they could be discussed during the session. So, I think that even if you can't get your draft out prior to the 21st, we could still discuss including this in the protocol evaluation document in Yokohama. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, May 10, 2002 2:40 PM To: Joel M. Halpern Cc: midcom@ietf.org Subject: Re: [midcom] Re: draft-renkel-rsip-midcom-eval-00.txt Joel, Thank you for your comments on the evaluation of RSIP against the MIDCOM requirements. I did not respond to your comments earlier because I expected more comments and hoped to possibly respond to them all at once. Since yours are the only comments I received, I'll respond to all the comments I received all at once! :-) > My primary observation reading this document is that it would be > helpful if you clearly and early in the document indicated that > your proposal is to change the data handling behavior of te > middlebox. It is NOT my intention to change the data handling behavior of the middlebox. The intention of the I-D was to show how RSIP could be extended to cover middleboxes that are different from what RSIP anti- cipated when it was designed. > If this is not your intent, then significant attention is needed > to how RSIP would work without the currently required tunneling > (you merely say "null tunnel", but there is a lot more to it than > that. Yes and no. When I worked through the design of a "null" tunnel, it fit into RSIP very nicely and allowed RSIP to satisfy the MIDCOM require- ments as stated in the I-D. However, it also exposed a number of issues that I don't think are adequately addressed by the MIDCOM requirements. Maybe they are addressed, but I just don't see them. I could be wrong. Yes, I owe everybody a description of a "null" tunnel, how it would work, how RSIP then satisfies the MIDCOM requirements to the extent claimed in the evaluation I-D. I am preparing that as a separate I-D that also raises the other issues I think I have found. I should have that in a few weeks, hopefully before the cut-off for the Yokahama meeting. > The other issue is that as I understand it RSIP as currently > designed assumes that the requestor and the communicating party > are one and the same. If this is so, and is a behavior you intend > to retain, please say so. If it is a behavior you believe can be > changed, then some description of the complications and degree of > change to RSIP would be helpful. I wouldn't say that "RSIP ... assumes that the requestor and the communi- cating party are one and the same", it's more that it didn't admit to the possiblity that they might not be the same. Subtle, but important, dis- tinction. That said, what happens to RSIP if the application and the agent aren't the same? I guess that depends on your reading of the RSIP specification, as this is now a gray area not addressed by the specification. In check- ing this with some of my colleagues, we have found a way to read the specification that would allow the behavior intended by the MIDCOM requirements. But it's such a weird, obscure, perverse, etc., reading that I wouldn't propose it as "the right thing to do." So, yes, RSIP should be revised to explicitly account and allow for agents as well as applications. This change is really simple: if a client isn't "speaking for itself", then it identifies the client for which it is speaking. All it takes is one (maybe a few) additional parameters in the relevant RSIP messages. Extremely easy to do, with full backward com- patibility, because RSIP was designed to be extensible, in exactly this way! BTW, it was when we were exploring this "agent vs. application" issue that we discovered the other issues I mentioned above. Again, maybe they really aren't issues, or they are issues that have already been addressed, but I'll raise them anyhow in the new I-D. I have revised the evaluation I-D, hopefully addressing the issues you raised. The changes are basically what I described above. Again, thank you for your comments. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom (See attached file: C.htm) (See attached file: C.htm) --0__=86256BC20058345C8f9e8a93df938690918c86256BC20058345C Content-type: text/html; name="C.htm" Content-Disposition: attachment; filename="C.htm" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC44OSI+DQo8VElUTEU+UkU6IFtt aWRjb21dIFJlOiBkcmFmdC1yZW5rZWwtcnNpcC1taWRjb20tZXZhbC0wMC50eHQ8L1RJVExFPg0K PC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5KaW0sPC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTI+V2VsbCwgaXQgbG9va3MgbGlrZSB5b3VyIG9iamVjdGl2ZSBmb3IgdGhl IHRoZSBmaXJzdCBkcmFmdCBpc24ndCBuZWNlc3NhcmlseSBzcGVjaWZpYyB0byBkZXNjcmliaW5n IFJTSVAgYXMgYXBwbGljYWJsZSB0byB0aGUgTUlEQ09NIHByb3RvY29sLCBzbyBJIGRvbid0IHRo aW5rIGl0IG5lZWRzIHRvIGJlIGluY2x1ZGVkIGFzIHBhcnQgb2YgdGhlIE1JRENPTSBwcm90b2Nv bCBldmFsdWF0aW9uIGRvY3VtZW50LiA8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+TWFy eS4mbmJzcDsgPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkZyb206IEphbWVzX1JlbmtlbEAz Y29tLmNvbSBbPEEgSFJFRj0ibWFpbHRvOkphbWVzX1JlbmtlbEAzY29tLmNvbSI+bWFpbHRvOkph bWVzX1JlbmtlbEAzY29tLmNvbTwvQT5dPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TZW50OiBX ZWRuZXNkYXksIE1heSAyMiwgMjAwMiAxOjIzIFBNPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5U bzogQmFybmVzLCBNYXJ5IFtOR0M6QjYwMTpFWENIXTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Q2M6IG1pZGNvbUBpZXRmLm9yZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U3ViamVjdDogUkU6 IFttaWRjb21dIFJlOiBkcmFmdC1yZW5rZWwtcnNpcC1taWRjb20tZXZhbC0wMC50eHQ8L0ZPTlQ+ DQo8L1A+DQo8QlI+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5NYXJ5LDwvRk9OVD4NCjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yPkkgYW0gaW50ZW5kaW5nIHRvIHN1Ym1pdCB0d28gSS1EcyBiZWZv cmUgdGhlIFlva2FoYW1hIG1lZXRpbmcsIGFwcHJveGktPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj5tYXRlbHkgZW50aXRsZWQ6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4xLiBOQVRzLCB0dW5u ZWxzLCBhbmQgdGhlIE1JRENPTSBwcm90b2NvbDsgYW5kPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4yLiBSZXF1aXJlbWVudHMgZm9yIHN1cHBvcnRpbmcgbWlkZGxlYm94ZXMgaW4gc2Vzc2lvbiBj b250cm9sIHByb3RvY29scy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5BdCB0aGlz IHRpbWUsIEkgc2VlIG5vIHByb2JsZW0gd2l0aCBoYXZpbmcgdGhlIGZpcnN0IG9uZSBieSA2LzE0 LzIwMDIsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5zbyB0aGF0IGl0IGNhbiBiZSBkaXNjdXNz ZWQgdmlhIGUtbWFpbCBhbmQgdGhlbiBpbmNsdWRlZCBhcyBhbiBhcHBlbmRpeDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+b2YgdGhlIGV2YWx1YXRpb24gZG9jdW1lbnQuPC9GT05UPg0KPC9QPg0K DQo8UD48Rk9OVCBTSVpFPTI+SSdsbCBmb2xsb3cgd2l0aCB0aGUgc2Vjb25kIG9uZSBBU0FQIGFm dGVyIHRoZSBmaXJzdC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5MZXQgbWUga25v dyBpZiB0aGlzIGlzIHdoYXQgeW91J3JlIGxvb2tpbmcgZm9yLiBPciBub3QuPC9GT05UPg0KPC9Q Pg0KDQo8UD48Rk9OVCBTSVpFPTI+SmltPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0K PEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+JnF1b3Q7TWFyeSBCYXJuZXMmcXVvdDsmbHQ7 bWJhcm5lc0Bub3J0ZWxuZXR3b3Jrcy5jb20mZ3Q7IG9uIDA1LzIyLzIwMDIgMTI6MTA6MDUgUE08 L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiZuYnNwOyAmcXVvdDtNYXJ5 IEJhcm5lcyZxdW90OyZsdDttYmFybmVzQG5vcnRlbG5ldHdvcmtzLmNvbSZndDs8L0ZPTlQ+DQo8 L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5UbzombmJzcDsmbmJzcDsgSmFtZXMgUmVua2Vs L01XL1VTLzNDb208L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmNjOjwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+U3ViamVjdDombmJzcDsgUkU6IFttaWRjb21dIFJlOiBkcmFmdC1yZW5rZWwtcnNp cC1taWRjb20tZXZhbC0wMC50eHQ8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9 Mj5KaW0sPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SSdtIGluIHRoZSBtaWRkbGUg b2YgcHVsbGluZyB0aGUgZG9jdW1lbnQgdG9nZXRoZXIgZm9yIEZyaWRheSdzIGRlYWRsaW5lPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5hbmQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPndhcyBq dXN0IGRvaW5nIGEgZG91YmxlLWNoZWNrIHRoYXQgYWxsIGVtYWlsIGNvbW1lbnRzIHdlcmUgZnVs bHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmluY29ycG9yYXRlZCBhbmQgcmVhbGl6ZWQgdGhh dCBJIGhhZG4ndCByZWFkIHlvdXIgZW1haWwgaW4gZGV0YWlsIGFuZCBJIGRvPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj5oYXZlIHNvbWUgcXVlc3Rpb25zIHdydCB0byB5b3VyICZxdW90O251bGwm cXVvdDsgdHVubmVsLWlkIGFzIGl0IGFwcGVhcnMgeW91J3JlPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5wcm9wb3NpbmcgdG8gaGF2ZSB0aGF0IGF2YWlsYWJsZSBieSBKdW5lIDIxc3QgKHdoaWNo IGlzIHRoZSBZb2tvaGFtYTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ZGVhZGxpbmUgZm9yIC0w MCBkcmFmdHMpLiZuYnNwOyBUaGUgY3VycmVudCB0aW1lbGluZSBmb3IgdGhlIHByb3RvY29sIGV2 YWx1YXRpb248L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmRyYWZ0IHdvdWxkIGJlIHRvIGhhdmUg dGhlIGRvY3VtZW50IHJlYWR5IGZvciBXR0xDIGJ5IEp1bmUgMjh0aC4mbmJzcDsgSSB0aGluazwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+aXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPndvdWxk IGJlIGV4dHJlbWVseSB1c2VmdWwgdG8gaGF2ZSB0aGlzIGluZm9ybWF0aW9uIGluY2x1ZGVkIGFz IGFuIGFwcGVuZGl4PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5mb3IgdGhlIHByb3RvY29sIGV2 YWx1YXRpb24gZHJhZnQgKHdoaWNoIGlzIHdoYXQgSSdtIHBsYW5uaW5nIG9uIGRvaW5nIHdpdGg8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRoZSBhcHBlbmRpeCB3aGljaCBpcyBub3cgaW4gdGhl IE1lZ2FjbyBkcmFmdCkuJm5ic3A7IElzIHRoZXJlIGFueXdheSB5b3UgY291bGQ8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPmhhdmUgdGhhdCBhdmFpbGFibGUgZm9yIGRpc2N1c3Npb24gYnkgSnVu ZSAxNHRoIHNvIHRoYXQgd2UgY2FuIGhhdmUgbWFpbGluZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+bGlzdCBkaXNjdXNzaW9uIGFib3V0IGluY2x1ZGluZyBpdCBpbiB0aGUgYXBwZW5kaXggb2Yg dGhlIHByb3RvY29sPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5ldmFsdWF0aW9uIGRvY3VtZW50 IGR1ZSBvdXQgb24gdGhlIDI4dGg/PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+R2l2 ZW4gdGhlIGxldmVsIG9mIGludGVyZXN0IGFuZCBkaXNjdXNzaW9uIHRoZXNlIGRyYWZ0cyBoYXZl IGhhZCBvbiB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPm1haWxpbmcgbGlzdCwgSSB0aGlu ayB0aGlzIGlzIGFjaGlldmFibGUsIGJ1dCB1bmRlcnN0YW5kIHlvdSBtYXkgaGF2ZSBvdGhlcjwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Y29uc3RyYWludHMgdGhhdCBJIGhhdmVuJ3QgY29uc2lk ZXJlZC4mbmJzcDsgV2UgZG8gaGF2ZSBzb21lIGxlYXdheSwgaG93ZXZlciwgSTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+aGFkIHJlYWxseSB3YW50ZWQgdG8gaGF2ZSBhIGZhaXJseSBjbG9zZSB0 byBmaW5hbCB2ZXJzaW9uIHN1Ym1pdHRlZCBwcmlvcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ dG88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPllva29oYW1hIHNvIGluZGVlZCBpZiBhbnlvbmUg aGFkIGFueSBpc3N1ZXMgdGhleSBjb3VsZCBiZSBkaXNjdXNzZWQgZHVyaW5nPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj50aGUgc2Vzc2lvbi4mbmJzcDsgU28sIEkgdGhpbmsgdGhhdCBldmVuIGlm IHlvdSBjYW4ndCBnZXQgeW91ciBkcmFmdCBvdXQgcHJpb3I8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPnRvPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50aGUgMjFzdCwgd2UgY291bGQgc3RpbGwg ZGlzY3VzcyBpbmNsdWRpbmcgdGhpcyBpbiB0aGUgcHJvdG9jb2wgZXZhbHVhdGlvbjwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+ZG9jdW1lbnQgaW4gWW9rb2hhbWEuPC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTI+UmVnYXJkcyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPk1hcnkgSC4g QmFybmVzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5tYmFybmVzQG5vcnRlbG5ldHdvcmtzLmNv bTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+OTcyLTY4NC01NDMyPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj5XaXJlbGVzcyA4MTctNzAzLTQ4MDY8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxG T05UIFNJWkU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+RnJvbTogSmFtZXNfUmVua2VsQDNjb20uY29tIFs8QSBIUkVGPSJtYWlsdG86SmFtZXNf UmVua2VsQDNjb20uY29tIj5tYWlsdG86SmFtZXNfUmVua2VsQDNjb20uY29tPC9BPl08L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPlNlbnQ6IEZyaWRheSwgTWF5IDEwLCAyMDAyIDI6NDAgUE08L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBKb2VsIE0uIEhhbHBlcm48L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPkNjOiBtaWRjb21AaWV0Zi5vcmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlN1 YmplY3Q6IFJlOiBbbWlkY29tXSBSZTogZHJhZnQtcmVua2VsLXJzaXAtbWlkY29tLWV2YWwtMDAu dHh0PC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+Sm9lbCw8L0ZP TlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMg b24gdGhlIGV2YWx1YXRpb24gb2YgUlNJUCBhZ2FpbnN0IHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+TUlEQ09NIHJlcXVpcmVtZW50cy4gSSBkaWQgbm90IHJlc3BvbmQgdG8geW91ciBjb21t ZW50cyBlYXJsaWVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5iZWNhdXNlIEkgZXhwZWN0ZWQg bW9yZSBjb21tZW50cyBhbmQgaG9wZWQgdG8gcG9zc2libHkgcmVzcG9uZCB0bzwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+dGhlbSBhbGwgYXQgb25jZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U IFNJWkU9Mj5TaW5jZSB5b3VycyBhcmUgdGhlIG9ubHkgY29tbWVudHMgSSByZWNlaXZlZCwgSSds bCByZXNwb25kIHRvIGFsbCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmNvbW1lbnRzIEkg cmVjZWl2ZWQgYWxsIGF0IG9uY2UhIDotKTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTXkgcHJpbWFyeSBvYnNlcnZhdGlvbiByZWFkaW5nIHRo aXMgZG9jdW1lbnQgaXMgdGhhdCBpdCB3b3VsZCBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBoZWxwZnVsIGlmIHlvdSBjbGVhcmx5IGFuZCBlYXJseSBp biB0aGUgZG9jdW1lbnQgaW5kaWNhdGVkIHRoYXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgeW91ciBwcm9wb3NhbCBpcyB0byBjaGFuZ2UgdGhlIGRhdGEg aGFuZGxpbmcgYmVoYXZpb3Igb2YgdGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsgbWlkZGxlYm94LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y Pkl0IGlzIE5PVCBteSBpbnRlbnRpb24gdG8gY2hhbmdlIHRoZSBkYXRhIGhhbmRsaW5nIGJlaGF2 aW9yIG9mIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+bWlkZGxlYm94LiBUaGUgaW50ZW50 aW9uIG9mIHRoZSBJLUQgd2FzIHRvIHNob3cgaG93IFJTSVAgY291bGQgYmU8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPmV4dGVuZGVkIHRvIGNvdmVyIG1pZGRsZWJveGVzIHRoYXQgYXJlIGRpZmZl cmVudCBmcm9tIHdoYXQgUlNJUCBhbnRpLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Y2lwYXRl ZCB3aGVuIGl0IHdhcyBkZXNpZ25lZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHRoaXMgaXMgbm90IHlvdXIgaW50ZW50LCB0aGVuIHNp Z25pZmljYW50IGF0dGVudGlvbiBpcyBuZWVkZWQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gaG93IFJTSVAgd291bGQgd29yayB3aXRob3V0IHRoZSBj dXJyZW50bHkgcmVxdWlyZWQgdHVubmVsaW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICh5b3UgbWVyZWx5IHNheSAmcXVvdDtudWxsIHR1bm5lbCZxdW90 OywgYnV0IHRoZXJlIGlzIGEgbG90IG1vcmUgdG8gaXQgdGhhbjwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPlllcyBhbmQgbm8uIFdoZW4gSSB3b3JrZWQgdGhyb3VnaCB0aGUgZGVzaWduIG9m IGEgJnF1b3Q7bnVsbCZxdW90OyB0dW5uZWwsIGl0IGZpdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+aW50byBSU0lQIHZlcnkgbmljZWx5IGFuZCBhbGxvd2VkIFJTSVAgdG8gc2F0aXNmeSB0aGUg TUlEQ09NIHJlcXVpcmUtPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5tZW50cyBhcyBzdGF0ZWQg aW4gdGhlIEktRC4gSG93ZXZlciwgaXQgYWxzbyBleHBvc2VkIGEgbnVtYmVyIG9mIGlzc3Vlczwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhhdCBJIGRvbid0IHRoaW5rIGFyZSBhZGVxdWF0ZWx5 IGFkZHJlc3NlZCBieSB0aGUgTUlEQ09NIHJlcXVpcmVtZW50cy48L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPk1heWJlIHRoZXkgYXJlIGFkZHJlc3NlZCwgYnV0IEkganVzdCBkb24ndCBzZWUgdGhl bS4gSSBjb3VsZCBiZSB3cm9uZy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5ZZXMs IEkgb3dlIGV2ZXJ5Ym9keSBhIGRlc2NyaXB0aW9uIG9mIGEgJnF1b3Q7bnVsbCZxdW90OyB0dW5u ZWwsIGhvdyBpdCB3b3VsZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+d29yaywgaG93IFJTSVAg dGhlbiBzYXRpc2ZpZXMgdGhlIE1JRENPTSByZXF1aXJlbWVudHMgdG8gdGhlIGV4dGVudDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Y2xhaW1lZCBpbiB0aGUgZXZhbHVhdGlvbiBJLUQuIEkgYW0g cHJlcGFyaW5nIHRoYXQgYXMgYSBzZXBhcmF0ZSBJLUQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PnRoYXQgYWxzbyByYWlzZXMgdGhlIG90aGVyIGlzc3VlcyBJIHRoaW5rIEkgaGF2ZSBmb3VuZC4g SSBzaG91bGQgaGF2ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhhdCBpbiBhIGZldyB3ZWVr cywgaG9wZWZ1bGx5IGJlZm9yZSB0aGUgY3V0LW9mZiBmb3IgdGhlIFlva2FoYW1hPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5tZWV0aW5nLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIG90aGVyIGlzc3VlIGlzIHRoYXQgYXMgSSB1bmRl cnN0YW5kIGl0IFJTSVAgYXMgY3VycmVudGx5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2lnbmVkIGFzc3VtZXMgdGhhdCB0aGUgcmVxdWVzdG9yIGFu ZCB0aGUgY29tbXVuaWNhdGluZyBwYXJ0eTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBhcmUgb25lIGFuZCB0aGUgc2FtZS4mbmJzcDsgSWYgdGhpcyBpcyBz bywgYW5kIGlzIGEgYmVoYXZpb3IgeW91IGludGVuZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0byByZXRhaW4sIHBsZWFzZSBzYXkgc28uJm5ic3A7IElm IGl0IGlzIGEgYmVoYXZpb3IgeW91IGJlbGlldmUgY2FuIGJlPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNoYW5nZWQsIHRoZW4gc29tZSBkZXNjcmlwdGlv biBvZiB0aGUgY29tcGxpY2F0aW9ucyBhbmQgZGVncmVlIG9mPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNoYW5nZSB0byBSU0lQIHdvdWxkIGJlIGhlbHBm dWwuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SSB3b3VsZG4ndCBzYXkgdGhhdCAm cXVvdDtSU0lQIC4uLiBhc3N1bWVzIHRoYXQgdGhlIHJlcXVlc3RvciBhbmQgdGhlIGNvbW11bmkt PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5jYXRpbmcgcGFydHkgYXJlIG9uZSBhbmQgdGhlIHNh bWUmcXVvdDssIGl0J3MgbW9yZSB0aGF0IGl0IGRpZG4ndCBhZG1pdCB0byB0aGU8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPnBvc3NpYmxpdHkgdGhhdCB0aGV5IG1pZ2h0IG5vdCBiZSB0aGUgc2Ft ZS4gU3VidGxlLCBidXQgaW1wb3J0YW50LCBkaXMtPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50 aW5jdGlvbi48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGF0IHNhaWQsIHdoYXQg aGFwcGVucyB0byBSU0lQIGlmIHRoZSBhcHBsaWNhdGlvbiBhbmQgdGhlIGFnZW50IGFyZW4ndDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlIHNhbWU/IEkgZ3Vlc3MgdGhhdCBkZXBlbmRzIG9u IHlvdXIgcmVhZGluZyBvZiB0aGUgUlNJUCBzcGVjaWZpY2F0aW9uLDwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+YXMgdGhpcyBpcyBub3cgYSBncmF5IGFyZWEgbm90IGFkZHJlc3NlZCBieSB0aGUg c3BlY2lmaWNhdGlvbi4gSW4gY2hlY2stPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5pbmcgdGhp cyB3aXRoIHNvbWUgb2YgbXkgY29sbGVhZ3Vlcywgd2UgaGF2ZSBmb3VuZCBhIHdheSB0byByZWFk IHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+c3BlY2lmaWNhdGlvbiB0aGF0IHdvdWxkIGFs bG93IHRoZSBiZWhhdmlvciBpbnRlbmRlZCBieSB0aGUgTUlEQ09NPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj5yZXF1aXJlbWVudHMuIEJ1dCBpdCdzIHN1Y2ggYSB3ZWlyZCwgb2JzY3VyZSwgcGVy dmVyc2UsIGV0Yy4sIHJlYWRpbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRoYXQgSSB3b3Vs ZG4ndCBwcm9wb3NlIGl0IGFzICZxdW90O3RoZSByaWdodCB0aGluZyB0byBkby4mcXVvdDs8L0ZP TlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5TbywgeWVzLCBSU0lQIHNob3VsZCBiZSByZXZp c2VkIHRvIGV4cGxpY2l0bHkgYWNjb3VudCBhbmQgYWxsb3cgZm9yPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj5hZ2VudHMgYXMgd2VsbCBhcyBhcHBsaWNhdGlvbnMuIFRoaXMgY2hhbmdlIGlzIHJl YWxseSBzaW1wbGU6IGlmIGEgY2xpZW50PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5pc24ndCAm cXVvdDtzcGVha2luZyBmb3IgaXRzZWxmJnF1b3Q7LCB0aGVuIGl0IGlkZW50aWZpZXMgdGhlIGNs aWVudCBmb3Igd2hpY2ggaXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmlzIHNwZWFraW5nLiBB bGwgaXQgdGFrZXMgaXMgb25lIChtYXliZSBhIGZldykgYWRkaXRpb25hbCBwYXJhbWV0ZXJzIGlu PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50aGUgcmVsZXZhbnQgUlNJUCBtZXNzYWdlcy4gRXh0 cmVtZWx5IGVhc3kgdG8gZG8sIHdpdGggZnVsbCBiYWNrd2FyZCBjb20tPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj5wYXRpYmlsaXR5LCBiZWNhdXNlIFJTSVAgd2FzIGRlc2lnbmVkIHRvIGJlIGV4 dGVuc2libGUsIGluIGV4YWN0bHkgdGhpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+d2F5ITwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkJUVywgaXQgd2FzIHdoZW4gd2Ugd2VyZSBl eHBsb3JpbmcgdGhpcyAmcXVvdDthZ2VudCB2cy4gYXBwbGljYXRpb24mcXVvdDsgaXNzdWU8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRoYXQgd2UgZGlzY292ZXJlZCB0aGUgb3RoZXIgaXNzdWVz IEkgbWVudGlvbmVkIGFib3ZlLiBBZ2FpbiwgbWF5YmUgdGhleTwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+cmVhbGx5IGFyZW4ndCBpc3N1ZXMsIG9yIHRoZXkgYXJlIGlzc3VlcyB0aGF0IGhhdmUg YWxyZWFkeSBiZWVuIGFkZHJlc3NlZCw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmJ1dCBJJ2xs IHJhaXNlIHRoZW0gYW55aG93IGluIHRoZSBuZXcgSS1ELjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPkkgaGF2ZSByZXZpc2VkIHRoZSBldmFsdWF0aW9uIEktRCwgaG9wZWZ1bGx5IGFk ZHJlc3NpbmcgdGhlIGlzc3VlcyB5b3U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnJhaXNlZC4g VGhlIGNoYW5nZXMgYXJlIGJhc2ljYWxseSB3aGF0IEkgZGVzY3JpYmVkIGFib3ZlLjwvRk9OVD4N CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkFnYWluLCB0aGFuayB5b3UgZm9yIHlvdXIgY29tbWVu dHMuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SmltPC9GT05UPg0KPC9QPg0KPEJS Pg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPm1pZGNvbSBtYWlsaW5n IGxpc3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPm1pZGNvbUBpZXRmLm9yZzwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+PEEgSFJFRj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWlkY29tIiBUQVJHRVQ9Il9ibGFuayI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWlkY29tPC9BPjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPihT ZWUgYXR0YWNoZWQgZmlsZTogQy5odG0pPC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8L0JPRFk+DQo8 L0hUTUw+ --0__=86256BC20058345C8f9e8a93df938690918c86256BC20058345C-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 24 10:28:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00032 for ; Fri, 24 May 2002 10:28:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13349 for midcom-archive@odin.ietf.org; Fri, 24 May 2002 10:28:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13079; Fri, 24 May 2002 10:25:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13048 for ; Fri, 24 May 2002 10:25:50 -0400 (EDT) Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.148.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29945 for ; Fri, 24 May 2002 10:25:30 -0400 (EDT) Received: from 161.58.69.250 (161.58.69.250) by mail14.verio-web.com (RS ver 1.0.63s) with SMTP id 017986702 for ; Fri, 24 May 2002 10:29:45 -0400 (EDT) Reply-To: From: "Thomas Huang" To: Date: Fri, 24 May 2002 09:22:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Loop-Detect: 1 Content-Transfer-Encoding: 7bit Subject: [midcom] Midcom protocol specification and status Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I have studied the three major doc in the repository: - Midcom architecture and framework - Midcom requirement - STUN But I can't find the MidCom protocol specification itself. Could you please help? - any draft spec that this group is working on - what's the concensus among the group and other related groups about midcom (SIP, MGCP, MEGACO) - Are there vendors starting to develop midcom boxes following the architecture? I am in the process of meeting a couple of vendors, but they don't say in literature what they follow. If yes, who are leading the pack? Thanks for any help. Thomas _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 24 10:46:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00553 for ; Fri, 24 May 2002 10:46:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14639 for midcom-archive@odin.ietf.org; Fri, 24 May 2002 10:46:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14603; Fri, 24 May 2002 10:44:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14576 for ; Fri, 24 May 2002 10:44:37 -0400 (EDT) Received: from linux.aravox.com (linux.aravox.com [209.46.41.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00528 for ; Fri, 24 May 2002 10:44:16 -0400 (EDT) Received: from MPIETRAS (IDENT:root@linux.aravox.com [209.46.41.66] (may be forged)) by linux.aravox.com (8.9.3/8.9.3) with ESMTP id JAA27193; Fri, 24 May 2002 09:42:14 -0500 From: "Mark Pietras" To: , Subject: RE: [midcom] Midcom protocol specification and status Date: Fri, 24 May 2002 09:41:34 -0500 Message-ID: <002201c20331$1a4fe680$4c01a8c0@MPIETRAS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Thomas, - There is no protocol specification at this point. The work is in progress. Currently the working group is doing two things: 1) working the STUN portion of the current charter which addresses short-term needs and a specific market, and 2) working the protocol portion of the current charter by evaluating several different protocol proposals against the framework/requirements docs as candidates for the actual Midcom protocol. - There are several vendors developing "Midcom boxes" currently. Some even have some in production networks. They generally follow the Midcom architecture, but currently use different protocols for policy control as there is no standard yet. Hence the current charter of this working group. Most of the vendors actively work in or at least follow this group, so I'm sure each would suggest they "lead the pack." Mark. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Thomas Huang Sent: Friday, May 24, 2002 11:23 AM To: midcom@ietf.org Subject: [midcom] Midcom protocol specification and status I have studied the three major doc in the repository: - Midcom architecture and framework - Midcom requirement - STUN But I can't find the MidCom protocol specification itself. Could you please help? - any draft spec that this group is working on - what's the concensus among the group and other related groups about midcom (SIP, MGCP, MEGACO) - Are there vendors starting to develop midcom boxes following the architecture? I am in the process of meeting a couple of vendors, but they don't say in literature what they follow. If yes, who are leading the pack? Thanks for any help. Thomas _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 24 11:26:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02288 for ; Fri, 24 May 2002 11:26:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17040 for midcom-archive@odin.ietf.org; Fri, 24 May 2002 11:26:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16892; Fri, 24 May 2002 11:24:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16799 for ; Fri, 24 May 2002 11:24:22 -0400 (EDT) Received: from mail-fwd.verio-web.com (mail11b.verio-web.com [161.58.148.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02170 for ; Fri, 24 May 2002 11:24:02 -0400 (EDT) Received: from 161.58.69.250 (161.58.69.250) by mail11b.verio-web.com (RS ver 1.0.63s) with SMTP id 015219675; Fri, 24 May 2002 11:23:25 -0400 (EDT) Reply-To: From: "Thomas Huang" To: "Mark Pietras" , Subject: RE: [midcom] Midcom protocol specification and status Date: Fri, 24 May 2002 10:22:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <002201c20331$1a4fe680$4c01a8c0@MPIETRAS> X-Loop-Detect: 1 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hello Mark, Thank you very much for the info and update. Would you be kind enough to email some proposed protocol drafts that may make their way to publication? I got the impression that you are involved in the reviewing them and drafting. It apears that this MIDCOM framework/architecture would provide the solution for complete new deployment using this type of controllable middlebox. However are there efforts also in the making also addressing the deployment of voip in existing FW/NAT environment? I studied some sip/rtp proxy drafts from SIP/SIPPING group as well as some early packet relay in MGCP drafts. Is this group trying to consolidate the different approaches? as the one I mentioned? You said companies have started to build the boxes based on midcom architecture and some in production. I know Cisco doesn't offer it yet (to my limited knowledge). How could customers be assured that the boxes/hardware they buy today will be upgradable when there is a standard? Could you please kindly tell me if I could find the active member list of this midcom working group? Regards, Thomas -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Mark Pietras Sent: Friday, May 24, 2002 7:42 AM To: thuang@codentnetworks.com; midcom@ietf.org Subject: RE: [midcom] Midcom protocol specification and status Thomas, - There is no protocol specification at this point. The work is in progress. Currently the working group is doing two things: 1) working the STUN portion of the current charter which addresses short-term needs and a specific market, and 2) working the protocol portion of the current charter by evaluating several different protocol proposals against the framework/requirements docs as candidates for the actual Midcom protocol. - There are several vendors developing "Midcom boxes" currently. Some even have some in production networks. They generally follow the Midcom architecture, but currently use different protocols for policy control as there is no standard yet. Hence the current charter of this working group. Most of the vendors actively work in or at least follow this group, so I'm sure each would suggest they "lead the pack." Mark. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Thomas Huang Sent: Friday, May 24, 2002 11:23 AM To: midcom@ietf.org Subject: [midcom] Midcom protocol specification and status I have studied the three major doc in the repository: - Midcom architecture and framework - Midcom requirement - STUN But I can't find the MidCom protocol specification itself. Could you please help? - any draft spec that this group is working on - what's the concensus among the group and other related groups about midcom (SIP, MGCP, MEGACO) - Are there vendors starting to develop midcom boxes following the architecture? I am in the process of meeting a couple of vendors, but they don't say in literature what they follow. If yes, who are leading the pack? Thanks for any help. Thomas _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 24 14:17:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08364 for ; Fri, 24 May 2002 14:17:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10203 for midcom-archive@odin.ietf.org; Fri, 24 May 2002 14:17:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09975; Fri, 24 May 2002 14:14:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09824 for ; Fri, 24 May 2002 14:14:02 -0400 (EDT) Received: from linux.aravox.com (linux.aravox.com [209.46.41.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04667 for ; Fri, 24 May 2002 12:28:26 -0400 (EDT) Received: from MPIETRAS (IDENT:root@linux.aravox.com [209.46.41.66] (may be forged)) by linux.aravox.com (8.9.3/8.9.3) with ESMTP id LAA02985; Fri, 24 May 2002 11:26:35 -0500 From: "Mark Pietras" To: , Subject: RE: [midcom] Midcom protocol specification and status Date: Fri, 24 May 2002 11:25:54 -0500 Message-ID: <003301c2033f$ad4d1c10$4c01a8c0@MPIETRAS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I'd classify myself largely as being a "regular observer." You can get the submissions, working group archives, etc. from the www.ietf.org site. Correct, there is the "new device solution" which is the "controllable middlebox," and there is the shorter-term solution for working with existing environments (STUN). Each does certain things well in different environments. Buyers of new devices would simply have to pick a vendor they are comfortable with "to be assured that the boxes/hardware they buy today will be upgradable when there is a standard." Mark. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Thomas Huang Sent: Friday, May 24, 2002 12:23 PM To: Mark Pietras; midcom@ietf.org Subject: RE: [midcom] Midcom protocol specification and status Hello Mark, Thank you very much for the info and update. Would you be kind enough to email some proposed protocol drafts that may make their way to publication? I got the impression that you are involved in the reviewing them and drafting. It apears that this MIDCOM framework/architecture would provide the solution for complete new deployment using this type of controllable middlebox. However are there efforts also in the making also addressing the deployment of voip in existing FW/NAT environment? I studied some sip/rtp proxy drafts from SIP/SIPPING group as well as some early packet relay in MGCP drafts. Is this group trying to consolidate the different approaches? as the one I mentioned? You said companies have started to build the boxes based on midcom architecture and some in production. I know Cisco doesn't offer it yet (to my limited knowledge). How could customers be assured that the boxes/hardware they buy today will be upgradable when there is a standard? Could you please kindly tell me if I could find the active member list of this midcom working group? Regards, Thomas -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Mark Pietras Sent: Friday, May 24, 2002 7:42 AM To: thuang@codentnetworks.com; midcom@ietf.org Subject: RE: [midcom] Midcom protocol specification and status Thomas, - There is no protocol specification at this point. The work is in progress. Currently the working group is doing two things: 1) working the STUN portion of the current charter which addresses short-term needs and a specific market, and 2) working the protocol portion of the current charter by evaluating several different protocol proposals against the framework/requirements docs as candidates for the actual Midcom protocol. - There are several vendors developing "Midcom boxes" currently. Some even have some in production networks. They generally follow the Midcom architecture, but currently use different protocols for policy control as there is no standard yet. Hence the current charter of this working group. Most of the vendors actively work in or at least follow this group, so I'm sure each would suggest they "lead the pack." Mark. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Thomas Huang Sent: Friday, May 24, 2002 11:23 AM To: midcom@ietf.org Subject: [midcom] Midcom protocol specification and status I have studied the three major doc in the repository: - Midcom architecture and framework - Midcom requirement - STUN But I can't find the MidCom protocol specification itself. Could you please help? - any draft spec that this group is working on - what's the concensus among the group and other related groups about midcom (SIP, MGCP, MEGACO) - Are there vendors starting to develop midcom boxes following the architecture? I am in the process of meeting a couple of vendors, but they don't say in literature what they follow. If yes, who are leading the pack? Thanks for any help. Thomas _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 24 17:59:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16703 for ; Fri, 24 May 2002 17:59:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24351 for midcom-archive@odin.ietf.org; Fri, 24 May 2002 17:59:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24186; Fri, 24 May 2002 17:56:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24158 for ; Fri, 24 May 2002 17:55:57 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16539 for ; Fri, 24 May 2002 17:55:31 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4OLtRQ15375; Fri, 24 May 2002 16:55:28 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 16:55:15 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE3B65@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'thuang@codentnetworks.com'" , Mark Pietras , midcom@ietf.org Subject: RE: [midcom] Midcom protocol specification and status Date: Fri, 24 May 2002 16:55:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2036D.AECE4EF0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2036D.AECE4EF0 Content-Type: text/plain; charset="iso-8859-1" The MIDCOM protocol evaluation document (for which I'm the editor) will be submitted very soon - I'm in the midst of completing edits. It should be in your mailbox by Monday morning. The purpose of this evaluation was to evaluate existing protocols as the MIDCOM protocol with the following being considered: SNMP: http://www.ietf.org/internet-drafts/draft-quittek-midcom-snmp-eval-00.txt DIAMETER: http://www.ietf.org/internet-drafts/draft-taylor-midcom-diameter-eval-01.txt RSIP: http://www.ietf.org/internet-drafts/draft-renkel-rsip-midcom-eval-01.txt MEGACO: http://www.ietf.org/internet-drafts/draft-sct-midcom-megaco-02.txt COPS: http://www.ietf.org/internet-drafts/draft-aoun-midcom-cops-02.txt I would suggest that you wait till Monday rather than review these individual drafts as the majority of the content is being edited into the WG draft and comments need to be directed at that document rather than to the individual ones going forward. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: Thomas Huang [mailto:thuang@codentnetworks.com] Sent: Friday, May 24, 2002 12:23 PM To: Mark Pietras; midcom@ietf.org Subject: RE: [midcom] Midcom protocol specification and status Hello Mark, Thank you very much for the info and update. Would you be kind enough to email some proposed protocol drafts that may make their way to publication? I got the impression that you are involved in the reviewing them and drafting. It apears that this MIDCOM framework/architecture would provide the solution for complete new deployment using this type of controllable middlebox. However are there efforts also in the making also addressing the deployment of voip in existing FW/NAT environment? I studied some sip/rtp proxy drafts from SIP/SIPPING group as well as some early packet relay in MGCP drafts. Is this group trying to consolidate the different approaches? as the one I mentioned? You said companies have started to build the boxes based on midcom architecture and some in production. I know Cisco doesn't offer it yet (to my limited knowledge). How could customers be assured that the boxes/hardware they buy today will be upgradable when there is a standard? Could you please kindly tell me if I could find the active member list of this midcom working group? Regards, Thomas -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Mark Pietras Sent: Friday, May 24, 2002 7:42 AM To: thuang@codentnetworks.com; midcom@ietf.org Subject: RE: [midcom] Midcom protocol specification and status Thomas, - There is no protocol specification at this point. The work is in progress. Currently the working group is doing two things: 1) working the STUN portion of the current charter which addresses short-term needs and a specific market, and 2) working the protocol portion of the current charter by evaluating several different protocol proposals against the framework/requirements docs as candidates for the actual Midcom protocol. - There are several vendors developing "Midcom boxes" currently. Some even have some in production networks. They generally follow the Midcom architecture, but currently use different protocols for policy control as there is no standard yet. Hence the current charter of this working group. Most of the vendors actively work in or at least follow this group, so I'm sure each would suggest they "lead the pack." Mark. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Thomas Huang Sent: Friday, May 24, 2002 11:23 AM To: midcom@ietf.org Subject: [midcom] Midcom protocol specification and status I have studied the three major doc in the repository: - Midcom architecture and framework - Midcom requirement - STUN But I can't find the MidCom protocol specification itself. Could you please help? - any draft spec that this group is working on - what's the concensus among the group and other related groups about midcom (SIP, MGCP, MEGACO) - Are there vendors starting to develop midcom boxes following the architecture? I am in the process of meeting a couple of vendors, but they don't say in literature what they follow. If yes, who are leading the pack? Thanks for any help. Thomas _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C2036D.AECE4EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Midcom protocol specification and status

The MIDCOM protocol evaluation document (for which = I'm the editor) will be submitted very soon - I'm in the midst of = completing edits.  It should be in your mailbox by Monday morning. = The purpose of this evaluation was to evaluate existing protocols as = the MIDCOM protocol with the following being considered:

SNMP:
http://www.ietf.org/internet-drafts/draft-quittek-midc= om-snmp-eval-00.txt

DIAMETER:
http://www.ietf.org/internet-drafts/draft-taylor-midco= m-diameter-eval-01.txt

RSIP:
http://www.ietf.org/internet-drafts/draft-renkel-rsip-= midcom-eval-01.txt

MEGACO:
http://www.ietf.org/internet-drafts/draft-sct-midcom-m= egaco-02.txt

COPS:
http://www.ietf.org/internet-drafts/draft-aoun-midcom-= cops-02.txt

I would suggest that you wait till Monday rather than = review these individual drafts as the majority of the content is being = edited into the WG draft and comments need to be directed at that = document rather than to the individual ones going forward.

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806

-----Original Message-----
From: Thomas Huang [mailto:thuang@codentnetworks.c= om]
Sent: Friday, May 24, 2002 12:23 PM
To: Mark Pietras; midcom@ietf.org
Subject: RE: [midcom] Midcom protocol specification = and status


Hello Mark,

Thank you very much for the info and update.

Would you be kind enough to email some proposed = protocol drafts that may
make their way to publication? I got the impression = that you are involved in
the reviewing them and drafting.

It apears that this MIDCOM framework/architecture = would provide the solution
for complete new deployment using this type of = controllable middlebox.
However are there efforts also in the making also = addressing the deployment
of voip in existing FW/NAT environment?

I studied some sip/rtp proxy drafts from SIP/SIPPING = group as well as some
early packet relay in MGCP drafts. Is this group = trying to consolidate the
different approaches? as the one I mentioned?

You said companies have started to build the boxes = based on midcom
architecture and some in production. I know Cisco = doesn't offer it yet (to
my limited knowledge). How could customers be = assured that the
boxes/hardware they buy today will be upgradable = when there is a standard?

Could you please kindly tell me if I could find the = active member list of
this midcom working group?

Regards,
Thomas

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]O= n Behalf Of
Mark Pietras
Sent: Friday, May 24, 2002 7:42 AM
To: thuang@codentnetworks.com; = midcom@ietf.org
Subject: RE: [midcom] Midcom protocol specification = and status


Thomas,

- There is no protocol specification at this = point.  The work is in
progress.  Currently the working group is doing = two things: 1) working
the STUN portion of the current charter which = addresses short-term needs
and a specific market, and 2) working the protocol = portion of the
current charter by evaluating several different = protocol proposals
against the framework/requirements docs as = candidates for the actual
Midcom protocol.

- There are several vendors developing "Midcom = boxes" currently.  Some
even have some in production networks.  They = generally follow the Midcom
architecture, but currently use different protocols = for policy control
as there is no standard yet.  Hence the current = charter of this working
group.  Most of the vendors actively work in or = at least follow this
group, so I'm sure each would suggest they = "lead the pack."

Mark.

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] = On Behalf Of
Thomas Huang
Sent: Friday, May 24, 2002 11:23 AM
To: midcom@ietf.org
Subject: [midcom] Midcom protocol specification and = status


I have studied the three major doc in the = repository:
- Midcom architecture and framework
- Midcom requirement
- STUN

But I can't find the MidCom protocol specification = itself. Could you
please
help?
- any draft spec that this group is working = on
- what's the concensus among the group and other = related groups about
midcom
  (SIP, MGCP, MEGACO)
- Are there vendors starting to develop midcom boxes = following the
architecture?
  I am in the process of meeting a couple of = vendors, but they don't say
in
literature
  what they follow. If yes, who are leading the = pack?

Thanks for any help.

Thomas


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


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


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

------_=_NextPart_001_01C2036D.AECE4EF0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed May 29 07:35:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11293 for ; Wed, 29 May 2002 07:35:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03177 for midcom-archive@odin.ietf.org; Wed, 29 May 2002 07:35:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02761; Wed, 29 May 2002 07:33:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02731 for ; Wed, 29 May 2002 07:33:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11068; Wed, 29 May 2002 07:32:56 -0400 (EDT) Message-Id: <200205291132.HAA11068@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 May 2002 07:32:56 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-protocol-eval-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Protocol Evaluation Author(s) : M. Barnes Filename : draft-ietf-midcom-protocol-eval-00.txt Pages : 33 Date : 28-May-02 This document provides an evaluation of the applicability of SNMP, RSIP, MEGACO, DIAMETER and COPS as the MIDCOM protocol. A summary of each of the proposed protocols against the MIDCOM requirements and MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-protocol-eval-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-protocol-eval-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20020528130753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-protocol-eval-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-protocol-eval-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528130753.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed May 29 09:02:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15116 for ; Wed, 29 May 2002 09:02:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11517 for midcom-archive@odin.ietf.org; Wed, 29 May 2002 09:02:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11290; Wed, 29 May 2002 09:01:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11261 for ; Wed, 29 May 2002 09:01:06 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15041 for ; Wed, 29 May 2002 09:00:41 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4TD0W924993 for ; Wed, 29 May 2002 09:00:32 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 09:00:33 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A526@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'midcom@ietf.org'" Date: Wed, 29 May 2002 09:00:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20710.7BEAC5D0" Subject: [midcom] Evaluation Nit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20710.7BEAC5D0 Content-Type: text/plain; charset="iso-8859-1" In draft-ietf-midcom-protocol-eval-00.txt section 2.1.9, the final sentence relating to DIAMETER is extraneous: it appears to be copied from the previous requirement on mutual authentication. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C20710.7BEAC5D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Evaluation Nit

In draft-ietf-midcom-protocol-eval-00.txt section = 2.1.9, the final sentence relating to DIAMETER is extraneous: it = appears to be copied from the previous requirement on mutual = authentication.

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C20710.7BEAC5D0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed May 29 09:17:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15730 for ; Wed, 29 May 2002 09:17:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA12601 for midcom-archive@odin.ietf.org; Wed, 29 May 2002 09:17:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12570; Wed, 29 May 2002 09:15:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12536 for ; Wed, 29 May 2002 09:15:44 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15670 for ; Wed, 29 May 2002 09:15:15 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4TDF7926238 for ; Wed, 29 May 2002 09:15:07 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 09:15:08 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A527@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'midcom@ietf.org'" Date: Wed, 29 May 2002 09:15:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20712.998718EE" Subject: [midcom] SNMP In The Evaluation Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20712.998718EE Content-Type: text/plain; charset="iso-8859-1" SNMP fit to requirements is overstated relative to the other protocols. For consistency, every requirement which refers to "an appropriate definition of a Midcom MIB module" should be rated as "partially met". Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C20712.998718EE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SNMP In The Evaluation

SNMP fit to requirements is overstated relative to = the other protocols.  For consistency, every requirement which = refers to "an appropriate definition of a Midcom MIB module" = should be rated as "partially met".

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C20712.998718EE-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed May 29 09:38:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16680 for ; Wed, 29 May 2002 09:38:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13972 for midcom-archive@odin.ietf.org; Wed, 29 May 2002 09:38:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13884; Wed, 29 May 2002 09:37:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13850 for ; Wed, 29 May 2002 09:36:34 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16588 for ; Wed, 29 May 2002 09:36:06 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4TDaDZ26525 for ; Wed, 29 May 2002 08:36:13 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 08:36:01 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE3B79@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Subject: FW: [midcom] I-D ACTION:draft-ietf-midcom-protocol-eval-00.txt Date: Wed, 29 May 2002 08:35:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C20715.C4AE9A80" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C20715.C4AE9A80 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20715.C4AE9A80" ------_=_NextPart_001_01C20715.C4AE9A80 Content-Type: text/plain; charset="iso-8859-1" Hi all, The protocol evaluation draft is finally available. All WG members should review the document, particularly since there were so few comments received on the individual drafts that make up the content of this document. The individual contributors should carefully review their portions to ensure that my editorial changes are consistent and as Tom has already done, to point out any errors. I did some wordsmithing to ensure that the document had some consistent level of style and references to MIDCOM terms (i.e. being explicit when referring to MIDCOM agents, etc.), thus if you think I have changed the intent it should probably be discussed on the list. Since I was late getting it submitted on Friday nite and Monday was a Holiday in the US, the draft was delayed in getting published. So, I'm going to extend the deadline for comments to allow that extra weekend and request that all comments be submitted by noon CST on June 10th (rather than June 7th), but intend to keep the remaining dates for this document the same: June 14th Second version of draft available. June 14th-June 21st Mailing list discussion of version 2 of draft. June 28th Draft ready for WGLC July 19th WGLC ends July 26th Updated draft based upon WGLC comments available July 26th- Aug (whether another iteration is required for WGLC depends upon the extent of changes, etc.) Aug Draft submitted to IESG Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, May 29, 2002 6:33 AM Cc: midcom@ietf.org Subject: [midcom] I-D ACTION:draft-ietf-midcom-protocol-eval-00.txt 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 Evaluation Author(s) : M. Barnes Filename : draft-ietf-midcom-protocol-eval-00.txt Pages : 33 Date : 28-May-02 This document provides an evaluation of the applicability of SNMP, RSIP, MEGACO, DIAMETER and COPS as the MIDCOM protocol. A summary of each of the proposed protocols against the MIDCOM requirements and MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-protocol-eval-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-protocol-eval-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C20715.C4AE9A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [midcom] I-D = ACTION:draft-ietf-midcom-protocol-eval-00.txt

Hi all,

The protocol evaluation draft is finally = available.  All WG members should review the document, = particularly since there were so few comments received on the = individual drafts that make up the content of this document.  The = individual contributors should carefully review their portions to = ensure that my editorial changes are consistent and as Tom has already = done, to point out any errors.  I did some wordsmithing to ensure = that the document had some consistent level of style and references to = MIDCOM terms (i.e. being explicit when referring to MIDCOM agents, = etc.), thus if you think I have changed the intent it should probably = be discussed on the list. 

Since I was late getting it submitted on Friday nite = and Monday was a Holiday in the US, the draft was delayed in getting = published. So, I'm going to extend the deadline for comments to allow = that extra weekend and request that all comments be submitted by noon = CST on June 10th (rather than June 7th), but intend to keep the = remaining dates for this document the same:

June 14th       Second = version of draft available.
 
June 14th-June 21st  Mailing list discussion of = version 2 of draft.

June 28th       Draft = ready for WGLC

July 19th       WGLC = ends

July 26th       Updated = draft based upon WGLC comments available

July 26th- Aug (whether another iteration is required = for WGLC depends upon
          &nb= sp;     the extent of changes, etc.)

Aug     Draft submitted to IESG =

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Wednesday, May 29, 2002 6:33 AM
Cc: midcom@ietf.org
Subject: [midcom] I-D = ACTION:draft-ietf-midcom-protocol-eval-00.txt


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 Evaluation
        Author(s)       : M. = Barnes
        Filename        : = draft-ietf-midcom-protocol-eval-00.txt
        Pages           : = 33
        Date =            : = 28-May-02
       =20
This document provides an evaluation of the = applicability of SNMP,
RSIP, MEGACO, DIAMETER and COPS as the MIDCOM = protocol. A summary
of each of the proposed protocols against the MIDCOM = requirements
and MIDCOM framework is provided.  Compliancy = of each of the
protocols against each requirement is detailed. A = conclusion
summarizes how each of the protocols fares in the = evaluation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-= protocol-eval-00.txt

To remove yourself from the IETF Announcement list, = send a message to
ietf-announce-request with the word unsubscribe in = the body of the message.

Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" and a password of your e-mail = address. After logging in,
type "cd internet-drafts" and then
        "get = draft-ietf-midcom-protocol-eval-00.txt".

A list of Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-ietf-midcom-protocol-eval-00.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C20715.C4AE9A80-- ------_=_NextPart_000_01C20715.C4AE9A80 Content-Type: message/rfc822 To: Subject: Date: Wed, 29 May 2002 08:36:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C20715.C4AE9A80" ------_=_NextPart_002_01C20715.C4AE9A80 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C20715.C4AE9A80" ------_=_NextPart_003_01C20715.C4AE9A80 Content-Type: text/plain ------_=_NextPart_003_01C20715.C4AE9A80 Content-Type: text/html

  ------_=_NextPart_003_01C20715.C4AE9A80-- ------_=_NextPart_002_01C20715.C4AE9A80 Content-Type: application/octet-stream; name="ATT58255" Content-Disposition: attachment; filename="ATT58255" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020528130753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-protocol-eval-00.txt ------_=_NextPart_002_01C20715.C4AE9A80 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-midcom-protocol-eval-00"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C20715.C4AE9A80-- ------_=_NextPart_000_01C20715.C4AE9A80-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 30 09:00:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02316 for ; Thu, 30 May 2002 09:00:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25204 for midcom-archive@odin.ietf.org; Thu, 30 May 2002 09:01:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24568; Thu, 30 May 2002 08:55:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24540 for ; Thu, 30 May 2002 08:55:27 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02168 for ; Thu, 30 May 2002 08:55:01 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g4UCsr818847; Thu, 30 May 2002 14:54:53 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA09006; Thu, 30 May 2002 14:51:23 +0200 Date: Thu, 30 May 2002 14:51:21 +0200 From: Juergen Quittek To: Tom-PT Taylor , "'midcom@ietf.org'" Subject: Re: [midcom] SNMP In The Evaluation Message-ID: <8141096.1022770281@[192.168.102.164]> In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A527@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA0001E8A527@zcard0kc.ca.nortel.com> 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 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Tom, --On 29 May 2002 09:15 -0400 Tom-PT Taylor wrote: > > SNMP fit to requirements is overstated relative to the other > protocols. For consistency, every requirement which refers to > "an appropriate definition of a Midcom MIB module" should be > rated as "partially met". I agree, that the statements are to general. Would you be fine if I provide more concrete arguments, why these requirements are clearly met. This is much more appropriate than moving to partially met. Take for example "2.2.2 Support of multiple Middlebox types". SNMP has several means to do so, starting from the standard sysObjectID indicating the 'kind of box' to managed objects defining the type in more general terms, e.g. NAT, NAT-PT, NAPT, packet filter, ... Also box type specific support by specific managed objects is something which SNMP/SMI was built for. It definitely meets these requirement fully, not partially. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 30 09:55:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05109 for ; Thu, 30 May 2002 09:55:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA00737 for midcom-archive@odin.ietf.org; Thu, 30 May 2002 09:55:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00268; Thu, 30 May 2002 09:51:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29996 for ; Thu, 30 May 2002 09:48:00 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04679 for ; Thu, 30 May 2002 09:47:33 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4UDlMO24254 for ; Thu, 30 May 2002 15:47:22 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4UDlLP24378 for ; Thu, 30 May 2002 14:47:21 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 14:47:21 +0100 Message-ID: <4103264BC8D3D51180B7002048400C456344C0@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'midcom@ietf.org'" Date: Thu, 30 May 2002 14:48:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C207E0.A5F2116E" Subject: [midcom] Comments on SNMP evaluation in draft-ietf-midcom-protocol-eval-00 .txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C207E0.A5F2116E Content-Type: text/plain; charset="iso-8859-1" Hi. Some thoughts on the SNMP evaluation part: - There are more areas than just security where only SNMPv3 can meet the requirements. - The very simple and unextendable semantics of the SNMP protocol (just GET/SET/INFORM verbs) may be found to be restrictive for the mechanisms needed for Midcom. - SNMP message transport uses UDP when IP protocols are used (ie essentially always). This means that message delivery is unreliable which has some knock on effects: - The Midcom protocol would have to achieve reliability for itself above the SNMP layer - The Midcom protocol would have to be constructed to be be idempotent with respect to the MIB Module which implements the Midcom communication, because acknowledgements are just as unreliable as original messages. This means that any of the commands could be executed more than once as a result of retransmissions before an acknowledgement gets through. - TRAP messages cannot be realistically used to for the midbox -> agent direction as they are unacknowledged - Instead need to use acknowledged INFORMs available only in v3. Versions 1 and 2 of SNMP have not been used for configuration purposes (only GET/TRAP verbs used) because of obvious concerns about security: Network managers may have qualms about SNMPv3 until it has been extensively tested, which might slow up the deployment of Midcom if it uses SNMPv3. Regards, Elwyn Davies ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== ------_=_NextPart_001_01C207E0.A5F2116E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on SNMP evaluation in = draft-ietf-midcom-protocol-eval-00.txt

Hi.

Some thoughts on the SNMP evaluation part:
- There are more areas than just security where only = SNMPv3 can meet the requirements.
- The very simple and unextendable semantics of the = SNMP protocol (just GET/SET/INFORM verbs)
  may be found to be restrictive for the = mechanisms needed for Midcom.
- SNMP message transport uses UDP when IP protocols = are used (ie essentially always).  This means that
  message delivery is unreliable which has some = knock on effects:
  - The Midcom protocol would have to achieve = reliability for itself above the SNMP layer
  - The Midcom protocol would have to be = constructed to be be idempotent with respect to the MIB
    Module which implements the = Midcom communication, because acknowledgements are just as = unreliable
    as original messages.  This = means that any of the commands could be executed more than once as = a
    result of retransmissions before = an acknowledgement gets through.
  - TRAP messages cannot be realistically used = to for the midbox -> agent direction as they are
    unacknowledged  - Instead = need to use acknowledged INFORMs available only in v3.

Versions 1 and 2 of SNMP have not been used for = configuration purposes (only GET/TRAP verbs used) because of obvious = concerns about security:  Network managers may have qualms about = SNMPv3 until it has been extensively tested, which might slow up the = deployment of Midcom if it uses SNMPv3.

Regards,
Elwyn Davies
---------------------------------------------------------------= -------------------

Elwyn B Davies

        Routing = and Addressing Strategy Prime
        Portfolio = Integration           =         Solutions Ready =        

        Nortel = Networks plc     =         =         Email: = elwynd@nortelnetworks.com
        Harlow = Laboratories     =         =         =         = ESN           &nb= sp;         6-742-5498
        London = Road, Harlow,    =         =         Direct = Line             = +44-1279-405498
        Essex, = CM17 9NA, UK     =         =         = Fax           &nb= sp;         +44-1279-402047
        = Registered Office:      =         =         Maidenhead Office Park, = Westacott Way,
        Company = No. 3937799     =         =         Maidenhead, Berkshire, SSL6 = 3QH
---------------------------------------------------------------= -------------
This message may contain information proprietary to = Nortel Networks plc so any
unauthorised disclosure, copying or distribution of = its contents is strictly prohibited.
---------------------------------------------------------------= -------------
"The Folly is mostly mine"
and the opinions are mine and not those of my = employer.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D





------_=_NextPart_001_01C207E0.A5F2116E-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 30 10:00:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05338 for ; Thu, 30 May 2002 10:00:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01196 for midcom-archive@odin.ietf.org; Thu, 30 May 2002 10:00:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00785; Thu, 30 May 2002 09:55:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00757 for ; Thu, 30 May 2002 09:55:47 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05130 for ; Thu, 30 May 2002 09:55:22 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4UDtCR03975 for ; Thu, 30 May 2002 09:55:12 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 09:55:13 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A546@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Juergen Quittek'" , "'midcom@ietf.org'" Subject: RE: [midcom] SNMP In The Evaluation Date: Thu, 30 May 2002 09:55:10 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a matter of consistent treatment of the protocols in the evaluation. For DIAMETER, for instance, the necessary data types have probably all been defined in Base, but it will be necessary to define the messages containing them. I think you are saying that in the SNMP case you can point to specific object types you can import but it will be necessary to define a new module to provide a context for them. These may not be at the same level of activity, but I think they are sufficiently analogous that both protocols should be classified in the same way. -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: Thursday, May 30, 2002 8:51 AM To: Taylor, Tom-PT [CAR:B602:EXCH]; 'midcom@ietf.org' Subject: Re: [midcom] SNMP In The Evaluation Tom, --On 29 May 2002 09:15 -0400 Tom-PT Taylor wrote: > > SNMP fit to requirements is overstated relative to the other > protocols. For consistency, every requirement which refers to > "an appropriate definition of a Midcom MIB module" should be > rated as "partially met". I agree, that the statements are to general. Would you be fine if I provide more concrete arguments, why these requirements are clearly met. This is much more appropriate than moving to partially met. Take for example "2.2.2 Support of multiple Middlebox types". SNMP has several means to do so, starting from the standard sysObjectID indicating the 'kind of box' to managed objects defining the type in more general terms, e.g. NAT, NAT-PT, NAPT, packet filter, ... Also box type specific support by specific managed objects is something which SNMP/SMI was built for. It definitely meets these requirement fully, not partially. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 30 14:28:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16631 for ; Thu, 30 May 2002 14:28:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26579 for midcom-archive@odin.ietf.org; Thu, 30 May 2002 14:29:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26477; Thu, 30 May 2002 14:27:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26435 for ; Thu, 30 May 2002 14:27:47 -0400 (EDT) Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16548; Thu, 30 May 2002 14:27:11 -0400 (EDT) Received: from notes800.cc.telcordia.com (notes800.cc.telcordia.com [128.96.79.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id OAA15155; Thu, 30 May 2002 14:20:52 -0400 (EDT) To: midcom@ietf.org, sipping@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Thu, 30 May 2002 14:19:12 -0400 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 05/30/2002 02:20:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] STUN Implementation in Java 1.4 available Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org For those interested, there is a Java implementation available of the STUN proposal at http://www.columbia.edu/~pt81/cs6901-08/cs6901-08.html _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu May 30 14:49:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17217 for ; Thu, 30 May 2002 14:49:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27771 for midcom-archive@odin.ietf.org; Thu, 30 May 2002 14:49:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27713; Thu, 30 May 2002 14:48:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27682 for ; Thu, 30 May 2002 14:48:09 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17154 for ; Thu, 30 May 2002 14:47:42 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g4UIlc825915; Thu, 30 May 2002 20:47:38 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA11662; Thu, 30 May 2002 20:44:07 +0200 Date: Thu, 30 May 2002 20:44:06 +0200 From: Juergen Quittek To: Elwyn Davies , "'midcom@ietf.org'" Subject: Re: [midcom] Comments on SNMP evaluation in draft-ietf-midcom-protocol-eval-00 .txt Message-ID: <29305889.1022791446@[192.168.102.164]> In-Reply-To: <4103264BC8D3D51180B7002048400C456344C0@zhard0jd.europe.nortel.com> References: <4103264BC8D3D51180B7002048400C456344C0@zhard0jd.europe.nortel.com> 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 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi Elwyn, Thank you for your comments. Please see my answers below. --On 30 May 2002 14:48 +0100 Elwyn Davies wrote: > > Hi. > > Some thoughts on the SNMP evaluation part: > - There are more areas than just security where only SNMPv3 > can meet the requirements. Which areas? Do you mean the two you mention below (INFORMS, not extensively tested)? > - The very simple and unextendable semantics of the SNMP > protocol (just GET/SET/INFORM verbs) may be found to be > restrictive for the mechanisms needed for Midcom. I don't think so. Can you give an example? I agree that this restriction might become a bit inconvenient, but I do not see any requirement that is not met because of it. > - SNMP message transport uses UDP when IP protocols are used > (ie essentially always). This means that message delivery > is unreliable which has some knock on effects: > - The Midcom protocol would have to achieve reliability for > itself above the SNMP layer Typically an SNMP stack includes some reliability mechanisms "above" SNMP for exactly solving this problem. Is it intentional, that there is no reliability requirement for the midcom protocol? > - The Midcom protocol would have to be constructed to be > be idempotent with respect to the MIB Module which > implements the Midcom communication, because > acknowledgements are just as unreliable as original > messages. This means that any of the commands could be > executed more than once as a result of retransmissions > before an acknowledgement gets through. Yes, this is a typical problem with SNMP. However, typically it is solved case by case. Most cases can be solved by a good MIB module design that considers this fact. The remaining cases have to be covered by the SNMP agent implementation at the midcom server. > - TRAP messages cannot be realistically used to for the > midbox -> agent direction as they are unacknowledged > - Instead need to use acknowledged INFORMs available > only in v3. I disagree. I think that unacknowledged v2 notifications are sufficient (and meet the requirements). Of course INFORMs are more desirable. > Versions 1 and 2 of SNMP have not been used for > configuration purposes (only GET/TRAP verbs used) because > of obvious concerns about security: Network managers may > have qualms about SNMPv3 until it has been extensively tested, > which might slow up the deployment of Midcom if it uses SNMPv3. Just compare deployment and testing of SNMPv3 to the other protocols that have been suggested. It might turn out to be the one with the most practical experience. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > Regards, > Elwyn Davies > ---------------------------------------------------------------------------------- > > Elwyn B Davies > > Routing and Addressing Strategy Prime > Portfolio Integration Solutions Ready > > Nortel Networks plc Email: elwynd@nortelnetworks.com > Harlow Laboratories ESN 6-742-5498 > London Road, Harlow, Direct Line +44-1279-405498 > Essex, CM17 9NA, UK Fax +44-1279-402047 > Registered Office: Maidenhead Office Park, Westacott Way, > Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH > ---------------------------------------------------------------------------- > This message may contain information proprietary to Nortel Networks plc so any > unauthorised disclosure, copying or distribution of its contents is strictly prohibited. > ---------------------------------------------------------------------------- > "The Folly is mostly mine" > and the opinions are mine and not those of my employer. > ================================================================================== > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri May 31 03:02:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07717 for ; Fri, 31 May 2002 03:02:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA08993 for midcom-archive@odin.ietf.org; Fri, 31 May 2002 03:02:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08157; Fri, 31 May 2002 02:51:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08126 for ; Fri, 31 May 2002 02:51:06 -0400 (EDT) Received: from cygnus.degree2.com ([195.89.159.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07424 for ; Fri, 31 May 2002 02:50:40 -0400 (EDT) Received: from calypso (calypso.degree2.com [172.30.40.49]) by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id g4V6odf30134; Fri, 31 May 2002 07:50:39 +0100 From: "Alistair Munro" To: "'Juergen Quittek'" , "'Elwyn Davies'" , Subject: RE: [midcom] Comments on SNMP evaluation in draft-ietf-midcom-protocol-eval-00 .txt Date: Fri, 31 May 2002 07:52:51 +0100 Message-ID: <001701c2086f$c8b03b60$31281eac@degree2.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <29305889.1022791446@[192.168.102.164]> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi All, I may have missed discussion of the topic, but is TCP-friendliness, congestion awareness, etc. an issue here? Regards, Alistair -- Dr. Alistair Munro, Chief Systems Engineer, Degree2 Innovations Ltd. Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K. E-mail: Alistair.Munro@degree2.com Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-900-8151 Web: http://www.u4eagroup.com > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On > Behalf Of Juergen Quittek > Sent: 30 May 2002 19:44 > To: Elwyn Davies; 'midcom@ietf.org' > Subject: Re: [midcom] Comments on SNMP evaluation in > draft-ietf-midcom-protocol-eval-00 .txt > > > Hi Elwyn, > > Thank you for your comments. Please see my answers below. > > --On 30 May 2002 14:48 +0100 Elwyn Davies wrote: > > > > > Hi. > > > > Some thoughts on the SNMP evaluation part: > > - There are more areas than just security where only SNMPv3 > > can meet the requirements. > > Which areas? Do you mean the two you mention below (INFORMS, > not extensively tested)? > > > - The very simple and unextendable semantics of the SNMP > > protocol (just GET/SET/INFORM verbs) may be found to be > > restrictive for the mechanisms needed for Midcom. > > I don't think so. Can you give an example? > > I agree that this restriction might become a bit > inconvenient, but I do not see any requirement that > is not met because of it. > > > - SNMP message transport uses UDP when IP protocols are used > > (ie essentially always). This means that message delivery > > is unreliable which has some knock on effects: > > - The Midcom protocol would have to achieve reliability for > > itself above the SNMP layer > > Typically an SNMP stack includes some reliability mechanisms > "above" SNMP for exactly solving this problem. > > Is it intentional, that there is no reliability requirement > for the midcom protocol? > > > - The Midcom protocol would have to be constructed to be > > be idempotent with respect to the MIB Module which > > implements the Midcom communication, because > > acknowledgements are just as unreliable as original > > messages. This means that any of the commands could be > > executed more than once as a result of retransmissions > > before an acknowledgement gets through. > > Yes, this is a typical problem with SNMP. However, typically > it is solved case by case. Most cases can be solved by a good > MIB module design that considers this fact. The remaining > cases have to be covered by the SNMP agent implementation at > the midcom server. > > > - TRAP messages cannot be realistically used to for the > > midbox -> agent direction as they are unacknowledged > > - Instead need to use acknowledged INFORMs available > > only in v3. > > I disagree. I think that unacknowledged v2 notifications > are sufficient (and meet the requirements). Of course INFORMs > are more desirable. > > > Versions 1 and 2 of SNMP have not been used for > > configuration purposes (only GET/TRAP verbs used) because > > of obvious concerns about security: Network managers may > have qualms > > about SNMPv3 until it has been extensively tested, which > might slow up > > the deployment of Midcom if it uses SNMPv3. > > Just compare deployment and testing of SNMPv3 to the other > protocols that have been suggested. It might turn out to be > the one with the most practical experience. > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > > Regards, > > Elwyn Davies > > > ---------------------------------------------------------------------- > > ------------ > > > > Elwyn B Davies > > > > Routing and Addressing Strategy Prime > > Portfolio Integration Solutions Ready > > > > Nortel Networks plc Email: > elwynd@nortelnetworks.com > > Harlow Laboratories ESN > 6-742-5498 > > London Road, Harlow, Direct Line > +44-1279-405498 > > Essex, CM17 9NA, UK Fax > +44-1279-402047 > > Registered Office: Maidenhead > Office Park, Westacott Way, > > Company No. 3937799 Maidenhead, > Berkshire, SSL6 3QH > > > ---------------------------------------------------------------------- > > ------ > > This message may contain information proprietary to Nortel > Networks plc so any > > unauthorised disclosure, copying or distribution of its > contents is strictly prohibited. > > > -------------------------------------------------------------- > -------------- > > "The Folly is mostly mine" > > and the opinions are mine and not those of my employer. > > > ============================================================== > ==================== > > > > > > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 31 11:59:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20403 for ; Fri, 31 May 2002 11:59:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15589 for midcom-archive@odin.ietf.org; Fri, 31 May 2002 11:59:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15327; Fri, 31 May 2002 11:55:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15297 for ; Fri, 31 May 2002 11:55:55 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20287 for ; Fri, 31 May 2002 11:55:25 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4VFsOIZ019007 for ; Fri, 31 May 2002 08:54:24 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEA28900; Fri, 31 May 2002 08:51:29 -0700 (PDT) Message-Id: <5.1.0.14.0.20020531115055.00aa76e0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 31 May 2002 11:59:10 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Upcoming meeting Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org It's time to start thinking about the agenda for the July meeting. On the plate are: 1) pre-midcom: I'm still hoping to get STUN through WG last call before the meeting, but the other thing, which we're currently calling "SPAN," will just be available and should be discussed. 2) midcom: we'll probably be spending most of the meeting on the evaluation document and talking about moving towards producing a protocol. Please let me know if there's anything that needs additional or particular attention. As usual, there will be NO presentations, and new material will be discussed only if there's an extremely compelling reason for doing so. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri May 31 12:33:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21666 for ; Fri, 31 May 2002 12:33:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20153 for midcom-archive@odin.ietf.org; Fri, 31 May 2002 12:34:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20086; Fri, 31 May 2002 12:32:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20057 for ; Fri, 31 May 2002 12:32:18 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21558 for ; Fri, 31 May 2002 12:31:04 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4VGUwp12416 for ; Fri, 31 May 2002 12:30:58 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 12:30:58 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A55E@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Upcoming meeting Date: Fri, 31 May 2002 12:30:58 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We reached a bit of an impasse over the "deterministic result" requirement in our semantic discussion. I can restart discussion on the list, but we may find this discussion needs face-to-face resolution. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Friday, May 31, 2002 11:59 AM To: midcom@ietf.org Subject: [midcom] Upcoming meeting It's time to start thinking about the agenda for the July meeting. On the plate are: 1) pre-midcom: I'm still hoping to get STUN through WG last call before the meeting, but the other thing, which we're currently calling "SPAN," will just be available and should be discussed. 2) midcom: we'll probably be spending most of the meeting on the evaluation document and talking about moving towards producing a protocol. Please let me know if there's anything that needs additional or particular attention. As usual, there will be NO presentations, and new material will be discussed only if there's an extremely compelling reason for doing so. 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