From daemon@optimus.ietf.org Mon Dec 3 13:19:03 2001 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 NAA18860 for ; Mon, 3 Dec 2001 13:19:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05436 for midcom-archive@odin.ietf.org; Mon, 3 Dec 2001 13:19:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05315; Mon, 3 Dec 2001 13:13:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05288 for ; Mon, 3 Dec 2001 13:13:22 -0500 (EST) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18523 for ; Mon, 3 Dec 2001 13:13:21 -0500 (EST) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA28235 for ; Mon, 3 Dec 2001 12:12:49 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 3 Dec 2001 12:04:51 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Dec 2001 12:10:32 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F328@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Steve Davies'" , "'midcom@ietf.org'" Cc: "Sanjoy Sen" Subject: RE: [midcom] new I-D on "symmetric STUN" Date: Mon, 3 Dec 2001 12:10:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17C25.CB141650" X-Orig: 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_01C17C25.CB141650 Content-Type: text/plain; charset="iso-8859-1" Steve, Please find my comments inline. -----Original Message----- From: Steve Davies [mailto:sdavies@ridgewaysystems.com] Sent: Friday, November 30, 2001 8:50 AM To: Sen, Sanjoy [NGB:B692:EXCH]; 'midcom@ietf.org' Subject: RE: [midcom] new I-D on "symmetric STUN" [snip] > 1) Your App. Proxy is also an RTP Proxy. So for a simple two party call where both are behind NAPT, > the media need to traverse at least 3 RTP proxies. Is this correct? Ans: The FANTOM client, like the TURN client, may be implemented on the UA, in which case only the external RTP proxy is traversed, as in your proposal. The FANTOM client may also be implemented as a standalone system or be co-resident in an IP-PBX or IAD. In this case you are correct. Why? See 2 below. [SS] I still don't see the benefits of your standalone system apart from bringing in additional cost and complexity to the solution (see below). > 2) Not sure what you gain by making the media go through the App. Proxy? For example, in our proposal, > we have the terminal send the empty RTP packets (equivalent to your probes) directly to the Media > intermediary in the SP network to establish the media binds. Ans: The reason FANTOM is specified in this way is because we felt a pre-midcom solution should require ABSOLUTELY NO changes (protocol or behavioural) to enterprise endpoints and should work with existing systems. [SS] I question the effectiveness of the additional complexity and an additional network entity when you can avoid them by making some simple configurations on the client. This is a costly solution for a problem which can be solved easily otherwise. And, if you make the clients run FANTOM, then you're adding a whole bunch of signaling complexity in the client. FANTOM places NO pre-requisite for symmetric bi-directional, continual RTP. The FANTOM client is responsible for making outbound UDP connection and the NAT keep-alives, so the UA can implement uni-directional RTP or silence suppression if it wishes. [SS] Both the Sen proposal (and I believe TURN) can work with unidirectional RTP. In the Sen proposal, you just need the send and receive ports spit out empty RTP packets to create two binds in the NAT and Media Proxy. But there's a cost-complexity trade-off as noted above. And, as I noted before, you don't have to turn off silence suppression - either use the comfort noise packets generated by most existing codecs during silence period or use empty RTP packets. A major benefit of the FANTOM client (whether co-resident or standalone) is that we can minimise the pin-holes required in the firewall to just a few - our optimal solution is just 3 - one TCP and 2 UDP. [SS] This means you're resorting to "tunneling" and the FW has no clue as to what packets are getting sent across within the tunnel. This is something we all want to avoid. With FANTOM, a FW admnistrator can restrict external UDP to just symmetric UDP to/from the FANTOM server's 2 UDP ports. With your proposal, the firewall administrator has to work on IP addresses of the RTP proxies, which means that as the service scales, the administrator is continually adding extra IP addresses to the FW access list. The more work the FW administrator does the greater the chances of error. [SS] This is not correct. All you need for the Sen proposal to work is for the FW to turn on dynamic stateful packet filter policy (aka, UDP conversation or transparent firewall) which allows UDP packets in the Enterprise if its from the same address/port that a packet was sent to. This is most commonly used Enterprise FW policy. The admin doesn't worry about the RTP proxy port allocations. Again, there're only two ways you can keep the UDP path open - either create a permanently open bind/pinhole, or use refresh packets. The first method is obviously not a good security policy. If you resort to the second method, then the main difference between FANTOM and the other proposals is whether to create new messages (RTP probes) or re-use something existing for this purpose (e.g., silence packets). Again, we think that its lot cheaper to leverage existing mechanisms. The extra hops that FANTOM requires in the enterprise is insignificant in latency and bandwidth particularly in a switched Ethernet configuration. [SS] When you've three Proxies in the path each handling signaling and media for potentially thousands of simultaneous calls, its not obvious to me how you claim that the performance will not suffer as you scale. > 3) For SIP services, your AP and PEA both will house a SIP Proxy function, RTP Proxy function, as well > as your control protocol+ RTP/RTCP probes. What is the implication of putting all these functions in > one box from capacity, fault-tolerance and security p.o.v. ? Ans: Only the AP has a SIP or H.323 or MGCP (or...) proxy function. Those who have attended any of my presentations (VON, SIP Summit etc.) will have deduced that the functions readily break out and can reside on different processors so that a distributed fault tolerant architecture can be implemented if required. [SS] Its not just splitting the functions. How would you coordinate the signaling and the media port allocation? Are you talking about a multiprocessor implementation? Also if you split the functions in different boxes, you now need 5 boxes for setting up an end to end call (when both users are behind NAT). > For example, the AP will be doing refreshes for all NAT binds for all RTP sessions on behalf of all terminals. Ans: Yes FANTOM is tuned to the network infrastructure obviating the need for applications to know about it. We have designed the FANTOM probe to be very distinguishable from media making a silicon or efficient software implementations possible. [SS] I question the scalability, fault-tolerance and implementation cost of this approach. This is too heavy-weight compared to a more distributed signaling and media approach that we've, that essentially serves the same purpose. > 4) Are you planning on using a standard protocol as this control protocol? In Sen proposal, we've used > an existing device control protocol. The sen proposal essentially needs no new protocol development. Ans: Do you mean between the FANTOM client and the FANTOM server or between the signalling proxy and the RTP proxy? FANTOM is the control protocol between client and server. Like you, our philosophy is to use existing methods where appropriate. But we don't based a solution on having to change a protocol or terminal behaviour to make it work. That's too hard a sell. [SS] Between the FANTOM client and the server. This control protocol essentially essentially serves the same purpose of the control protocol that we've between the signaling proxy and the RTP (media) proxy, except for the RTP probes. An existing device-control protocol can be used here. > 5) Your requirement for always allowing traffic from some "well-known" address/port of PEA to the AP > in the private network is a big concern. This is typically NOT done in traditional enterprise FW. Ans: On the contrary it is (a) common practice - that's what well know ports are for, ... [SS] Don't agree on this one. > Such a FW will typically close the pin-hole after sometime, hence the need for signaling path refreshes > using PING or REGISTER) both in our scheme and Jonathan's. Ans: This is the reason we mux the signalling with the control channel. It removes the need to do lots of refreshes for multiple paths. Again FANTOM takes care of it on behalf of the terminal. [SS] But you resort to tunneling, something most of us want to avoid as stated earlier. Regards, Sanjoy Steve > Thanks, > Sanjoy ------_=_NextPart_001_01C17C25.CB141650 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] new I-D on "symmetric STUN"

Steve, Please find my comments inline.

-----Original Message-----
From: Steve Davies [mailto:sdavies@ridgewaysystems.com]
Sent: Friday, November 30, 2001 8:50 AM
To: Sen, Sanjoy [NGB:B692:EXCH]; 'midcom@ietf.org'
Subject: RE: [midcom] new I-D on "symmetric STUN"

[snip]

> 1) Your App. Proxy is also an RTP Proxy. So for a simple two party call where both are behind NAPT,
> the media need to traverse at least 3 RTP proxies. Is this correct?

Ans: The FANTOM client, like the TURN client, may be implemented on the UA, in which case only the external RTP proxy is traversed, as in your proposal. The FANTOM client may also be implemented as a standalone system or be co-resident in an IP-PBX or IAD. In this case you are correct. Why? See 2 below.

  [SS] I still don't see the benefits of your standalone system apart from bringing in additional cost and complexity to the solution (see below).

> 2) Not sure what you gain by making the media go through the App. Proxy? For example, in our proposal,
> we have the terminal send the empty RTP packets (equivalent to your probes) directly to the Media
> intermediary in the SP network to establish the media binds.

Ans: The reason FANTOM is specified in this way is because we felt a pre-midcom solution should require ABSOLUTELY NO changes (protocol or behavioural) to enterprise endpoints and should work with existing systems.

[SS] I question the effectiveness of the additional complexity and an additional network entity when you can avoid them by making some simple configurations on the client. This is a costly solution for a problem which can be solved easily otherwise. And, if you make the clients run FANTOM, then you're adding a whole bunch of signaling complexity in the client.

FANTOM places NO pre-requisite for symmetric bi-directional, continual RTP. The FANTOM client is responsible for making outbound UDP connection and the NAT keep-alives, so the UA can implement uni-directional RTP or silence suppression if it wishes.

[SS] Both the Sen proposal (and I believe TURN) can work with unidirectional RTP. In the Sen proposal, you just need the send and receive ports spit out empty RTP packets to create two binds in the NAT and Media Proxy. But there's a cost-complexity trade-off as noted above. And, as I noted before, you don't have to turn off silence suppression - either use the comfort noise packets generated by most existing codecs during silence period or use empty RTP packets.

A major benefit of the FANTOM client (whether co-resident or standalone) is that we can minimise the pin-holes required in the firewall to just a few - our optimal solution is just 3 - one TCP and 2 UDP.

[SS] This means you're resorting to "tunneling" and the FW has no clue as to what packets are getting sent across within the tunnel. This is something we all want to avoid.

With FANTOM, a FW admnistrator can restrict external UDP to just symmetric UDP to/from the FANTOM server's 2 UDP ports. With your proposal, the firewall administrator has to work on IP addresses of the RTP proxies, which means that as the service scales, the administrator is continually adding extra IP addresses to the FW access list. The more work the FW administrator does the greater the chances of error.

[SS] This is not correct. All you need for the Sen proposal to work is for the FW to turn on dynamic stateful packet filter policy (aka, UDP conversation or transparent firewall) which allows UDP packets in the Enterprise if its from the same address/port that a packet was sent to. This is most commonly used Enterprise FW policy. The admin doesn't worry about the RTP proxy port allocations.

Again, there're only two ways you can keep the UDP path open - either create a permanently open bind/pinhole, or use refresh packets. The first method is obviously not a good security policy. If you resort to the second method, then the main difference between FANTOM and the other proposals is whether to create new messages (RTP probes) or re-use something existing for this purpose (e.g., silence packets). Again, we think that its lot cheaper to leverage existing mechanisms.

The extra hops that FANTOM requires in the enterprise is insignificant in latency and bandwidth particularly in a switched Ethernet configuration.

  [SS] When you've three Proxies in the path each handling signaling and media for potentially thousands of simultaneous calls, its not obvious to me how you claim that the performance will not suffer as you scale.

> 3) For SIP services, your AP and PEA both will house a SIP Proxy function, RTP Proxy function, as well
> as your control protocol+ RTP/RTCP probes. What is the implication of putting all these functions in
> one box from capacity, fault-tolerance and security p.o.v. ?

Ans: Only the AP has a SIP or H.323 or MGCP (or...) proxy function. Those who have attended any of my presentations (VON, SIP Summit etc.) will have deduced that the functions readily break out and can reside on different processors so that a distributed fault tolerant architecture can be implemented if required.

  [SS] Its not just splitting the functions. How would you coordinate the signaling and the media port allocation? Are you talking about a multiprocessor implementation? Also if you split the functions in different boxes, you now need 5 boxes for setting up an end to end call (when both users are behind NAT).

> For example, the AP will be doing refreshes for all NAT binds for all RTP sessions on behalf of all terminals.

Ans: Yes FANTOM is tuned to the network infrastructure obviating the need for applications to know about it. We have designed the FANTOM probe to be very distinguishable from media making a silicon or efficient software implementations possible.

[SS] I question the scalability, fault-tolerance and implementation cost of this approach. This is too heavy-weight compared to a more distributed signaling and media approach that we've, that essentially serves the same purpose.

> 4) Are you planning on using a standard protocol as this control protocol? In Sen proposal, we've used
> an existing device control protocol. The sen proposal essentially needs no new protocol development.

Ans: Do you mean between the FANTOM client and the FANTOM server or between the signalling proxy and the RTP proxy? FANTOM is the control protocol between client and server. Like you, our philosophy is to use existing methods where appropriate. But we don't based a solution on having to change a protocol or terminal behaviour to make it work. That's too hard a sell.

   [SS] Between the FANTOM client and the server. This control protocol essentially essentially serves the same purpose of the control protocol that we've between the signaling proxy and the RTP (media) proxy, except for the RTP probes. An existing device-control protocol can be used here.

> 5) Your requirement for always allowing traffic from some "well-known" address/port of PEA to the AP
> in the private network is a big concern. This is typically NOT done in traditional enterprise FW.

Ans: On the contrary it is (a) common practice - that's what well know ports are for,  ...

  [SS] Don't agree on this one.

> Such a FW will typically close the pin-hole after sometime, hence the need for signaling path refreshes
> using PING or REGISTER) both in our scheme and Jonathan's.

Ans: This is the reason we mux the signalling with the control channel. It removes the need to do lots of refreshes for multiple paths. Again FANTOM takes care of it on behalf of the terminal.

[SS] But you resort to tunneling, something most of us want to avoid as stated earlier.

Regards,

Sanjoy

Steve

> Thanks,
> Sanjoy

yes :-). I've been troubled with this issue as well = as the discovery problem.
Using the application client registration process is = the best way to reach the clients (while maintaining the bind by a keep = alive of course) but we need to reach the application servers = first.

This is not a tough problem in enterprise since you = can afford putting 1 or 2 call agents in the DMZ.

Unfortunately when we look at a VoIP service provider = handling several hundred thousands (or probably millions) calls, = several 10s of call agent processing entities will be required. =

In case full cone NATs where used all times, one = could potentially think of using stateless registration servers; most = enterprises still use symmetric NAT for security reasons. So this = solution doesn't work, we can't minimize the number of servers in the = DMZ.

It is no longer a couple of servers hosted in the DMZ = of a service provider.

This is a problem that I've been noticing in the VoIP = carrier space, and not all service providers could afford giving up = these groups of registered addresses.

Using static binds doesn't scale and is a nightmare = to maintain.
Potentially the solution could use DNS SRV with an = embedded DNS ALG on the service provider MBs.
Any comments/inputs?

-----Original Message-----
From: Scott Brim [mailto:swb@employees.org]
Sent: Thursday, December 06, 2001 8:15 PM
To: midcom
Subject: Re: [midcom] More than one NAT in = Network-friendlier Midcom

On Thu, Dec 06, 2001 01:29:09PM -0500, Melinda Shore = wrote:
> First, a deployment in which a server does not = have a
> public address but is intended to be globally = reachable
> is just asking for trouble.

There's a message I can't find in the archives, in = which iirc Cedric
Aoun claimed that at least some voice service = providers would be placing
voice agents behind NATs. It's been = complicating everything for me.
Cedric, are you there?

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

------_=_NextPart_001_01C17EB2.6B536330-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Dec 6 20:08:58 2001 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 UAA20245 for ; Thu, 6 Dec 2001 20:08:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22964 for midcom-archive@odin.ietf.org; Thu, 6 Dec 2001 20:09:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22927; Thu, 6 Dec 2001 20:07:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22900 for ; Thu, 6 Dec 2001 20:07:02 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20203 for ; Thu, 6 Dec 2001 20:06:59 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id fB716pT03050; Thu, 6 Dec 2001 20:06:51 -0500 (EST) Message-Id: <200112070106.fB716pT03050@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Cedric Aoun" cc: "'Scott Brim'" , midcom Subject: Re: [midcom] More than one NAT in Network-friendlier Midcom In-reply-to: Your message of "Fri, 07 Dec 2001 00:02:11 GMT." Date: Thu, 06 Dec 2001 20:06:51 -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 > Potentially the solution could use DNS SRV with an embedded DNS ALG on the > service provider MBs. please don't pollute DNS in an effort to try to solve the NAT problem. NATs cause enough problems as it is without making DNS worse. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Dec 7 01:41:33 2001 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 BAA00881 for ; Fri, 7 Dec 2001 01:41:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA11262 for midcom-archive@odin.ietf.org; Fri, 7 Dec 2001 01:41:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10948; Fri, 7 Dec 2001 01:32:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10923 for ; Fri, 7 Dec 2001 01:32:23 -0500 (EST) 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 BAA00106 for ; Fri, 7 Dec 2001 01:32:22 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fB76Vr901070; Thu, 6 Dec 2001 22:31:53 -0800 (PST) Received: from ELEAR-W2K1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id fB76VqS04499; Thu, 6 Dec 2001 22:31:52 -0800 (PST) Message-Id: <5.1.0.14.2.20011206221249.01c07628@lint.cisco.com> X-Sender: elear@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Dec 2001 22:31:48 -0800 To: "Cedric Aoun" From: Eliot Lear Subject: RE: [midcom] More than one NAT in Network-friendlier Midcom Cc: "'Scott Brim'" , midcom In-Reply-To: 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 I don't know if Sean is on the list, but he did in fact suggest precisely what you mentioned- use DNS SRV records. This has several benefits and several problems. The benefits are that you force consistency in DNS because you can't have a connection without it- that's also bad, by the way, but I'll get to that in a bit. It also has a discovery benefit, in as much as you can have multiple records for multiple NATs within an administrative domain. This gets tricky for concentric NAT but then I've always been of the opinion that if you are going to NAT *always* NAT into public space. I also think that DNS *should* play much more of a role than it does today, so that you can more properly identify the actors, and not just a pool member. Now the problems: as I alluded, placing a connectivity requirement on a functional DNS could lead to certain circular dependencies. However, these dependencies already exist just about any CLIENT, today, and it would be the CLIENT that would have the problem. Getting reverse lookups working would be amusing, to say the least, since you *really* want to resolve both the IP address, and the transport port into a name. Caching semantics here are of concern, as well. If the phone ends up listening for a brief period of time, when it stops you have a problem if your ttl > 0. Lots of gotchas around this one... One problem is the installed base, and that every protocol would have to make use of this record. I'm also unsure of whether operationally DNS is up to this, especially if each phone needs to do lots of transactions (opening ports, closing ports, etc). This to me is a bit unknown. We've all seen Randy's presentation, and I can't fault Keith for worrying about what messes could get created, here. Eliot _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Dec 7 04:51:33 2001 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 EAA17163 for ; Fri, 7 Dec 2001 04:51:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17316 for midcom-archive@odin.ietf.org; Fri, 7 Dec 2001 04:51:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17080; Fri, 7 Dec 2001 04:49:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17014 for ; Fri, 7 Dec 2001 04:49:23 -0500 (EST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17121 for ; Fri, 7 Dec 2001 04:49:20 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fB79lnd27096; Fri, 7 Dec 2001 04:47:49 -0500 (EST) 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 fB79mJl06311; Fri, 7 Dec 2001 09:48:20 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 09:47:23 -0000 Message-ID: From: "Cedric Aoun" To: "'Keith Moore'" Cc: "'Scott Brim'" , midcom Subject: RE: [midcom] More than one NAT in Network-friendlier Midcom Date: Fri, 7 Dec 2001 09:47:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17F04.285B18A0" 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_01C17F04.285B18A0 Content-Type: text/plain; charset="iso-8859-1" Keith, point taken I was just proposing a potential solution, Eliot mentioned some of the encountered issues. Thanks for your comment Cedric -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, December 07, 2001 2:07 AM To: Aoun, Cedric [QPD:MA01:EXCH] Cc: 'Scott Brim'; midcom Subject: Re: [midcom] More than one NAT in Network-friendlier Midcom > Potentially the solution could use DNS SRV with an embedded DNS ALG on the > service provider MBs. please don't pollute DNS in an effort to try to solve the NAT problem. NATs cause enough problems as it is without making DNS worse. Keith ------_=_NextPart_001_01C17F04.285B18A0 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] More than one NAT in Network-friendlier Midcom

Keith,
point taken
I was just proposing a potential solution, Eliot mentioned some of the encountered issues.
Thanks for your comment
Cedric
-----Original Message-----
From: Keith Moore [mailto:moore@cs.utk.edu]
Sent: Friday, December 07, 2001 2:07 AM
To: Aoun, Cedric [QPD:MA01:EXCH]
Cc: 'Scott Brim'; midcom
Subject: Re: [midcom] More than one NAT in Network-friendlier Midcom

> Potentially the solution could use DNS SRV with an embedded DNS ALG on the
> service provider MBs.

please don't pollute DNS in an effort to try to solve the NAT problem.
NATs cause enough problems as it is without making DNS worse.

Keith

------_=_NextPart_001_01C17F04.285B18A0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Dec 7 05:17:46 2001 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 FAA17751 for ; Fri, 7 Dec 2001 05:17:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19977 for midcom-archive@odin.ietf.org; Fri, 7 Dec 2001 05:17:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19951; Fri, 7 Dec 2001 05:16:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19875 for ; Fri, 7 Dec 2001 05:16:04 -0500 (EST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17736 for ; Fri, 7 Dec 2001 05:16:01 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fB7AEqd04426; Fri, 7 Dec 2001 05:14:52 -0500 (EST) 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 fB7AFOl13330; Fri, 7 Dec 2001 10:15:24 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 10:14:29 -0000 Message-ID: From: "Cedric Aoun" To: "'Eliot Lear'" Cc: "'Scott Brim'" , midcom Subject: RE: [midcom] More than one NAT in Network-friendlier Midcom Date: Fri, 7 Dec 2001 10:14:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17F07.F21F9820" 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_01C17F07.F21F9820 Content-Type: text/plain; charset="iso-8859-1" Eliot, I agree with all your comments.the solution to the bind dynamics might be to create static binds, but it's quite heavy to maintain. I thought of the cable service provider case, not all of them provide registered addresses to their subscribers. I noticed that many cable service providers provide one private IP address, therefore some subscribers use residential middleboxes. This is one of the exceptions where NAT is applied twice on the packets.This is another scenario that has been troubling me. One could say, why not provide more private addresses to the subscribers, this has obvious operational issues for the ISP network. I'm thinking to do a more detailed analysis on the DNS SRV method impacts. Any volunteers ? To which Randy's presentation are you referring to? thanks Cedric -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com] Sent: Friday, December 07, 2001 7:32 AM To: Aoun, Cedric [QPD:MA01:EXCH] Cc: 'Scott Brim'; midcom Subject: RE: [midcom] More than one NAT in Network-friendlier Midcom I don't know if Sean is on the list, but he did in fact suggest precisely what you mentioned- use DNS SRV records. This has several benefits and several problems. The benefits are that you force consistency in DNS because you can't have a connection without it- that's also bad, by the way, but I'll get to that in a bit. It also has a discovery benefit, in as much as you can have multiple records for multiple NATs within an administrative domain. This gets tricky for concentric NAT but then I've always been of the opinion that if you are going to NAT *always* NAT into public space. I also think that DNS *should* play much more of a role than it does today, so that you can more properly identify the actors, and not just a pool member. Now the problems: as I alluded, placing a connectivity requirement on a functional DNS could lead to certain circular dependencies. However, these dependencies already exist just about any CLIENT, today, and it would be the CLIENT that would have the problem. Getting reverse lookups working would be amusing, to say the least, since you *really* want to resolve both the IP address, and the transport port into a name. Caching semantics here are of concern, as well. If the phone ends up listening for a brief period of time, when it stops you have a problem if your ttl > 0. Lots of gotchas around this one... One problem is the installed base, and that every protocol would have to make use of this record. I'm also unsure of whether operationally DNS is up to this, especially if each phone needs to do lots of transactions (opening ports, closing ports, etc). This to me is a bit unknown. We've all seen Randy's presentation, and I can't fault Keith for worrying about what messes could get created, here. Eliot _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C17F07.F21F9820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] More than one NAT in Network-friendlier = Midcom

Eliot,
I agree with all your comments.the solution to the = bind dynamics might be to create static binds, but it's quite heavy to = maintain.

I thought of the cable service provider case, not all = of them provide registered addresses to their subscribers. I noticed = that many cable service providers provide one private IP address, = therefore some subscribers use residential middleboxes. This is one of = the exceptions where NAT is applied twice on the packets.This is = another scenario that has been troubling me. One could say, why not = provide more private addresses to the subscribers, this has obvious = operational issues for the ISP network.

I'm thinking to do a more detailed analysis on the = DNS SRV method impacts.
Any volunteers ?
To which Randy's presentation are you referring = to?
thanks
Cedric

-----Original Message-----
From: Eliot Lear [mailto:lear@cisco.com]
Sent: Friday, December 07, 2001 7:32 AM
To: Aoun, Cedric [QPD:MA01:EXCH]
Cc: 'Scott Brim'; midcom
Subject: RE: [midcom] More than one NAT in = Network-friendlier Midcom

I don't know if Sean is on the list, but he did in = fact suggest precisely
what you mentioned- use DNS SRV records. This = has several benefits and
several problems. The benefits are that you = force consistency in DNS
because you can't have a connection without it- = that's also bad, by the
way, but I'll get to that in a bit. It also = has a discovery benefit, in as
much as you can have multiple records for multiple = NATs within an
administrative domain. This gets tricky for = concentric NAT but then I've
always been of the opinion that if you are going to = NAT *always* NAT into
public space. I also think that DNS *should* = play much more of a role than
it does today, so that you can more properly = identify the actors, and not
just a pool member.

Now the problems: as I alluded, placing a = connectivity requirement on a
functional DNS could lead to certain circular = dependencies. However, these
dependencies already exist just about any CLIENT, = today, and it would be
the CLIENT that would have the problem. = Getting reverse lookups working
would be amusing, to say the least, since you = *really* want to resolve both
the IP address, and the transport port into a = name. Caching semantics here
are of concern, as well. If the phone ends up = listening for a brief period
of time, when it stops you have a problem if your = ttl > 0. Lots of gotchas
around this one...

One problem is the installed base, and that every = protocol would have to
make use of this record. I'm also unsure of = whether operationally DNS is
up to this, especially if each phone needs to do = lots of transactions
(opening ports, closing ports, etc). This to = me is a bit unknown. We've
all seen Randy's presentation, and I can't fault = Keith for worrying about
what messes could get created, here.

Eliot

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

------_=_NextPart_001_01C17F07.F21F9820-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat Dec 8 18:48:13 2001 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 SAA05526 for ; Sat, 8 Dec 2001 18:48:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04490 for midcom-archive@odin.ietf.org; Sat, 8 Dec 2001 18:48:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04456; Sat, 8 Dec 2001 18:44:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04427 for ; Sat, 8 Dec 2001 18:44:20 -0500 (EST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05476 for ; Sat, 8 Dec 2001 18:44:16 -0500 (EST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id IAA11203; Sun, 9 Dec 2001 08:43:18 +0900 (JST) Received: from pc-pj100h (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id IAA28869; Sun, 9 Dec 2001 08:43:09 +0900 (JST) To: pete@tech-know-ware.com, CEDRIC.AOUN@nortelnetworks.com Cc: midcom@ietf.org Subject: Re: [midcom] FANTOM comments From: Kuniaki Kondo References: <004601c17dad$20b91820$0200000a@tkw> In-Reply-To: <004601c17dad$20b91820$0200000a@tkw> Message-Id: <200112082217.FIJ65643.JJVLOBL@iij.ad.jp> X-Mailer: Winbiff [Version 2.34beta2] X-Accept-Language: ja,en Date: Sun, 9 Dec 2001 08:43:12 +0900 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 Please see comments in-line: > >> From: Cedric Aoun >> >> >> Hi Steve, >> I have some comments on the FANTOM draft, I'm still way behind my mails so >> sorry if my comments have already been posted. >> >> -The FANTOM solution requires 2 devices (the AP and the PEA) one in the >> private network and another one in the Service Provider (or DMZ of the >> enterprise depending on the nature of the service).The AP hosts an >> application proxy, a media proxy and the FANTOM client, the PEA hosts a >> media proxy as well as a FANTOM server. Just by looking at the media proxy >> role, it requires that the host machine has a forwarding rate to meet >VoIP's >> periodicity, assume 10 ms packetisation rate is used you have 100 pps in >and >> a 100 out, in total you will need to relay 200 pps for every single call. >> >> This type of platform doesn't come for free if you have a hundred or more >> calls, we are not talking of a standard workstation. >> In addition the PEA will require much more processing since it will need >to >> handle calls from other private networks. >> I'm assuming that you have a sort of architecture where the FANTOM server >> could be used by several FANTOM clients (I'm talking about channel ids or >> tunnel ids that you might need to use combined with association ids...). I >> understand that you have used the AP to avoid modifying the end host but >at >> what cost. > >Our experiments have shown that we are able to handle media forwarding at >wire speed on 100 Mb Ethernet using ordinary computing hardware. As most >organisations only have a few T1 links to their ISP this is not a particular >burden, and a service provider can easily handle many enterprises with a >single box. If they need more capacity they can simply add more boxes. >FANTOM is designed to scale very well in that respect. Enterprise user indeeded have a few T1 links. If the FANTOM is used for those situation, then I think that it will work. However, All ISP customer might not use FANTOM such as home user. Many ISPs have many thousands of home user or small scale enterprise user. In this situation, ISP should give FANTOM server, and ISP have to transfer enormous traffic through FANTOM server. It may be over some giga bps. How many servers does ISP put on their network? I don't think that this model is scalable. > >> >> Since the end host has already an application client, why don't use the >> application with certain extension to get the binds and refresh them as >well >> as workaround the problem where the signaling is sent to an address >included >> in the signaling message? > >Firstly, there is no reason that FANTOM can not be used on the client. I >think using a separate AP gives a more secure solution for an enterprise >environment and that's why I've pushed it, but integrating the AP with the >client is also perfectly valid. > >The extensions you are talking about are intimately coupled with the >internal workings of the SIP client. SIP is complicated enough without >requiring extra layers of logic to implement NAT traversal. I also don't >want to have to undo all those changes when migrating to midcom. > >On the other hand, when integrated in the client FANTOM can be treated as an >alternative transport layer, and hence all the changes are localised. This >represents good modular design principles. I think this is an essential >quality for when pre-midcom is replaced by midcom. > >> >> -One thing that I found weird is the usage of tunneling by using tcp >> multiplexing, it's a VPN reinvention type of thing. What is the gain? I >> understand that the driver was to reduce the number of pinholes to be >opened >> to allow the signaling to path through the packet filter. BUT this gain is >> really small compared to the number of pinholes required for the media >> flows, therefore I do not see the point for the tunneling. I'm sure that >you >> are aware of the risks of tunneling, the firewall doesn't have the >> capability to snif in the payload of the TCP segments to determine the >type >> of protocols that are transported in the multiplexed channels. >> >> THIS is a BIG HOLE in the corporate security > >No it's not - If you think about it, the problem is caused in part because >the firewall doesn't have the ability to sniff the data in the connections >in the first place. If FANTOM is implemented in the client, this is no >different to any other TCP outbound connection. Hopefully you'll agree that >there is no concern about data sent out. For the data sent in, it is up to >the client how this is interpreted. The format or content of the data >presents no more threat than any other TCP connection that might be >established. > >If you implement the AP as a standalone proxy, then it can implement full >stateful inspection and only allow through what it is happy with. In this >case the firewall and the AP work together to deliver a secure solution. >The firewall ensures that FANTOM only comes from the authorised AP. >Authentication with the PEA is another check that the correct AP is being >used. Various forms of spoofing are also subverted by this dual approach. >How does the administrator know that he/she can trust the AP? Because >he/she put it there. There is no less reason to trust a separate AP than >there is to trust an ALG in a firewall / NAT. (That's why we view it as an >externalised ALG - let's call it an EALG!) > >> >> -The protocol between the AP and the PEA looks really complex and will >need >> at lot of work to get standardized, personally I would prefer building a >> much simpler solution with existing protocols. > >I think the key word here is 'looks'. I think that a working solution based >on FANTOM is no more complex than a working solution based on TURN or the >Sen proposal. Much of the difference is that the complexity of the TURN and >Sen proposals are hidden in the modifications needed to SIP. I believe such >changes will be harder to manage, and harder to test. Also, I feel that >implementors will be reluctant to make such changes if they will later have >to remove them in order to migrate to midcom. The result will be that >pre-midcom doesn't achieve its objective of a quick time to market. > >> >> -I think that the transition solution to move towards Midcom should be >based >> on a mix of using reflectors (such as defined in STUN) in residential and >> SMEs where full cone NATs are predominant, a media intermediary (instead >of >> 2 in your solution) could be used to solve the symmetric NATs that are >> mostly deployed in corporate and in service provider networks. > >If we could use a bunch of established protocols to achieve the result then >I would agree with you. If we are going to have to invent stuff (e.g. STUN >/ TURN / Sen) then we might as well make a good job of it. FANTOM is a >simple one-stop plug in solution to fix the problem. > >> >> Hope I understood your solution. >> Cedric >> Cedric Aoun >> Nortel Networks >> France >> mailto:cedric.aoun@nortelnetworks.com >> > >Pete. > >============================================= >Pete Cordell >Tech-Know-Ware >pete@tech-know-ware.com >+44 1473 635863 >============================================= > > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >http://www1.ietf.org/mailman/listinfo/midcom -- Kuniaki Kondo kuniaki@iij.ad.jp _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Dec 9 21:42:52 2001 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 VAA08571 for ; Sun, 9 Dec 2001 21:42:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA21446 for midcom-archive@odin.ietf.org; Sun, 9 Dec 2001 21:42:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21184; Sun, 9 Dec 2001 21:33:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21159 for ; Sun, 9 Dec 2001 21:33:01 -0500 (EST) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07536 for ; Sun, 9 Dec 2001 21:32:57 -0500 (EST) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.16) with SMTP id M2001121002303003526 for ; Mon, 10 Dec 2001 02:30:30 GMT Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 02:32:24 -0000 Message-ID: <00533D13955AD411AF3800A0C9B42639E92661@ThisAddressDoesNotExist> From: Steve Davies To: midcom@ietf.org Subject: RE: [midcom] pre-midcom requirements and goals Date: Mon, 10 Dec 2001 02:32:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18122.E30EE580" 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_01C18122.E30EE580 Content-Type: text/plain; charset="ISO-8859-1" All, Perhaps the reason we have not been making much progress on a pre-midcom solution is that we have not been discussuing how the candidates meet any underlying requirements. In truth we have no explicit requirements, only goals. However, at an adhoc meeting at the 51st IETF in London (in which 60+ people attended), there seemed to be a consensus (at the time only 1 person voiced disagreement) that a pre-midcom solution should address the following requirements: 1. enable VoIP and MoIP through already deployed firewalls and NATs - no upgrades required 2. protocol agnostic solution - work for SIP, Megaco, H.323, MGCP etc. 3. must be secure in the firewall sense 4. must keep control with the FW/IT administrator (i.e. if he wants to block VoIP, then so be it) 5. should work with any flavours of NAT 6. must allow existing clients/proxies to be unaware of the solution 7. must be compatible with real-time media transport requirements 8. a near term development without inhibiting long term solutions (Midcom/IPV6) 9. not break end-to-end security In addition, the following are stated pre-midcom goals: a. rapid delivery b. consistency with midcom c. consistency with security STUN/TURN: ---------- As specified TURN does not work for H.323. STUN/TURN require changes to SIP to make it work and therfore does not work with existing clients and proxies The TURN solution requires all clients to implement bi-directional, passive RTP, which entails new client behavior to make STUN, TURN and passive RTP decisions. Client and proxy behavioral changes are also required to implement TCP signaling. The need for bi-directional passive RTP becomes obsolete in a Midcom solution as do the client and proxy behavioral changes STUN/TURN entails. By promoting STUN/TURN as a pre-midcom solution the group will be condemning terminal manufacturers and the industry to a lot of churn that may inhibit Midcom uptake. The advantage of TURN over FANTOM and Sen proposals is that in the symmetric NAT or FW/NAT case it can, in theory, half the number of media intermediary hops that the FANTOM/Sen solutions require. However, the saving is really only for inter-service provider calls when all end-points support passive RTP, and only if service providers have the right bi-lateral agreements. For intra-service provider calls, the number of media intermediary hops for all solutions is identical, i.e. 1. The price TURN pays for the media hop saving is that a TURN client must be able to make an outbound UDP connections to any public IP address, so the enterprise firewall must allow it. Many firewall administrators will feel uncomfortable with this sieve-like security policy. Sen and FANTOM can restrict outbound UDP connections to designated intermediaries only. Furthermore, through TURN, an enterprises IP address can easily be discovered through making a call to it. SEN and FANTOM hide enterprise IP addresses which in many quarters is a perceived benefit. In summary, STUN/TURN does not meet requirements 2, 6 and 8 and is the weakest on 3. It is also difficult to see how it meets goals a and b. SEN: ---- Like STUN/TURN, the Sen proposal is SIP specific also requiring bi-directional passive RTP and client and proxy behavioral changes that are obsoleted by Midcom. It does not meet requirements 2, 6 and 8, or goals a and b. FANTOM: ------- FANTOM is the only candidate that meets all these requirements. Architecurally, FANTOM is a natural pre-decessor to Midcom. It fits into the Midcom framework and aligns with many of the Midcom principles. It could even share many of the Midcom protocol methods. FANTOM has been designed with ease of deployment in mind. It can be deployed transparently to all endpoints. In the case of an enterprise, once an AP and PEA are deployed its simply a matter of configuration of firewalls, proxies and endpoints. No protocol changes to SIP,SDP, RTP, H.323 ... are needed. This allows for quick, trouble-free deployment of VoIP and MoIP - today. Having deployed FANTOM, an administrator will have some insight into what is involved in deploying Midcom and they should feel comfortable doing it. They would also perceive benefit (less media hops) in making the migration from FANTOM to Midcom which would be seamless as the FANTOM AP becomes a Midcom Agent. In this context TURN and Sen are radically different concepts and represent separate evolutionary paths. As such they do not prepare an enterprise for a midcom deployment. FANTOM also lends itself to the most scalable secure implementation. Firewall rules can restrict UDP traffic from/to a standalone FANTOM client and well known ports of the FANTOM server. Conversely, if an administrator does not want all clients to be able to make UDP connections to any public host, TURN is not deployable and SEN requires the media intermediary's IP addresses to be pre-specified, which doesn't scale that well. Does the list agree that this is the right sort of criterion by which to compare the candidates, and is the corresponding analysis fair? Steve www.ridgewaysystems.com ------_=_NextPart_001_01C18122.E30EE580 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom requirements and goals

All,

Perhaps the reason we have not been making much = progress on a pre-midcom solution is
that we have not been discussuing how the candidates = meet any underlying requirements.
In truth we have no explicit requirements, only = goals. However, at an adhoc meeting
at the 51st IETF in London (in which 60+ people = attended), there seemed to be a consensus
(at the time only 1 person voiced disagreement) that = a pre-midcom solution should address
the following requirements:

1. enable VoIP and MoIP through already deployed = firewalls and NATs - no upgrades required
2. protocol agnostic solution - work for SIP, = Megaco, H.323, MGCP etc.
3. must be secure in the firewall sense
4. must keep control with the FW/IT administrator = (i.e. if he wants to block VoIP, then so be it)
5. should work with any flavours of NAT
6. must allow existing clients/proxies to be unaware = of the solution
7. must be compatible with real-time media transport = requirements
8. a near term development without inhibiting long = term solutions (Midcom/IPV6)
9. not break end-to-end security

In addition, the following are stated pre-midcom = goals:
a. rapid delivery
b. consistency with midcom
c. consistency with security

STUN/TURN:
----------
As specified TURN does not work for H.323.

STUN/TURN require changes to SIP to make it work and = therfore does not work with existing clients and proxies
The TURN solution requires all clients to implement = bi-directional, passive RTP, which entails new client behavior
to make STUN, TURN and passive RTP decisions. Client = and proxy behavioral changes are also required to implement
TCP signaling.

The need for bi-directional passive RTP becomes = obsolete in a Midcom solution as do the client and proxy behavioral =
changes STUN/TURN entails. By promoting STUN/TURN as = a pre-midcom solution the group will be condemning terminal
manufacturers and the industry to a lot of churn = that may inhibit Midcom uptake.

The advantage of TURN over FANTOM and Sen proposals = is that in the symmetric NAT or FW/NAT case it can,
in theory, half the number of media intermediary = hops that the FANTOM/Sen solutions require. However, the saving
is really only for inter-service provider calls when = all end-points support passive RTP, and only if service = providers
have the right bi-lateral agreements. For = intra-service provider calls, the number of media intermediary hops =
for all solutions is identical, i.e. 1.

The price TURN pays for the media hop saving is that = a TURN client must be able to make an outbound UDP connections
to any public IP address, so the enterprise firewall = must allow it. Many firewall administrators will feel
uncomfortable with this sieve-like security policy. = Sen and FANTOM can restrict outbound UDP connections to
designated intermediaries only. Furthermore, through = TURN, an enterprises IP address can easily be discovered
through making a call to it. SEN and FANTOM hide = enterprise IP addresses which in many quarters is a perceived
benefit.

In summary, STUN/TURN does not meet requirements 2, 6 = and 8 and is the weakest on 3. It is also difficult to see
how it meets goals a and b.

SEN:
----
Like STUN/TURN, the Sen proposal is SIP specific = also requiring bi-directional passive RTP and client and proxy
behavioral changes that are obsoleted by = Midcom.

It does not meet requirements 2, 6 and 8, or goals a = and b.

FANTOM:
-------
FANTOM is the only candidate that meets all these = requirements. Architecurally, FANTOM is a natural pre-decessor
to Midcom. It fits into the Midcom framework and = aligns with many of the Midcom principles. It could even share
many of the Midcom protocol methods.

FANTOM has been designed with ease of deployment in = mind. It can be deployed transparently to all endpoints. In the
case of an enterprise, once an AP and PEA are = deployed its simply a matter of configuration of firewalls,
proxies and endpoints. No protocol changes to = SIP,SDP, RTP, H.323 ... are needed. This allows for quick, = trouble-free
deployment of VoIP and MoIP - today.

Having deployed FANTOM, an administrator will have = some insight into what is involved in deploying Midcom and
they should feel comfortable doing it. They would = also perceive benefit (less media hops) in making the migration
from FANTOM to Midcom which would be seamless as the = FANTOM AP becomes a Midcom Agent. In this context TURN and Sen are =

radically different concepts and represent separate = evolutionary paths. As such they do not prepare an enterprise =
for a midcom deployment.

FANTOM also lends itself to the most scalable secure = implementation. Firewall rules can restrict UDP traffic from/to
a standalone FANTOM client and well known ports of = the FANTOM server. Conversely, if an administrator does not want all = clients to be able to make UDP connections to any public host, = TURN is not deployable and SEN requires the media intermediary's IP = addresses to be pre-specified, which doesn't scale that = well.

Does the list agree that this is the right sort of = criterion by which to compare the candidates, and is the corresponding = analysis fair?

Steve
www.ridgewaysystems.com

------_=_NextPart_001_01C18122.E30EE580-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Dec 10 02:13:26 2001 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 CAA25528 for ; Mon, 10 Dec 2001 02:13:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA07374 for midcom-archive@odin.ietf.org; Mon, 10 Dec 2001 02:13:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07350; Mon, 10 Dec 2001 02:11:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07314 for ; Mon, 10 Dec 2001 02:11:43 -0500 (EST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25249 for ; Mon, 10 Dec 2001 02:11:41 -0500 (EST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id QAA02580; Mon, 10 Dec 2001 16:10:40 +0900 (JST) Received: from pc-pj100h (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id QAA03692; Mon, 10 Dec 2001 16:10:30 +0900 (JST) To: sdavies@ridgewaysystems.com, midcom@ietf.org Cc: nats@ml.canonet.ne.jp, nats@bugest.net Subject: Re: [midcom] pre-midcom requirements and goals From: Kuniaki Kondo References: <00533D13955AD411AF3800A0C9B42639E92661@ThisAddressDoesNotExist> In-Reply-To: <00533D13955AD411AF3800A0C9B42639E92661@ThisAddressDoesNotExist> Message-Id: <200112101610.DIH99376.VJLLJBO@iij.ad.jp> X-Mailer: Winbiff [Version 2.34beta2] X-Accept-Language: ja,en Date: Mon, 10 Dec 2001 16:10:32 +0900 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 Hi, This summary might rise up a nature of midcom. I think that those consensus should reconfirm at tomorrow meeting. Incidentally, this summary did not compare with NATS proposal. Then, I would like to add it. In message <00533D13955AD411AF3800A0C9B42639E92661@ThisAddressDoesNotExist> "RE: [midcom] pre-midcom requirements and goals" "Steve Davies " wrote: >All, > >Perhaps the reason we have not been making much progress on a pre-midcom >solution is >that we have not been discussuing how the candidates meet any underlying >requirements. >In truth we have no explicit requirements, only goals. However, at an adhoc >meeting >at the 51st IETF in London (in which 60+ people attended), there seemed to >be a consensus >(at the time only 1 person voiced disagreement) that a pre-midcom solution >should address >the following requirements: > >1. enable VoIP and MoIP through already deployed firewalls and NATs - no >upgrades required What is the purpose of this issue? If the purpose is 'rapid delivery' then we should concern more about this. Because recent NAT/NAPT router can updates very easily by just firmware upgrade which is released by router vendors. Conversely, If a protocol needs to change already existing application then deployment might be late. >2. protocol agnostic solution - work for SIP, Megaco, H.323, MGCP etc. NATS does not need to change application software. >3. must be secure in the firewall sense NATS is same as NAT/NAPT about security issue. >4. must keep control with the FW/IT administrator (i.e. if he wants to block >VoIP, then so be it) NATS doesn't touch TCP/UDP layer. >5. should work with any flavours of NAT I believe that NATS dose not have any problem about this. However, I need more concern. >6. must allow existing clients/proxies to be unaware of the solution NATS meets this requirement. >7. must be compatible with real-time media transport requirements NATS also meets this requirement. >8. a near term development without inhibiting long term solutions >(Midcom/IPV6) NATS also meets this requirement. >9. not break end-to-end security I don't understand what the purpose is. > >In addition, the following are stated pre-midcom goals: >a. rapid delivery NATS already started implementation. Test code will be released in January or February. >b. consistency with midcom >c. consistency with security I need more concern about those issues. Thank you. > >STUN/TURN: >---------- >As specified TURN does not work for H.323. > >STUN/TURN require changes to SIP to make it work and therfore does not work >with existing clients and proxies >The TURN solution requires all clients to implement bi-directional, passive >RTP, which entails new client behavior >to make STUN, TURN and passive RTP decisions. Client and proxy behavioral >changes are also required to implement >TCP signaling. > >The need for bi-directional passive RTP becomes obsolete in a Midcom >solution as do the client and proxy behavioral >changes STUN/TURN entails. By promoting STUN/TURN as a pre-midcom solution >the group will be condemning terminal >manufacturers and the industry to a lot of churn that may inhibit Midcom >uptake. > >The advantage of TURN over FANTOM and Sen proposals is that in the symmetric >NAT or FW/NAT case it can, >in theory, half the number of media intermediary hops that the FANTOM/Sen >solutions require. However, the saving >is really only for inter-service provider calls when all end-points support >passive RTP, and only if service providers >have the right bi-lateral agreements. For intra-service provider calls, the >number of media intermediary hops >for all solutions is identical, i.e. 1. > >The price TURN pays for the media hop saving is that a TURN client must be >able to make an outbound UDP connections >to any public IP address, so the enterprise firewall must allow it. Many >firewall administrators will feel >uncomfortable with this sieve-like security policy. Sen and FANTOM can >restrict outbound UDP connections to >designated intermediaries only. Furthermore, through TURN, an enterprises IP >address can easily be discovered >through making a call to it. SEN and FANTOM hide enterprise IP addresses >which in many quarters is a perceived >benefit. > >In summary, STUN/TURN does not meet requirements 2, 6 and 8 and is the >weakest on 3. It is also difficult to see >how it meets goals a and b. > >SEN: >---- >Like STUN/TURN, the Sen proposal is SIP specific also requiring >bi-directional passive RTP and client and proxy >behavioral changes that are obsoleted by Midcom. > >It does not meet requirements 2, 6 and 8, or goals a and b. > >FANTOM: >------- >FANTOM is the only candidate that meets all these requirements. >Architecurally, FANTOM is a natural pre-decessor >to Midcom. It fits into the Midcom framework and aligns with many of the >Midcom principles. It could even share >many of the Midcom protocol methods. > >FANTOM has been designed with ease of deployment in mind. It can be deployed >transparently to all endpoints. In the >case of an enterprise, once an AP and PEA are deployed its simply a matter >of configuration of firewalls, >proxies and endpoints. No protocol changes to SIP,SDP, RTP, H.323 ... are >needed. This allows for quick, trouble-free >deployment of VoIP and MoIP - today. > >Having deployed FANTOM, an administrator will have some insight into what is >involved in deploying Midcom and >they should feel comfortable doing it. They would also perceive benefit >(less media hops) in making the migration >from FANTOM to Midcom which would be seamless as the FANTOM AP becomes a >Midcom Agent. In this context TURN and Sen are >radically different concepts and represent separate evolutionary paths. As >such they do not prepare an enterprise >for a midcom deployment. > >FANTOM also lends itself to the most scalable secure implementation. >Firewall rules can restrict UDP traffic from/to >a standalone FANTOM client and well known ports of the FANTOM server. >Conversely, if an administrator does not want all clients to be able to >make UDP connections to any public host, TURN is not deployable and SEN >requires the media intermediary's IP addresses to be pre-specified, which >doesn't scale that well. > > >Does the list agree that this is the right sort of criterion by which to >compare the candidates, and is the corresponding analysis fair? > >Steve >www.ridgewaysystems.com -- Kuniaki Kondo kuniaki@iij.ad.jp _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Dec 10 09:36:45 2001 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 JAA02325 for ; Mon, 10 Dec 2001 09:36:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18885 for midcom-archive@odin.ietf.org; Mon, 10 Dec 2001 09:36:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18804; Mon, 10 Dec 2001 09:33:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18773 for ; Mon, 10 Dec 2001 09:33:05 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02257 for ; Mon, 10 Dec 2001 09:33:03 -0500 (EST) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fBAEWZn27512 for ; Mon, 10 Dec 2001 09:32:35 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh1i.attrh.att.com (5.5.029) id 3C0BA3A5000ACE50; Mon, 10 Dec 2001 09:32:30 -0500 content-class: urn:content-classes:message Subject: RE: [midcom] pre-midcom requirements and goals Date: Mon, 10 Dec 2001 09:32:30 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F978340F@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [midcom] pre-midcom requirements and goals X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcGBI1T6azzeh+0LEdWjbgCQJ60IGQAY4+lQ From: "Roy, Radhika R, ALCTA" To: "Steve Davies" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA18774 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 If the requirements for the pre-MIDCOM solution would have been known, it would provide a baseline to compare all competing solutions. Radhika R. Roy rrroy@att.com -----Original Message----- From: Steve Davies [mailto:sdavies@ridgewaysystems.com] Sent: Sunday, December 09, 2001 9:32 PM To: midcom@ietf.org Subject: RE: [midcom] pre-midcom requirements and goals All, Perhaps the reason we have not been making much progress on a pre-midcom solution is that we have not been discussuing how the candidates meet any underlying requirements. In truth we have no explicit requirements, only goals. However, at an adhoc meeting at the 51st IETF in London (in which 60+ people attended), there seemed to be a consensus (at the time only 1 person voiced disagreement) that a pre-midcom solution should address the following requirements: 1. enable VoIP and MoIP through already deployed firewalls and NATs - no upgrades required 2. protocol agnostic solution - work for SIP, Megaco, H.323, MGCP etc. 3. must be secure in the firewall sense 4. must keep control with the FW/IT administrator (i.e. if he wants to block VoIP, then so be it) 5. should work with any flavours of NAT 6. must allow existing clients/proxies to be unaware of the solution 7. must be compatible with real-time media transport requirements 8. a near term development without inhibiting long term solutions (Midcom/IPV6) 9. not break end-to-end security In addition, the following are stated pre-midcom goals: a. rapid delivery b. consistency with midcom c. consistency with security _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Dec 10 13:45:32 2001 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 NAA08391 for ; Mon, 10 Dec 2001 13:45:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03700 for midcom-archive@odin.ietf.org; Mon, 10 Dec 2001 13:45:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03264; Mon, 10 Dec 2001 13:33:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03234 for ; Mon, 10 Dec 2001 13:33:51 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08128 for ; Mon, 10 Dec 2001 13:33:49 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBAIXBB28897; Mon, 10 Dec 2001 12:33:12 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 12:31:59 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187739@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Steve Davies'" , midcom@ietf.org Subject: RE: [midcom] pre-midcom requirements and goals Date: Mon, 10 Dec 2001 12:32:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C181A8.FAF14810" 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_01C181A8.FAF14810 Content-Type: text/plain; charset="iso-8859-1" Note that the Sen proposal will be henceforth called MINT (MIdcom-unaware firewall/Nat Traversal). Comments inline. -----Original Message----- From: Steve Davies [mailto:sdavies@ridgewaysystems.com] 1. enable VoIP and MoIP through already deployed firewalls and NATs - no upgrades required 2. protocol agnostic solution - work for SIP, Megaco, H.323, MGCP etc. 3. must be secure in the firewall sense 4. must keep control with the FW/IT administrator (i.e. if he wants to block VoIP, then so be it) 5. should work with any flavours of NAT 6. must allow existing clients/proxies to be unaware of the solution 7. must be compatible with real-time media transport requirements 8. a near term development without inhibiting long term solutions (Midcom/IPV6) 9. not break end-to-end security In addition, the following are stated pre-midcom goals: a. rapid delivery b. consistency with midcom c. consistency with security STUN/TURN: ---------- As specified TURN does not work for H.323. Furthermore, through TURN, an enterprises IP address can easily be discovered through making a call to it. SEN and FANTOM hide enterprise IP addresses which in many quarters is a perceived benefit. [SS] Agree on this one as a perceived benefit. In summary, STUN/TURN does not meet requirements 2, 6 and 8 and is the weakest on 3. It is also difficult to see how it meets goals a and b. SEN: ---- Like STUN/TURN, the Sen proposal is SIP specific [SS] The solution is exemplified in the draft with a SIP example. The basic concept of providing a hint to the Signaling Proxy that the client is behind a NAT is NOTHING SIP specific. In the example given, the proposed tag in Proxy-Require header is for providing hint to the Signaling Proxy to route subsequent messages to NAT address bind. This issue is orthogonal to the proposal and will be applicable to any application which has similar requirement. That's all we need. also requiring bi-directional passive RTP and client and proxy behavioral changes that are obsoleted by Midcom. [SS] The fundamental reason why we use symmetric RTP is that it reduces the number of pinholes/binds that need to be opened/maintained in the FW/NAT. I don't see why it won't be useful to reduce this number, even if Midcom is present. As I had said in one of the earlier email, this can be done at the expense of additional overhead - this is equally applicable to all three proposals. It does not meet requirements 2, 6 and 8, or goals a and b. [SS] It actually meets all your requirements: 2) See above 6) The existing clients are totally unaware of the existence of the Media Portal or the interactions between the signaling and media proxies to get the bind. 8) MINT needs the MINIMAL protocol development work among the three proposals & NO new protocol development. There is a clear evolutionary path from MINT to Midocom (replace the Media Proxy with a Middlebox!!) Goal a : The solution is deployed today. How "more rapid" do you want this to be ??!! Goal b: MINT is CLOSEST to Midcom among the 3 proposals. The control protocol between the signaling & media proxies need to be extended slightly to satisfy all the requirements currently proposed by the working group. There is a very clear and efficient evolutionary path from MINT to Midcom. FANTOM also lends itself to the most scalable secure implementation. Firewall rules can restrict UDP traffic from/to a standalone FANTOM client and well known ports of the FANTOM server. Conversely, if an administrator does not want all clients to be able to make UDP connections to any public host, TURN is not deployable and SEN requires the media intermediary's IP addresses to be pre-specified, which doesn't scale that well. [SS] Any policy which allows UDP packets from a set of IP address/port (which are not in response to packets send out to that address) to enter through a FW is a deviation from standard policy and WILL BE prone to security attacks. MINT DOES NOT require the media intermediary's IP address to be pre-specified for the purpose of firewall adminitration, as claimed above. Another benefit of MINT from the security p.o.v is that the port binds are allocated at the Intermediary (Media proxy) at the request of the signaling proxy only (which assumes a trusted relationship between the signaling proxy and the intermediary, which is what Midcom is driving at). This again shows the proximity of MINT to Midcom. Sanjoy ------_=_NextPart_001_01C181A8.FAF14810 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] pre-midcom requirements and goals

Note that the Sen proposal will be henceforth called MINT (MIdcom-unaware firewall/Nat Traversal).

Comments inline.

-----Original Message-----
From: Steve Davies [mailto:sdavies@ridgewaysystems.com]

<snipped>

1. enable VoIP and MoIP through already deployed firewalls and NATs - no upgrades required
2. protocol agnostic solution - work for SIP, Megaco, H.323, MGCP etc.
3. must be secure in the firewall sense
4. must keep control with the FW/IT administrator (i.e. if he wants to block VoIP, then so be it)
5. should work with any flavours of NAT
6. must allow existing clients/proxies to be unaware of the solution
7. must be compatible with real-time media transport requirements
8. a near term development without inhibiting long term solutions (Midcom/IPV6)
9. not break end-to-end security

In addition, the following are stated pre-midcom goals:
a. rapid delivery
b. consistency with midcom
c. consistency with security

STUN/TURN:
----------
As specified TURN does not work for H.323.

<snipped>

Furthermore, through TURN, an enterprises IP address can easily be discovered
through making a call to it. SEN and FANTOM hide enterprise IP addresses which in many quarters is a perceived
benefit.

[SS] Agree on this one as a perceived benefit.

In summary, STUN/TURN does not meet requirements 2, 6 and 8 and is the weakest on 3. It is also difficult to see
how it meets goals a and b.

SEN:
----
Like STUN/TURN, the Sen proposal is SIP specific

[SS] The solution is exemplified in the draft with a SIP example. The basic concept of providing a hint to the Signaling Proxy that the client is behind a NAT is NOTHING SIP specific. In the example given, the proposed tag in Proxy-Require header is for providing hint to the Signaling Proxy to route subsequent messages to NAT address bind. This issue is orthogonal to the proposal and will be applicable to any application which has similar requirement.

That's all we need.

also requiring bi-directional passive RTP and client and proxy
behavioral changes that are obsoleted by Midcom.

[SS] The fundamental reason why we use symmetric RTP is that it reduces the number of pinholes/binds that need to be opened/maintained in the FW/NAT. I don't see why it won't be useful to reduce this number, even if Midcom is present. As I had said in one of the earlier email, this can be done at the expense of additional overhead - this is equally applicable to all three proposals.

It does not meet requirements 2, 6 and 8, or goals a and b.

[SS] It actually meets all your requirements:

2) See above

6) The existing clients are totally unaware of the existence of the Media Portal or the interactions between the signaling and media proxies to get the bind.

8) MINT needs the MINIMAL protocol development work among the three proposals & NO new protocol development. There is a clear evolutionary path from MINT to Midocom (replace the Media Proxy with a Middlebox!!)

Goal a : The solution is deployed today. How "more rapid" do you want this to be ??!!

Goal b: MINT is CLOSEST to Midcom among the 3 proposals. The control protocol between the signaling & media proxies need to be extended slightly to satisfy all the requirements currently proposed by the working group. There is a very clear and efficient evolutionary path from MINT to Midcom.

<snipped>

FANTOM also lends itself to the most scalable secure implementation. Firewall rules can restrict UDP traffic from/to
a standalone FANTOM client and well known ports of the FANTOM server. Conversely, if an administrator does not want all clients to be able to make UDP connections to any public host, TURN is not deployable and SEN requires the media intermediary's IP addresses to be pre-specified, which doesn't scale that well.

[SS] Any policy which allows UDP packets from a set of IP address/port (which are not in response to packets send out to that address) to enter through a FW is a deviation from standard policy and WILL BE prone to security attacks. MINT DOES NOT require the media intermediary's IP address to be pre-specified for the purpose of firewall adminitration, as claimed above. Another benefit of MINT from the security p.o.v is that the port binds are allocated at the Intermediary (Media proxy) at the request of the signaling proxy only (which assumes a trusted relationship between the signaling proxy and the intermediary, which is what Midcom is driving at). This again shows the proximity of MINT to Midcom.

Sanjoy

------_=_NextPart_001_01C181A8.FAF14810-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Dec 10 16:23:30 2001 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 QAA11862 for ; Mon, 10 Dec 2001 16:23:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09961 for midcom-archive@odin.ietf.org; Mon, 10 Dec 2001 16:23:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09835; Mon, 10 Dec 2001 16:16:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09806 for ; Mon, 10 Dec 2001 16:16:47 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11687 for ; Mon, 10 Dec 2001 16:16:44 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GO500F2YCEZAQ@firewall.wcom.com> for midcom@ietf.org; Mon, 10 Dec 2001 21:16:11 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0GO500A01CEWWQ@pmismtp02.wcomnet.com>; Mon, 10 Dec 2001 21:16:11 +0000 (GMT) Received: from rccc6131 ([166.35.225.51]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0GO5008HLCEHGI@pmismtp02.wcomnet.com>; Mon, 10 Dec 2001 21:15:54 +0000 (GMT) Date: Mon, 10 Dec 2001 15:15:28 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] FANTOM comments In-reply-to: <200112082217.FIJ65643.JJVLOBL@iij.ad.jp> To: "'Kuniaki Kondo'" , pete@tech-know-ware.com, CEDRIC.AOUN@nortelnetworks.com Cc: midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <005401c181bf$cb67d200$33e123a6@rccc6131.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Since we are trying to resolve an enterprise issue right now, I thought, why mention the home user? > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Kuniaki Kondo > Sent: Saturday, December 08, 2001 5:43 PM > To: pete@tech-know-ware.com; CEDRIC.AOUN@nortelnetworks.com > Cc: midcom@ietf.org > Subject: Re: [midcom] FANTOM comments > > > Please see comments in-line: > > > > >> From: Cedric Aoun > >> > >> > >> Hi Steve, > >> I have some comments on the FANTOM draft, I'm still way > behind my mails so > >> sorry if my comments have already been posted. > >> > >> -The FANTOM solution requires 2 devices (the AP and the > PEA) one in the > >> private network and another one in the Service Provider > (or DMZ of the > >> enterprise depending on the nature of the service).The AP hosts an > >> application proxy, a media proxy and the FANTOM client, > the PEA hosts a > >> media proxy as well as a FANTOM server. Just by looking at > the media proxy > >> role, it requires that the host machine has a forwarding > rate to meet > >VoIP's > >> periodicity, assume 10 ms packetisation rate is used you > have 100 pps in > >and > >> a 100 out, in total you will need to relay 200 pps for > every single call. > >> > >> This type of platform doesn't come for free if you have a > hundred or more > >> calls, we are not talking of a standard workstation. > >> In addition the PEA will require much more processing > since it will need > >to > >> handle calls from other private networks. > >> I'm assuming that you have a sort of architecture where > the FANTOM server > >> could be used by several FANTOM clients (I'm talking about > channel ids or > >> tunnel ids that you might need to use combined with > association ids...). I > >> understand that you have used the AP to avoid modifying > the end host but > >at > >> what cost. > > > >Our experiments have shown that we are able to handle media > forwarding at > >wire speed on 100 Mb Ethernet using ordinary computing > hardware. As most > >organisations only have a few T1 links to their ISP this is > not a particular > >burden, and a service provider can easily handle many > enterprises with a > >single box. If they need more capacity they can simply add > more boxes. > >FANTOM is designed to scale very well in that respect. > > Enterprise user indeeded have a few T1 links. If the FANTOM is used > for those situation, then I think that it will work. > However, All ISP customer might not use FANTOM such as home user. > Many ISPs have many thousands of home user or small scale enterprise > user. In this situation, ISP should give FANTOM server, and > ISP have to transfer enormous traffic through FANTOM server. > It may be over some giga bps. How many servers does ISP put on > their network? I don't think that this model is scalable. > > > > >> > >> Since the end host has already an application client, why > don't use the > >> application with certain extension to get the binds and > refresh them as > >well > >> as workaround the problem where the signaling is sent to an address > >included > >> in the signaling message? > > > >Firstly, there is no reason that FANTOM can not be used on > the client. I > >think using a separate AP gives a more secure solution for > an enterprise > >environment and that's why I've pushed it, but integrating > the AP with the > >client is also perfectly valid. > > > >The extensions you are talking about are intimately coupled with the > >internal workings of the SIP client. SIP is complicated > enough without > >requiring extra layers of logic to implement NAT traversal. > I also don't > >want to have to undo all those changes when migrating to midcom. > > > >On the other hand, when integrated in the client FANTOM can > be treated as an > >alternative transport layer, and hence all the changes are > localised. This > >represents good modular design principles. I think this is > an essential > >quality for when pre-midcom is replaced by midcom. > > > >> > >> -One thing that I found weird is the usage of tunneling by > using tcp > >> multiplexing, it's a VPN reinvention type of thing. What > is the gain? I > >> understand that the driver was to reduce the number of > pinholes to be > >opened > >> to allow the signaling to path through the packet filter. > BUT this gain is > >> really small compared to the number of pinholes required > for the media > >> flows, therefore I do not see the point for the tunneling. > I'm sure that > >you > >> are aware of the risks of tunneling, the firewall doesn't have the > >> capability to snif in the payload of the TCP segments to > determine the > >type > >> of protocols that are transported in the multiplexed channels. > >> > >> THIS is a BIG HOLE in the corporate security > > > >No it's not - If you think about it, the problem is caused > in part because > >the firewall doesn't have the ability to sniff the data in > the connections > >in the first place. If FANTOM is implemented in the client, > this is no > >different to any other TCP outbound connection. Hopefully > you'll agree that > >there is no concern about data sent out. For the data sent > in, it is up to > >the client how this is interpreted. The format or content > of the data > >presents no more threat than any other TCP connection that might be > >established. > > > >If you implement the AP as a standalone proxy, then it can > implement full > >stateful inspection and only allow through what it is happy > with. In this > >case the firewall and the AP work together to deliver a > secure solution. > >The firewall ensures that FANTOM only comes from the authorised AP. > >Authentication with the PEA is another check that the > correct AP is being > >used. Various forms of spoofing are also subverted by this > dual approach. > >How does the administrator know that he/she can trust the > AP? Because > >he/she put it there. There is no less reason to trust a > separate AP than > >there is to trust an ALG in a firewall / NAT. (That's why > we view it as an > >externalised ALG - let's call it an EALG!) > > > >> > >> -The protocol between the AP and the PEA looks really > complex and will > >need > >> at lot of work to get standardized, personally I would > prefer building a > >> much simpler solution with existing protocols. > > > >I think the key word here is 'looks'. I think that a > working solution based > >on FANTOM is no more complex than a working solution based > on TURN or the > >Sen proposal. Much of the difference is that the complexity > of the TURN and > >Sen proposals are hidden in the modifications needed to SIP. > I believe such > >changes will be harder to manage, and harder to test. Also, > I feel that > >implementors will be reluctant to make such changes if they > will later have > >to remove them in order to migrate to midcom. The result > will be that > >pre-midcom doesn't achieve its objective of a quick time to market. > > > >> > >> -I think that the transition solution to move towards > Midcom should be > >based > >> on a mix of using reflectors (such as defined in STUN) in > residential and > >> SMEs where full cone NATs are predominant, a media > intermediary (instead > >of > >> 2 in your solution) could be used to solve the symmetric > NATs that are > >> mostly deployed in corporate and in service provider networks. > > > >If we could use a bunch of established protocols to achieve > the result then > >I would agree with you. If we are going to have to invent > stuff (e.g. STUN > >/ TURN / Sen) then we might as well make a good job of it. > FANTOM is a > >simple one-stop plug in solution to fix the problem. > > > >> > >> Hope I understood your solution. > >> Cedric > >> Cedric Aoun > >> Nortel Networks > >> France > >> mailto:cedric.aoun@nortelnetworks.com > >> > > > >Pete. > > > >============================================= > >Pete Cordell > >Tech-Know-Ware > >pete@tech-know-ware.com > >+44 1473 635863 > >============================================= > > > > > > > >_______________________________________________ > >midcom mailing list > >midcom@ietf.org > >http://www1.ietf.org/mailman/listinfo/midcom > > > -- > Kuniaki Kondo > kuniaki@iij.ad.jp > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Dec 10 18:25:51 2001 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 SAA14498 for ; Mon, 10 Dec 2001 18:25:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA15989 for midcom-archive@odin.ietf.org; Mon, 10 Dec 2001 18:25:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15950; Mon, 10 Dec 2001 18:23:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15873 for ; Mon, 10 Dec 2001 18:23:54 -0500 (EST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14459 for ; Mon, 10 Dec 2001 18:23:44 -0500 (EST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id IAA16816; Tue, 11 Dec 2001 08:22:46 +0900 (JST) Received: from pc-pj100h (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id IAA03194; Tue, 11 Dec 2001 08:22:45 +0900 (JST) To: christopher.a.martin@wcom.com, kuniaki@iij.ad.jp, pete@tech-know-ware.com, CEDRIC.AOUN@nortelnetworks.com Cc: midcom@ietf.org Subject: Re: [midcom] FANTOM comments From: Kuniaki Kondo References: <200112082217.FIJ65643.JJVLOBL@iij.ad.jp> <005401c181bf$cb67d200$33e123a6@rccc6131.mcit.com> In-Reply-To: <005401c181bf$cb67d200$33e123a6@rccc6131.mcit.com> Message-Id: <200112110822.GHG29368.OJLVLJB@iij.ad.jp> X-Mailer: Winbiff [Version 2.34beta2] X-Accept-Language: ja,en Date: Tue, 11 Dec 2001 08:22:47 +0900 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 In message <005401c181bf$cb67d200$33e123a6@rccc6131.mcit.com> "RE: [midcom] FANTOM comments" ""Christopher A. Martin" " wrote: >Since we are trying to resolve an enterprise issue right now, I thought, why >mention the home user? Firstly, my wording was not better. Home user, I mean small scale network user who uses 1 segment in their network. Thus, it includes "small enterprise user". Could you explain how size is enterprise network? I said in 2 or 3 previous mail that FANTOM,STUN or TURN might be good for enterprise network. It means that some enterprize might be able to buy a those server and be able to put the server on thier network. However, ISP's traffic is more enourmous than enterprise one. In that situation, ISPs might abhor to put those servers, becasue those server collects enourmous traffic. > > > >> -----Original Message----- >> From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of >> Kuniaki Kondo >> Sent: Saturday, December 08, 2001 5:43 PM >> To: pete@tech-know-ware.com; CEDRIC.AOUN@nortelnetworks.com >> Cc: midcom@ietf.org >> Subject: Re: [midcom] FANTOM comments >> >> >> Please see comments in-line: >> >> > >> >> From: Cedric Aoun >> >> >> >> >> >> Hi Steve, >> >> I have some comments on the FANTOM draft, I'm still way >> behind my mails so >> >> sorry if my comments have already been posted. >> >> >> >> -The FANTOM solution requires 2 devices (the AP and the >> PEA) one in the >> >> private network and another one in the Service Provider >> (or DMZ of the >> >> enterprise depending on the nature of the service).The AP hosts an >> >> application proxy, a media proxy and the FANTOM client, >> the PEA hosts a >> >> media proxy as well as a FANTOM server. Just by looking at >> the media proxy >> >> role, it requires that the host machine has a forwarding >> rate to meet >> >VoIP's >> >> periodicity, assume 10 ms packetisation rate is used you >> have 100 pps in >> >and >> >> a 100 out, in total you will need to relay 200 pps for >> every single call. >> >> >> >> This type of platform doesn't come for free if you have a >> hundred or more >> >> calls, we are not talking of a standard workstation. >> >> In addition the PEA will require much more processing >> since it will need >> >to >> >> handle calls from other private networks. >> >> I'm assuming that you have a sort of architecture where >> the FANTOM server >> >> could be used by several FANTOM clients (I'm talking about >> channel ids or >> >> tunnel ids that you might need to use combined with >> association ids...). I >> >> understand that you have used the AP to avoid modifying >> the end host but >> >at >> >> what cost. >> > >> >Our experiments have shown that we are able to handle media >> forwarding at >> >wire speed on 100 Mb Ethernet using ordinary computing >> hardware. As most >> >organisations only have a few T1 links to their ISP this is >> not a particular >> >burden, and a service provider can easily handle many >> enterprises with a >> >single box. If they need more capacity they can simply add >> more boxes. >> >FANTOM is designed to scale very well in that respect. >> >> Enterprise user indeeded have a few T1 links. If the FANTOM is used >> for those situation, then I think that it will work. >> However, All ISP customer might not use FANTOM such as home user. >> Many ISPs have many thousands of home user or small scale enterprise >> user. In this situation, ISP should give FANTOM server, and >> ISP have to transfer enormous traffic through FANTOM server. >> It may be over some giga bps. How many servers does ISP put on >> their network? I don't think that this model is scalable. >> >> > >> >> >> >> Since the end host has already an application client, why >> don't use the >> >> application with certain extension to get the binds and >> refresh them as >> >well >> >> as workaround the problem where the signaling is sent to an address >> >included >> >> in the signaling message? >> > >> >Firstly, there is no reason that FANTOM can not be used on >> the client. I >> >think using a separate AP gives a more secure solution for >> an enterprise >> >environment and that's why I've pushed it, but integrating >> the AP with the >> >client is also perfectly valid. >> > >> >The extensions you are talking about are intimately coupled with the >> >internal workings of the SIP client. SIP is complicated >> enough without >> >requiring extra layers of logic to implement NAT traversal. >> I also don't >> >want to have to undo all those changes when migrating to midcom. >> > >> >On the other hand, when integrated in the client FANTOM can >> be treated as an >> >alternative transport layer, and hence all the changes are >> localised. This >> >represents good modular design principles. I think this is >> an essential >> >quality for when pre-midcom is replaced by midcom. >> > >> >> >> >> -One thing that I found weird is the usage of tunneling by >> using tcp >> >> multiplexing, it's a VPN reinvention type of thing. What >> is the gain? I >> >> understand that the driver was to reduce the number of >> pinholes to be >> >opened >> >> to allow the signaling to path through the packet filter. >> BUT this gain is >> >> really small compared to the number of pinholes required >> for the media >> >> flows, therefore I do not see the point for the tunneling. >> I'm sure that >> >you >> >> are aware of the risks of tunneling, the firewall doesn't have the >> >> capability to snif in the payload of the TCP segments to >> determine the >> >type >> >> of protocols that are transported in the multiplexed channels. >> >> >> >> THIS is a BIG HOLE in the corporate security >> > >> >No it's not - If you think about it, the problem is caused >> in part because >> >the firewall doesn't have the ability to sniff the data in >> the connections >> >in the first place. If FANTOM is implemented in the client, >> this is no >> >different to any other TCP outbound connection. Hopefully >> you'll agree that >> >there is no concern about data sent out. For the data sent >> in, it is up to >> >the client how this is interpreted. The format or content >> of the data >> >presents no more threat than any other TCP connection that might be >> >established. >> > >> >If you implement the AP as a standalone proxy, then it can >> implement full >> >stateful inspection and only allow through what it is happy >> with. In this >> >case the firewall and the AP work together to deliver a >> secure solution. >> >The firewall ensures that FANTOM only comes from the authorised AP. >> >Authentication with the PEA is another check that the >> correct AP is being >> >used. Various forms of spoofing are also subverted by this >> dual approach. >> >How does the administrator know that he/she can trust the >> AP? Because >> >he/she put it there. There is no less reason to trust a >> separate AP than >> >there is to trust an ALG in a firewall / NAT. (That's why >> we view it as an >> >externalised ALG - let's call it an EALG!) >> > >> >> >> >> -The protocol between the AP and the PEA looks really >> complex and will >> >need >> >> at lot of work to get standardized, personally I would >> prefer building a >> >> much simpler solution with existing protocols. >> > >> >I think the key word here is 'looks'. I think that a >> working solution based >> >on FANTOM is no more complex than a working solution based >> on TURN or the >> >Sen proposal. Much of the difference is that the complexity >> of the TURN and >> >Sen proposals are hidden in the modifications needed to SIP. >> I believe such >> >changes will be harder to manage, and harder to test. Also, >> I feel that >> >implementors will be reluctant to make such changes if they >> will later have >> >to remove them in order to migrate to midcom. The result >> will be that >> >pre-midcom doesn't achieve its objective of a quick time to market. >> > >> >> >> >> -I think that the transition solution to move towards >> Midcom should be >> >based >> >> on a mix of using reflectors (such as defined in STUN) in >> residential and >> >> SMEs where full cone NATs are predominant, a media >> intermediary (instead >> >of >> >> 2 in your solution) could be used to solve the symmetric >> NATs that are >> >> mostly deployed in corporate and in service provider networks. >> > >> >If we could use a bunch of established protocols to achieve >> the result then >> >I would agree with you. If we are going to have to invent >> stuff (e.g. STUN >> >/ TURN / Sen) then we might as well make a good job of it. >> FANTOM is a >> >simple one-stop plug in solution to fix the problem. >> > >> >> >> >> Hope I understood your solution. >> >> Cedric >> >> Cedric Aoun >> >> Nortel Networks >> >> France >> >> mailto:cedric.aoun@nortelnetworks.com >> >> >> > >> >Pete. >> > >> >============================================= >> >Pete Cordell >> >Tech-Know-Ware >> >pete@tech-know-ware.com >> >+44 1473 635863 >> >============================================= >> > >> > >> > >> >_______________________________________________ >> >midcom mailing list >> >midcom@ietf.org >> >http://www1.ietf.org/mailman/listinfo/midcom >> >> >> -- >> Kuniaki Kondo >> kuniaki@iij.ad.jp >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> http://www1.ietf.org/mailman/listinfo/midcom >> > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >http://www1.ietf.org/mailman/listinfo/midcom -- Kuniaki Kondo kuniaki@iij.ad.jp _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Dec 11 13:28:46 2001 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 NAA22288 for ; Tue, 11 Dec 2001 13:28:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03824 for midcom-archive@odin.ietf.org; Tue, 11 Dec 2001 13:28:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03747; Tue, 11 Dec 2001 13:25:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03718 for ; Tue, 11 Dec 2001 13:25:54 -0500 (EST) Received: from localhost ([211.212.14.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22235 for ; Tue, 11 Dec 2001 13:25:41 -0500 (EST) Message-Id: <200112111825.NAA22235@ietf.org> Reply-To: e030@chinku.co.kr From: ģ��Ŀ�´��̼� To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 12 Dec 2001 03:26:09 +0900 Subject: [midcom] ��۸��ϵ� �� ̺�Ʈ��ǰ�� Ÿ��!(��) 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 event mail


ȭ��Ʈ X-mas	��³�
�� ̸�� !

ũ�� ȥ�� ܷӰ� ��
��귯�꿡�� ã��! ^-^*

��	�Ϸ翡 �ѹ�� ȸ! �� ǿ� ��÷�� ִٱ�~
��	�޷¹��ȭ��, ��Ų�� ̹�� ٸ��!
��	�� ϴ� �� 븦 �� ȭ�� ~
��	�� Ȩ�� ڶ��ϰ� �ʹٱ�? �׷� ģ�� ڶ��غ�!

�� ġ ��ø� �̸�� Է��ϰ� ��Űź� ��ư�� ʽÿ�

_______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Sun Dec 16 15:35:24 2001 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 PAA04526 for ; Sun, 16 Dec 2001 15:35:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01517 for midcom-archive@odin.ietf.org; Sun, 16 Dec 2001 15:35:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01012; Sun, 16 Dec 2001 15:28:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00983 for ; Sun, 16 Dec 2001 15:28:08 -0500 (EST) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04441 for ; Sun, 16 Dec 2001 15:28:05 -0500 (EST) Received: from 208-59-158-53.c3-0.snmt-ubr2.sfrn-snmt.ca.cable.rcn.com ([208.59.158.53] helo=tnpfrancis) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.33 #10) id 16FhtD-0005vd-00 for midcom@ietf.org; Sun, 16 Dec 2001 15:28:03 -0500 Message-ID: <004601c18670$2978b440$af010a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: References: <933FADF5E673D411B8A30002A5608A0E01187739@zrc2c012.us.nortel.com> Date: Sun, 16 Dec 2001 12:28:02 -0800 Organization: Tahoe Networks MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [midcom] any word on IAB pre-midcom deliberations??? 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 RE: [midcom] pre-midcom requirements and goalsI wasn't around Thursday night, so am wondering what the IAB had to say about pre-midcom stuff? PF _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Sun Dec 16 16:18:08 2001 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 QAA04723 for ; Sun, 16 Dec 2001 16:18:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02253 for midcom-archive@odin.ietf.org; Sun, 16 Dec 2001 16:18:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02222; Sun, 16 Dec 2001 16:16:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02193 for ; Sun, 16 Dec 2001 16:16:44 -0500 (EST) 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 QAA04714 for ; Sun, 16 Dec 2001 16:16:42 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBGLGEp17491; Sun, 16 Dec 2001 13:16:14 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACG86919; Sun, 16 Dec 2001 13:15:19 -0800 (PST) Message-Id: <5.1.0.14.0.20011216161708.00a556a0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 16 Dec 2001 16:19:07 -0500 To: "Paul Francis" , From: Melinda Shore Subject: Re: [midcom] any word on IAB pre-midcom deliberations??? In-Reply-To: <004601c18670$2978b440$af010a0a@tahoenetworks.com> References: <933FADF5E673D411B8A30002A5608A0E01187739@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 12:28 PM 12/16/01 -0800, Paul Francis wrote: >RE: [midcom] pre-midcom requirements and goalsI wasn't around Thursday >night, so am wondering what the IAB had to say about pre-midcom stuff? It didn't come up explicitly, but I'd say that there were some implications for us from the OPES considerations discussion. You may want to take a look at Sally Floyd's slides from the session: http://www.aciri.org/floyd/talks/plenary.Dec13.ps or http://www.aciri.org/floyd/talks/plenary.Dec13.pdf Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Dec 18 15:17:51 2001 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 PAA25950 for ; Tue, 18 Dec 2001 15:17:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06347 for midcom-archive@odin.ietf.org; Tue, 18 Dec 2001 15:17:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06108; Tue, 18 Dec 2001 15:06:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06077 for ; Tue, 18 Dec 2001 15:06:03 -0500 (EST) 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 PAA25675 for ; Tue, 18 Dec 2001 15:05:58 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBIK5VG28443 for ; Tue, 18 Dec 2001 12:05:31 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACH36371; Tue, 18 Dec 2001 12:04:35 -0800 (PST) Message-Id: <5.1.0.14.0.20011218150607.00a50110@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Dec 2001 15:08:22 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Requirements and framework 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 If you go to the midcom web page at the IETF you'll see that the requirements and framework documents are now marked as "Done." Again, many thanks to everybody who helped out with producing these documents, whether it was contributing text or providing input during discussions. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Dec 19 10:14:57 2001 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 KAA29201 for ; Wed, 19 Dec 2001 10:14:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA16152 for midcom-archive@odin.ietf.org; Wed, 19 Dec 2001 10:14:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15516; Wed, 19 Dec 2001 10:03:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15486 for ; Wed, 19 Dec 2001 10:03:12 -0500 (EST) 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 KAA28896 for ; Wed, 19 Dec 2001 10:03:08 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fBJF2fL16723 for ; Wed, 19 Dec 2001 07:02:41 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACH58699; Wed, 19 Dec 2001 07:01:46 -0800 (PST) Message-Id: <5.1.0.14.0.20011219100437.00a767a0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Dec 2001 10:05:34 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Fwd: draft-ietf-midcom-requirements-04.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 To keep you posted on progress ... >Date: Tue, 18 Dec 2001 21:00:44 -0500 (EST) >From: Scott Bradner >To: mankin@isi.edu, mshore@cisco.com >Subject: draft-ietf-midcom-requirements-04.txt > > >please share this with teh ID authors (and the mailing list if you want to) > >the ID looks good but IETF rules require that there be a section in RFCs >titled "Security Considerations" - > >This can be done in this ID by having a Security Considerations section that >says > "The secrity requirements for a midcom protocol are discissed in sec 2.3." > >since the ID has to be redone to fix the above please have the references >section redone to split normative and non-normative references - see the >RFC-Editor's web page for instructions. > >Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Dec 20 11:15:47 2001 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 LAA10884 for ; Thu, 20 Dec 2001 11:15:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15816 for midcom-archive@odin.ietf.org; Thu, 20 Dec 2001 11:15:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15650; Thu, 20 Dec 2001 11:10:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15623 for ; Thu, 20 Dec 2001 11:10:40 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10667; Thu, 20 Dec 2001 11:10:37 -0500 (EST) Message-Id: <200112201610.LAA10667@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: Thu, 20 Dec 2001 11:10:36 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-framework-06.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communication Architecture and framework Author(s) : P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan Filename : draft-ietf-midcom-framework-06.txt Pages : 35 Date : 17-Dec-01 There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications such as SIP and H.323 and peer-to-peer applications such as Napster and NetMeeting cannot be identified by merely examining packet headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-06.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-framework-06.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-framework-06.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: <20011217141603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-framework-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011217141603.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Dec 21 07:45:36 2001 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 HAA22990 for ; Fri, 21 Dec 2001 07:45:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01059 for midcom-archive@odin.ietf.org; Fri, 21 Dec 2001 07:45:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00522; Fri, 21 Dec 2001 07:42:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00483 for ; Fri, 21 Dec 2001 07:42:47 -0500 (EST) Received: from parajura.ns.parajura.net ([61.79.230.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22809 for ; Fri, 21 Dec 2001 07:42:43 -0500 (EST) Received: from m8f4n7 (unverified [211.41.61.1]) by parajura.ns.parajura.net (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 21 Dec 2001 21:26:37 +0900 Message-ID: From: =?ks_c_5601-1987?B?x9G8rrrA?= To: midcom@ietf.org Date: Fri, 21 Dec 2001 09:33:03 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01C0F21A.93A33C00" X-Priority: 3 Subject: [midcom] =?ks_c_5601-1987?B?W8GkurhdIKHaILXltvPAzLrqIMTavbogvsizuw==?= 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_0097_01C0F21A.93A33C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Ojo6Ojo6OiDD38O1ISC15bbzwMy66sTavbogOjo6Ojo6OiAgICAgICAgICAgICAgICAgICAg ICAgICA= ------=_NextPart_000_0097_01C0F21A.93A33C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT46Ojo6Ojo6IMPfw7UhILXltvPAzLrqxNq9uiA6Ojo6 Ojo6PC90aXRsZT4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQoNCjxib2R5IGJnY29sb3I9 IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiIGxlZnRtYXJnaW49IjAiIHRvcG1hcmdpbj0iMCI+ DQo8dGFibGUgd2lkdGg9IjYwMCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBh ZGRpbmc9IjAiPg0KICA8dHI+DQogICAgPHRkIHZhbGlnbj0idG9wIj48aW1nIHNyYz0iaHR0 cDovL3BhcmFqdXJhLmNvbS9zcF9tYWlsL2ltYWdlL2RyaXZlY291cnNlMV8xLmdpZiIgd2lk dGg9IjYwMCIgaGVpZ2h0PSI4MiI+PC90ZD4NCiAgPC90cj4NCiAgPHRyPg0KICAgIDx0ZCB2 YWxpZ249InRvcCI+PGltZyBzcmM9Imh0dHA6Ly9wYXJhanVyYS5jb20vc3BfbWFpbC9pbWFn ZS9kcml2ZWNvdXJzZTFfMi5naWYiIHdpZHRoPSI2MDAiIGhlaWdodD0iMTY1Ij48L3RkPg0K ICA8L3RyPg0KICA8dHI+DQogICAgPHRkIHZhbGlnbj0idG9wIj48aW1nIHNyYz0iaHR0cDov L3BhcmFqdXJhLmNvbS9zcF9tYWlsL2ltYWdlL2RyaXZlY291cnNlMV8zLmdpZiIgd2lkdGg9 IjYwMCIgaGVpZ2h0PSIyMDMiIHVzZW1hcD0iI01hcDIiIGJvcmRlcj0iMCI+PC90ZD4NCiAg PC90cj4NCiAgPHRyPg0KICAgIDx0ZCB2YWxpZ249InRvcCI+PGltZyBzcmM9Imh0dHA6Ly9w YXJhanVyYS5jb20vc3BfbWFpbC9pbWFnZS9kcml2ZWNvdXJzZTFfNC5naWYiIHdpZHRoPSI2 MDAiIGhlaWdodD0iMjEiIHVzZW1hcD0iI01hcCIgYm9yZGVyPSIwIj48L3RkPg0KICA8L3Ry Pg0KICA8dHI+DQogICAgPHRkIHZhbGlnbj0idG9wIj48aW1nIHNyYz0iaHR0cDovL3BhcmFq dXJhLmNvbS9zcF9tYWlsL2ltYWdlL2RyaXZlY291cnNlMV81LmdpZiIgd2lkdGg9IjYwMCIg aGVpZ2h0PSIxOTgiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4NCiAgICA8dGQgdmFsaWduPSJ0 b3AiPjxpbWcgc3JjPSJodHRwOi8vcGFyYWp1cmEuY29tL3NwX21haWwvaW1hZ2UvZHJpdmVj b3Vyc2UxXzYuZ2lmIiB3aWR0aD0iNjAwIiBoZWlnaHQ9IjM5IiB1c2VtYXA9IiNNYXAzIiBi b3JkZXI9IjAiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4NCiAgICA8dGQgdmFsaWduPSJ0b3Ai PjxpbWcgc3JjPSJodHRwOi8vcGFyYWp1cmEuY29tL3NwX21haWwvaW1hZ2UvZHJpdmVjb3Vy c2UxXzcuZ2lmIiB3aWR0aD0iNjAwIiBoZWlnaHQ9IjYzIiB1c2VtYXA9IiNNYXA0IiBib3Jk ZXI9IjAiPjwvdGQ+DQogIDwvdHI+DQo8L3RhYmxlPg0KPG1hcCBuYW1lPSJNYXAiPg0KICA8 YXJlYSBzaGFwZT0icmVjdCIgY29vcmRzPSIxMTksMSwxNzIsMjEiIGhyZWY9Imh0dHA6Ly8y MjAwNDk4OS5jb20vbWVtYmVyc2hpcC9tZW1iZXJfZ2FpcC5hc3AiIHRhcmdldD0iX2JsYW5r Ij4NCjwvbWFwPg0KPG1hcCBuYW1lPSJNYXAyIj4NCiAgPGFyZWEgc2hhcGU9InJlY3QiIGNv b3Jkcz0iMTcsNDMsNTgzLDIwMCIgaHJlZj0iaHR0cDovLzIyMDA0OTg5LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPg0KPC9tYXA+DQo8bWFwIG5hbWU9Ik1hcDMiPg0KICA8YXJlYSBzaGFwZT0i cmVjdCIgY29vcmRzPSIxOTksMiwzODUsNDgiIGhyZWY9Imh0dHA6Ly8yMjAwNDk4OS5jb20i IHRhcmdldD0iX2JsYW5rIj4NCjwvbWFwPg0KPG1hcCBuYW1lPSJNYXA0Ij4NCiAgPGFyZWEg c2hhcGU9InJlY3QiIGNvb3Jkcz0iMTQ5LDQyLDIwMiw1NyIgaHJlZj0ibWFpbHRvOmNvcmVA cGFyYWp1cmEuY29tIj4NCjwvbWFwPg0KPC9ib2R5Pg0KPC9odG1sPg0K ------=_NextPart_000_0097_01C0F21A.93A33C00-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Dec 28 11:20:12 2001 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 LAA09272 for ; Fri, 28 Dec 2001 11:20:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26309 for midcom-archive@odin.ietf.org; Fri, 28 Dec 2001 11:20:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26266; Fri, 28 Dec 2001 11:17:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26234 for ; Fri, 28 Dec 2001 11:17:38 -0500 (EST) Received: from hotmail.com (lwd711.emirates.net.ae [217.165.238.203]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09248 for ; Fri, 28 Dec 2001 11:17:28 -0500 (EST) Message-Id: <200112281617.LAA09248@ietf.org> From: "Christos Psaras" To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 28 Dec 2001 20:18:57 +0400 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [midcom] GET RICH AT HOME 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 Dear Future Millionaire: I'll make you a promise. READ THIS E-MAIL TO THE END! - Follow what it says to the letter- and you will not worry whether a RECESSION is coming or not, who is President, or whether you keep your current job or not. Yes, I know what you are thinking. I never responded to one of these before either. One day though, something just said "you throw away $25.00 going to a movie for 2 hours with your wife" ``what the heck``. Believe me, no matter where you believe "those feelings" come from, I thank goodness every day that I had that feeling. I cannot imagine where I would be or what I would be doing had I not. Read on. It's true. Every word of it. It is legal. I checked. Simply because you are buying and selling something of value. AS SEEN ON NATIONAL TV: Making over half million dollars every 4 to 5 months from your home. THANK`S TO THE COMPUTER AGE AND THE INTERNET!!! = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = BE AN INTERNET MILLIONAIRE LIKE OTHERS WITHIN A YEAR! ! ! Before you say "Bull``, please read the following. This is the letter you have been hearing about on the news lately . Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are " absolutely NO laws prohibiting the participation in the program and if people "follow the simple instruction" they are bound to make some mega bucks with only $ 25 out of pocket cost". DUE TO THE RECENT INCREACE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one day to say: "Thanks to this profitable opportunity" . I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received a total $ 610,470,00 in 21 weeks, with money still coming in". Pam Hedland , Fort Lee New Jersey. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Another said, " this program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it .I follow the simple instructions and walaa� 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything." More testimonials later but first, = = = = PRINT THIS NOW FOR YOUR FUTURE REFERENCE = = = = $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500.00 every 4 to 5 months easily and comfortably, please read the following � THEN READ IT AGAIN AND AGAIN TO UNERSTAND IT!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: = = = = = Order all 5 reports shown on the list below = = = = = For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORTS YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. = = = WHEN YOU PLACE YOUR ORDER, MAKE SURE YOU ORDER EACH OF THE 5 REPORTS = = = = You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $ 25.00 Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000`s of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happens to your computer. IMPORTANT --- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step ``1 through 6`` or you will loose out on the majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter it, it will NOT work!!! People have tried to put their friends/relatives names on all five, thinking they could get all the money. But it does not work this way. Believe us, some have tried to be greedy and then nothing happened. So DO NOT try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! This IS a legitimate BUSINESS. You are offering a product for sale and getting paid for it. Treat it as such and you will be VERY profitable in a short period of time. 1. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no dough counting their fortune. 2.. Move the name & address in report # 4 down to report # 5. 3.. Move the name & address in report # 3 down to report # 4. 4.. Move the name & address in report # 2 down to report # 3. 5.. Move the name & address in report # 1 down to report # 2. 6��Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! This is critical to your success. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = * * * * Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the Internet, the 5 reports you purchase will provide you with invaluable marketing information, which includes how to send bulk e-mail legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD #1: BY SENDING BULK E-MAIL LEGALLY = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Let's say that you decide to start small, just to see how it goes, and we will assume you and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only 0.2% (2/10 of 1%) response (the response could be much better but let's just say it is only 0.2%). Also many people will send out hundreds of thousands e-mails instead of only 5,000 each. Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that it is only 10 orders for report #1. Those 10 people responded by sending out 5,000 e-mails each for a total of 50,000. Out of those 50,000 e-mails only 0.2%responded with orders. That's = 100 people responded and ordered Report #2. Those 100 people mail out 5,000 e- mails each for a total of 500,000 e-mails. The 0.2% response to that are 1000 orders for report #3. Those 1000 people send 5.000 e-mails each for a total of 5 million e-mails send out. The 0.2% response is 10.000 orders for report #4. Those 10.000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that are 100,000 orders for report #5.THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half a million dollars). Your total income in this example is: 1� $50 + 2� $500 + 3� $5,000 + 4� $50,000 + 5� $500,000�Grand Total = $555,550.00. NUMBERS DO NOT LIE. GET A PENCIL & A PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY!!!! = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAIL TO. Dare to think for a moment what would happen if every one or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the Internet worldwide and counting, with thousands more coming on line every day. Believe me, many people will do just that, and more!! METHOD #2: BY PLACING FREE ADS ON THE INTERNET = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Advertising on the net is very, very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method #1 and add Method #2 as you go along. For every $5 you receive, all you must do is e-mail them the report they ordered. That's it. Always provide some day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. = = = = = = = = AVAILABLE REPORTS = = = = = = = = = = = = = = = = = = = = = = = The reason for the "cash" is not because this is illegal or somehow "wrong". It is simply about time. Time for checks or credit cards to be cleared or approved, etc. Concealing it is simply so no one can SEE there is money in the envelope and steal it before it gets to you. ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S.CURRENCY) for each report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & THE NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = REPORT #1 'The insider's guide to advertising for free on the net'. Order report #1 from: Christos Psaras 40,Serifou, Zakaki Limassol 3046, Cyprus REPORT #2: The insider's guide to sending Bulk E-mail on the net. Order report #2 from: Chris Rhodes 7915 Kleingreen Spring, Texas 77379 USA REPORT #3: The Secrets to multi-level marketing on the net. Order report #3 from: Scott Katip 3110 5th Ave Beavers Falls, Pa 15010 USA REPORT #4: How to become a millionaire using MLM & the net. Order report #4 from S. Wong 50 Burnhamthorpe Rd West #401 Mississauga, Ontario, L5B 3C2 Canada REPORT #5: How to send out one million e-mails for free. Order report #5 from: Zach Simmons 2135 Springwood Carrollton, TX 75006 USA $$$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$$$$$$$$$$$$$$$$$$ Follow these guidelines to guarantee your success: = = = If you do not receive at least 10 orders for report #1 within 2 weeks, continue sending e-mails until you do. = = = After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT #2. If you did not, continue advertising or sending e-mails until you do. * * * Once you have received 100 or more orders for report #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in frond of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = THE FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in report #1 and move others to #2��.. #5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the idea, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW!!! = = = = = = = = = MORE TESTIMONIALS = = = = = = = = = = = = = = = = = = " My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Judy about receiving `` junk mail`` . I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ``knew`` it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old `` I told you so`` on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $147,200.00� all cash! I was shocked. I have joined Jody in her ``hobby``. Mitchell Wolf M.D., Chicago, Illinois = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = " Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative as I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back". "I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal it does not matter where people live. There simply isn't better investment with a faster return and so big". Dan Sondstrom, Alberta, Canada. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else�.11 months passed then it luckily came again� I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20,560.00 and by the end of third month my total cash count was $362,840.00. Life is beautiful Thanks to Internet". Fred Dellaca, Westport, New Zealand = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you have any questions of the legality of this program, contact the office of associate director for marketing practices, federal trade commission, Bureau of consumer protection, Washington, DC $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ONE TIME MAILING, NO NEED TO REMOVE _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Dec 31 17:33:54 2001 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 RAA07663 for ; Mon, 31 Dec 2001 17:33:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA06199 for midcom-archive@odin.ietf.org; Mon, 31 Dec 2001 17:33:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06128; Mon, 31 Dec 2001 17:32:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06063 for ; Mon, 31 Dec 2001 17:32:03 -0500 (EST) Received: from localhost ([211.179.220.189]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07612 for ; Mon, 31 Dec 2001 17:31:59 -0500 (EST) Message-Id: <200112312231.RAA07612@ietf.org> Reply-To: sago8572@hananet.net From: �ȼ�ö To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 1 Jan 2002 07:32:05 +0900 Subject: [midcom] �ƴ�� 𸣴��Ŀ� �� õ��![��] 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 autoinad �� ѹ̸� Ȩ��

�� 帰 �� 帳�ϴ�.

��ʿ�� ̶�� ٷ� ��Ͽ� �ֽñ� �ٶ��ϴ�.[�Ҹ�÷��]

��

�ָԺ�� ƴ� �� !

- ��躸�� ϰ�� ó�� Ǳ⵵ �մϴ�.

- �ƴ�� 𸣳Ŀ� �� õ�� !!

- ��Ͽ�� Ǿ� �帮�ڽ��ϴ�.

�̷�� , ��ȭ �ϼ�� !

-.�� Ȳ�� .

-.�� ˰� �� .

-.�� ٰ� �� .

-.�� ڰ� �� .

-.�� δ��ϴٰ� �� .

-.�� ҵ�� .

-.��Ÿ �� ñ� �� .

�� մϴ�.

- �� 1��1 �ǽð� ��

- �ż��ϰ� , �� 亯

- �ÿ�� ذ�

��  [060-700-2114]

�� ź� �ǰ� ��׿� �ǰ� �� [��]�� ǥ�õ� �� Դϴ�.

�� ̻� �� ϰ� �� ø� [�� ź�]�� ޽�� ֽø� �ٽô� �߼�� ʵ�� ϰڽ��.

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

���� ���� ���� ���� �帰 �� ����帳�ϴ�. ���ʿ��� �����̶�� �ٷ� �����Ͽ� �ֽñ� �ٶ��ϴ�.[�Ҹ�÷��]

������ ������

�� 帰 �� 帳�ϴ�.

��ʿ�� ̶�� ٷ� ��Ͽ� �ֽñ� �ٶ��ϴ�.[�Ҹ�÷��]

��