From mailnull@www1.ietf.org Sun Sep 1 08:59:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18105 for ; Sun, 1 Sep 2002 08:59:52 -0400 (EDT) From: mailnull@www1.ietf.org Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g81D0vj07065 for midcom-archive@odin.ietf.org; Sun, 1 Sep 2002 09:00:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81D0vo07062 for ; Sun, 1 Sep 2002 09:00:57 -0400 Date: Sun, 01 Sep 2002 09:00:57 -0400 Message-ID: <20020901130057.1916.99294.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder To: midcom-web-archive@optimus.ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, midcom-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@. Thanks! Passwords for midcom-web-archive@optimus.ietf.org: List Password // URL ---- -------- midcom@ietf.org yYVU https://www1.ietf.org/mailman/options/midcom/midcom-web-archive%40optimus.ietf.org From mailnull@www1.ietf.org Sun Sep 1 10:41:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21611 for ; Sun, 1 Sep 2002 10:41:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g81EgS926964 for midcom-archive@odin.ietf.org; Sun, 1 Sep 2002 10:42:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81Eewo26928; Sun, 1 Sep 2002 10:40:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81Ecmo26840 for ; Sun, 1 Sep 2002 10:38:48 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21534 for ; Sun, 1 Sep 2002 10:37:13 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g81EcFW4027887; Sun, 1 Sep 2002 07:38:15 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADX00378; Sun, 1 Sep 2002 07:38:23 -0700 (PDT) From: "Cullen Jennings" To: "Francois Audet" , Subject: RE: [midcom] Moving SPAN along Date: Sun, 1 Sep 2002 07:38:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D203D62A7C@zsc3c030.us.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This falls into your category of both ends cooperate via a standardized mechanism but here is one possible idea. The two endpoint set up a communication channel that is guaranteed to work via TURN. Then endpoint A send a token and it's private address to endpoint B over this channel. Endpoint B looks at the private address and tries to directly send the token to A's private address. If A receives the correct token, they know they can talk to each other. Cullen -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Francois Audet Sent: Thursday, August 29, 2002 5:11 PM To: 'Jonathan Rosenberg'; Sanjoy Sen Cc: 'Melinda Shore'; 'Pete Cordell'; 'midcom@ietf.org' Subject: RE: [midcom] Moving SPAN along > The problem is not the case when two clients are behind the same NAT. > There are many ways to detect this, and once you know it, you can use > your private addresses. Can you expand on the "many ways" to detect this? I can't think of any way that does not require that both end cooperate on this through some standardized mechanism. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sun Sep 1 11:01:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22563 for ; Sun, 1 Sep 2002 11:01:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g81F2FY27643 for midcom-archive@odin.ietf.org; Sun, 1 Sep 2002 11:02:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81F0qo27592; Sun, 1 Sep 2002 11:00:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81EwFo27513 for ; Sun, 1 Sep 2002 10:58:15 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22460 for ; Sun, 1 Sep 2002 10:56:39 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g81Evfds008440; Sun, 1 Sep 2002 07:57:41 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADX00444; Sun, 1 Sep 2002 07:57:49 -0700 (PDT) From: "Cullen Jennings" To: "Melinda Shore" , Subject: RE: [midcom] Moving SPAN along Date: Sun, 1 Sep 2002 07:57:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200208281450.AEY16565@mira-sjc5-4.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think there are two orthogonal questions. The first question is UDP traversal in cases where STUN will not work. I think this is a questions worth solving. The second question is TCP traversal. I wish we could solve this but I'm not sure it is possible without running into the issue of violating the policy that the firewall administrator is trying to provide. If people think we can do a generic solution for peer to peer TCP - I'm very interested in figuring out how. If people don't think we can then, unfortunately, I think we may be stuck with doing traversal of TCP with application specific relays. H.323 and IM are some good use cases to think about - though 323 may just use Annex E to avoid this and SIMPLE may use sip like proxies as application level relays. I'd like to solve this problem but before we can figure out if a solution is possible, we need to figure out what our constraints are from the point of view of firewall policy. Cullen > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Melinda Shore > Sent: Wednesday, August 28, 2002 7:54 AM > To: Pete Cordell > Cc: midcom@ietf.org > Subject: Re: [midcom] Moving SPAN along > > > At this point there seems to be very little support for > continuing to work on SPAN. The question is whether or not > the problem of traversing symmetric NATs is sufficiently > compelling. If it is we need to continue; if not we can > consider dropping the deliverable. Let's try to resolve > this question over the next few days. > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Sep 2 15:08:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29502 for ; Mon, 2 Sep 2002 15:08:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82J9aQ23771 for midcom-archive@odin.ietf.org; Mon, 2 Sep 2002 15:09:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82J7jo23721; Mon, 2 Sep 2002 15:07:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82J6ho23158 for ; Mon, 2 Sep 2002 15:06:43 -0400 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29425 for ; Mon, 2 Sep 2002 15:05:03 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 2 Sep 2002 12:06:34 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Sep 2002 12:06:07 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Sep 2002 12:06:07 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 2 Sep 2002 12:06:05 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Mon, 2 Sep 2002 12:06:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6728.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Moving SPAN along Date: Mon, 2 Sep 2002 12:06:05 -0700 Message-ID: Thread-Topic: [midcom] Moving SPAN along Thread-Index: AcJRyTh9TTL9WlxnSuOqZeZ4B2sRhwA5syNQ From: "Christian Huitema" To: "Cullen Jennings" , "Melinda Shore" , X-OriginalArrivalTime: 02 Sep 2002 19:06:06.0120 (UTC) FILETIME=[C9FCB280:01C252B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g82J6io23159 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We already have a generic solution for crossing firewalls with the help of a 3rd party: tunneling IP through a VPN service; this allows both TCP and UDP. There is even an IETF proposed standard: RFC 2661, Layer Two Tunneling Protocol "L2TP". Sure, there are severe security issues with allowing a VPN connection to the outside, but any solution that will allow establishment of arbitrary TCP connection will run into the exact same issue, and will end up with the same class of solutions: establish some form of firewall at the tunnel endpoint. I don't think that MIDCOM should try reinventing another way to do VPN, and I am thus not terribly interested with any solution that implies relaying the data packets through a 3rd party. There are two interesting classes of short term solutions for TCP traversal: those that require some help from the firewall, and those that establish an "end-to-end" channel. We already have a proposed standard for the 1st class of solution: SOCKS, RFC 1928. A tempting approach for the 2nd class of solution is some form of "symmetric TCP" establishment, but it seems almost impossible to get a reliable design. We are thus left with solutions that establish an end-to-end UDP tunnel, maybe using STUN, and then use that tunnel to carry a TCP-IP exchange. At this point, we have a problem of allocating IP addresses to the tunnel end-point, and it is not an easy problem with IPv4. On the other hand, tunneling IPv6 over UDP end-to-end is exactly what Teredo does. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Sunday, September 01, 2002 7:58 AM > To: Melinda Shore; midcom@ietf.org > Subject: RE: [midcom] Moving SPAN along > > > I think there are two orthogonal questions. > > The first question is UDP traversal in cases where STUN will not work. I > think this is a questions worth solving. > > The second question is TCP traversal. I wish we could solve this but I'm > not > sure it is possible without running into the issue of violating the policy > that the firewall administrator is trying to provide. If people think we > can > do a generic solution for peer to peer TCP - I'm very interested in > figuring > out how. If people don't think we can then, unfortunately, I think we may > be > stuck with doing traversal of TCP with application specific relays. H.323 > and IM are some good use cases to think about - though 323 may just use > Annex E to avoid this and SIMPLE may use sip like proxies as application > level relays. I'd like to solve this problem but before we can figure out > if > a solution is possible, we need to figure out what our constraints are > from > the point of view of firewall policy. > > Cullen > > > > -----Original Message----- > > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > > Melinda Shore > > Sent: Wednesday, August 28, 2002 7:54 AM > > To: Pete Cordell > > Cc: midcom@ietf.org > > Subject: Re: [midcom] Moving SPAN along > > > > > > At this point there seems to be very little support for > > continuing to work on SPAN. The question is whether or not > > the problem of traversing symmetric NATs is sufficiently > > compelling. If it is we need to continue; if not we can > > consider dropping the deliverable. Let's try to resolve > > this question over the next few days. > > > > Melinda > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Sep 2 16:21:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00708 for ; Mon, 2 Sep 2002 16:21:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g82KMoJ27983 for midcom-archive@odin.ietf.org; Mon, 2 Sep 2002 16:22:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82KLIo27940; Mon, 2 Sep 2002 16:21:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g82KKao27914 for ; Mon, 2 Sep 2002 16:20:36 -0400 Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00694 for ; Mon, 2 Sep 2002 16:18:50 -0400 (EDT) Received: from host213-122-164-72.in-addr.btopenworld.com ([213.122.164.72] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 17lxgJ-0005CQ-00; Mon, 02 Sep 2002 21:20:19 +0100 Message-ID: <003b01c252be$4bd4db20$0200000a@tkw> From: "Pete Cordell" To: "Christian Huitema" , "Cullen Jennings" , "Melinda Shore" , References: Subject: Re: [midcom] Moving SPAN along Date: Mon, 2 Sep 2002 21:20:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit While L2TP has the benefit of being an off the shelf solution, it also comes with considerable overhead, e.g. IP/ (UDP/L2TP/PPP/IP) /UDP/RTP/data as opposed to: IP/UDP/RTP/data The PPP negotiation presumably requires a number of round trips to setup also. It's for these reasons that I've dismissed L2TP in the past. If a more detailed consideration is required I will need a bit more time to look into the specifics of L2TP. The problem with SOCKs is that it requires an OS upgrade. VoIP has got into the position it is in because it has a dependency on the firewall and NAT industry to solve its problems. Moving that dependency to various OS providers (including Solaris, HP-UX, etc, etc) is just moving the problem around rather than solving it. Thus while architecturally SOCKs may be appear to be a solution, in practice it does not move the technology forward. Your proposed use of STUN to build UDP tunnels does not appear to provide any benefits over a SPAN type solution. It has exactly the same security issues as SPAN (indeed SPAN and Teredo are very similar in this respect) but has considerably more overhead. In fact, having an application receive unspecified IP packets over UDP and then squirting them around a system seems a powerful thing to do, but also seems much scarier to me than allowing a client to do a rendezvous TCP connection. I don't want to stop you suggesting alternative solutions for the SPAN type space, but I'm afraid that so far I don't think what has been proposed are viable ways to move ahead. Pete. ----- Original Message ----- From: "Christian Huitema" To: "Cullen Jennings" ; "Melinda Shore" ; Sent: 02 September 2002 20:06 Subject: RE: [midcom] Moving SPAN along > We already have a generic solution for crossing firewalls with the help > of a 3rd party: tunneling IP through a VPN service; this allows both TCP > and UDP. There is even an IETF proposed standard: RFC 2661, Layer Two > Tunneling Protocol "L2TP". Sure, there are severe security issues with > allowing a VPN connection to the outside, but any solution that will > allow establishment of arbitrary TCP connection will run into the exact > same issue, and will end up with the same class of solutions: establish > some form of firewall at the tunnel endpoint. I don't think that MIDCOM > should try reinventing another way to do VPN, and I am thus not terribly > interested with any solution that implies relaying the data packets > through a 3rd party. > > There are two interesting classes of short term solutions for TCP > traversal: those that require some help from the firewall, and those > that establish an "end-to-end" channel. We already have a proposed > standard for the 1st class of solution: SOCKS, RFC 1928. A tempting > approach for the 2nd class of solution is some form of "symmetric TCP" > establishment, but it seems almost impossible to get a reliable design. > We are thus left with solutions that establish an end-to-end UDP tunnel, > maybe using STUN, and then use that tunnel to carry a TCP-IP exchange. > At this point, we have a problem of allocating IP addresses to the > tunnel end-point, and it is not an easy problem with IPv4. On the other > hand, tunneling IPv6 over UDP end-to-end is exactly what Teredo does. > .... cut .... _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Sep 2 23:43:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06596 for ; Mon, 2 Sep 2002 23:43:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g833iCu16879 for midcom-archive@odin.ietf.org; Mon, 2 Sep 2002 23:44:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g833gGo16808; Mon, 2 Sep 2002 23:42:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g833fio16781 for ; Mon, 2 Sep 2002 23:41:44 -0400 Received: from pallas.host4u.net (pallas.host4u.net [216.71.64.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06546 for ; Mon, 2 Sep 2002 23:40:02 -0400 (EDT) Received: from C1380748b (12-234-183-24.client.attbi.com [12.234.183.24]) by pallas.host4u.net (8.11.6/8.11.6) with ESMTP id g833dU909402; Mon, 2 Sep 2002 22:39:30 -0500 From: "Shai Mohaban" To: "'Pete Cordell'" , "'Christian Huitema'" , "'Cullen Jennings'" , "'Melinda Shore'" , Subject: RE: [midcom] Moving SPAN along Date: Mon, 2 Sep 2002 20:40:07 -0700 Organization: Kagoor Networks Message-ID: <010301c252fb$9aef05e0$0200a8c0@C1380748b> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <003b01c252be$4bd4db20$0200000a@tkw> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I am not sure I follow the OS upgrade argument. Wouldn't the same be true for SPAN? Either you upgrade the endpoint to support SPAN, or you put some kind of a proxy to do SPAN for it. You can do the same with SOCKS or whatever other mechanism you argue against with the "OS upgrade" argument... > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On > Behalf Of Pete Cordell > Sent: Monday, September 02, 2002 1:21 PM > To: Christian Huitema; Cullen Jennings; Melinda Shore; midcom@ietf.org > Subject: Re: [midcom] Moving SPAN along > > > While L2TP has the benefit of being an off the shelf > solution, it also comes > with considerable overhead, e.g. > > IP/ (UDP/L2TP/PPP/IP) /UDP/RTP/data > > as opposed to: > > IP/UDP/RTP/data > > The PPP negotiation presumably requires a number of round > trips to setup > also. It's for these reasons that I've dismissed L2TP in the > past. If a > more detailed consideration is required I will need a bit > more time to look > into the specifics of L2TP. > > The problem with SOCKs is that it requires an OS upgrade. > VoIP has got into > the position it is in because it has a dependency on the > firewall and NAT > industry to solve its problems. Moving that dependency to various OS > providers (including Solaris, HP-UX, etc, etc) is just moving > the problem > around rather than solving it. Thus while architecturally > SOCKs may be > appear to be a solution, in practice it does not move the technology > forward. > > Your proposed use of STUN to build UDP tunnels does not > appear to provide > any benefits over a SPAN type solution. It has exactly the > same security > issues as SPAN (indeed SPAN and Teredo are very similar in > this respect) but > has considerably more overhead. In fact, having an > application receive > unspecified IP packets over UDP and then squirting them > around a system > seems a powerful thing to do, but also seems much scarier to me than > allowing a client to do a rendezvous TCP connection. > > I don't want to stop you suggesting alternative solutions for > the SPAN type > space, but I'm afraid that so far I don't think what has been > proposed are > viable ways to move ahead. > > Pete. > > ----- Original Message ----- > From: "Christian Huitema" > To: "Cullen Jennings" ; "Melinda Shore" > ; > Sent: 02 September 2002 20:06 > Subject: RE: [midcom] Moving SPAN along > > > > We already have a generic solution for crossing firewalls > with the help > > of a 3rd party: tunneling IP through a VPN service; this > allows both TCP > > and UDP. There is even an IETF proposed standard: RFC 2661, > Layer Two > > Tunneling Protocol "L2TP". Sure, there are severe security > issues with > > allowing a VPN connection to the outside, but any solution that will > > allow establishment of arbitrary TCP connection will run > into the exact > > same issue, and will end up with the same class of > solutions: establish > > some form of firewall at the tunnel endpoint. I don't think > that MIDCOM > > should try reinventing another way to do VPN, and I am thus > not terribly > > interested with any solution that implies relaying the data packets > > through a 3rd party. > > > > There are two interesting classes of short term solutions for TCP > > traversal: those that require some help from the firewall, and those > > that establish an "end-to-end" channel. We already have a proposed > > standard for the 1st class of solution: SOCKS, RFC 1928. A tempting > > approach for the 2nd class of solution is some form of > "symmetric TCP" > > establishment, but it seems almost impossible to get a > reliable design. > > We are thus left with solutions that establish an > end-to-end UDP tunnel, > > maybe using STUN, and then use that tunnel to carry a > TCP-IP exchange. > > At this point, we have a problem of allocating IP addresses to the > > tunnel end-point, and it is not an easy problem with IPv4. > On the other > > hand, tunneling IPv6 over UDP end-to-end is exactly what > Teredo does. > > > .... cut .... > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 3 03:45:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18539 for ; Tue, 3 Sep 2002 03:45:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g837l0q05441 for midcom-archive@odin.ietf.org; Tue, 3 Sep 2002 03:47:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g837gFo05299; Tue, 3 Sep 2002 03:42:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g837fho05255 for ; Tue, 3 Sep 2002 03:41:43 -0400 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18437 for ; Tue, 3 Sep 2002 03:39:57 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.47]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g837esYH015129; Tue, 3 Sep 2002 03:40:56 -0400 (EDT) Message-ID: <3D746784.3070704@dynamicsoft.com> Date: Tue, 03 Sep 2002 03:40:52 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Cullen Jennings , Melinda Shore , midcom@ietf.org Subject: Re: [midcom] Moving SPAN along References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christian Huitema wrote: > We already have a generic solution for crossing firewalls with the help > of a 3rd party: tunneling IP through a VPN service; this allows both TCP > and UDP. There is even an IETF proposed standard: RFC 2661, Layer Two > Tunneling Protocol "L2TP". Sure, there are severe security issues with > allowing a VPN connection to the outside, but any solution that will > allow establishment of arbitrary TCP connection will run into the exact > same issue, and will end up with the same class of solutions: establish > some form of firewall at the tunnel endpoint. I don't think that MIDCOM > should try reinventing another way to do VPN, and I am thus not terribly > interested with any solution that implies relaying the data packets > through a 3rd party. I think its worth investigating in what ways our problem here is the same as VPN, and in what ways its not. I think the biggest difference is that the protocol is targeted by use for applications instead of the underlying host. Practically speaking, this means that what you want to allocate is an IP address and port, as opposed to just an IP address, which is what you typically get through a VPN. I wonder if any existing VPN protocol can do that, or be extended to do that... We also want low overhead, as Pete has pointed out, since the target applications are multimedia, although this is a general goal that any VPN protocol would probably also have. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 3 04:54:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19398 for ; Tue, 3 Sep 2002 04:54:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g838tsL09342 for midcom-archive@odin.ietf.org; Tue, 3 Sep 2002 04:55:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g838p5o09200; Tue, 3 Sep 2002 04:51:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g838opo09176 for ; Tue, 3 Sep 2002 04:50:51 -0400 Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19345 for ; Tue, 3 Sep 2002 04:48:57 -0400 (EDT) Received: from host213-122-62-135.in-addr.btopenworld.com ([213.122.62.135] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #8) id 17m9O7-0007Ay-00; Tue, 03 Sep 2002 09:50:19 +0100 Message-ID: <002c01c25327$37f18400$0200000a@tkw> From: "Pete Cordell" To: "Shai Mohaban" , "'Christian Huitema'" , References: <010301c252fb$9aef05e0$0200a8c0@C1380748b> Subject: Re: [midcom] Moving SPAN along Date: Tue, 3 Sep 2002 09:51:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Oooppps, I was still in tunnelling mode when I was talking about SOCKS and I was actually thinking about RSIP!!! My apologies. SOCKS (as mentioned in the original e-mail) obviously requires firewall support and so can not be compared directly with things in the SPAN space. SOCKS is in the Midcom protocol space. Pete. ----- Original Message ----- From: "Shai Mohaban" To: "'Pete Cordell'" ; "'Christian Huitema'" ; "'Cullen Jennings'" ; "'Melinda Shore'" ; Sent: 03 September 2002 04:40 Subject: RE: [midcom] Moving SPAN along > I am not sure I follow the OS upgrade argument. Wouldn't the same be > true for SPAN? Either you upgrade the endpoint to support SPAN, or you > put some kind of a proxy to do SPAN for it. You can do the same with > SOCKS or whatever other mechanism you argue against with the "OS > upgrade" argument... > > > -----Original Message----- > > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On > > Behalf Of Pete Cordell > > Sent: Monday, September 02, 2002 1:21 PM > > To: Christian Huitema; Cullen Jennings; Melinda Shore; midcom@ietf.org > > Subject: Re: [midcom] Moving SPAN along > > > > > > While L2TP has the benefit of being an off the shelf > > solution, it also comes > > with considerable overhead, e.g. > > > > IP/ (UDP/L2TP/PPP/IP) /UDP/RTP/data > > > > as opposed to: > > > > IP/UDP/RTP/data > > > > The PPP negotiation presumably requires a number of round > > trips to setup > > also. It's for these reasons that I've dismissed L2TP in the > > past. If a > > more detailed consideration is required I will need a bit > > more time to look > > into the specifics of L2TP. > > > > The problem with SOCKs is that it requires an OS upgrade. > > VoIP has got into > > the position it is in because it has a dependency on the > > firewall and NAT > > industry to solve its problems. Moving that dependency to various OS > > providers (including Solaris, HP-UX, etc, etc) is just moving > > the problem > > around rather than solving it. Thus while architecturally > > SOCKs may be > > appear to be a solution, in practice it does not move the technology > > forward. > > > > Your proposed use of STUN to build UDP tunnels does not > > appear to provide > > any benefits over a SPAN type solution. It has exactly the > > same security > > issues as SPAN (indeed SPAN and Teredo are very similar in > > this respect) but > > has considerably more overhead. In fact, having an > > application receive > > unspecified IP packets over UDP and then squirting them > > around a system > > seems a powerful thing to do, but also seems much scarier to me than > > allowing a client to do a rendezvous TCP connection. > > > > I don't want to stop you suggesting alternative solutions for > > the SPAN type > > space, but I'm afraid that so far I don't think what has been > > proposed are > > viable ways to move ahead. > > > > Pete. > > > > ----- Original Message ----- > > From: "Christian Huitema" > > To: "Cullen Jennings" ; "Melinda Shore" > > ; > > Sent: 02 September 2002 20:06 > > Subject: RE: [midcom] Moving SPAN along > > > > > > > We already have a generic solution for crossing firewalls > > with the help > > > of a 3rd party: tunneling IP through a VPN service; this > > allows both TCP > > > and UDP. There is even an IETF proposed standard: RFC 2661, > > Layer Two > > > Tunneling Protocol "L2TP". Sure, there are severe security > > issues with > > > allowing a VPN connection to the outside, but any solution that will > > > allow establishment of arbitrary TCP connection will run > > into the exact > > > same issue, and will end up with the same class of > > solutions: establish > > > some form of firewall at the tunnel endpoint. I don't think > > that MIDCOM > > > should try reinventing another way to do VPN, and I am thus > > not terribly > > > interested with any solution that implies relaying the data packets > > > through a 3rd party. > > > > > > There are two interesting classes of short term solutions for TCP > > > traversal: those that require some help from the firewall, and those > > > that establish an "end-to-end" channel. We already have a proposed > > > standard for the 1st class of solution: SOCKS, RFC 1928. A tempting > > > approach for the 2nd class of solution is some form of > > "symmetric TCP" > > > establishment, but it seems almost impossible to get a > > reliable design. > > > We are thus left with solutions that establish an > > end-to-end UDP tunnel, > > > maybe using STUN, and then use that tunnel to carry a > > TCP-IP exchange. > > > At this point, we have a problem of allocating IP addresses to the > > > tunnel end-point, and it is not an easy problem with IPv4. > > On the other > > > hand, tunneling IPv6 over UDP end-to-end is exactly what > > Teredo does. > > > > > .... cut .... > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 3 07:39:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22326 for ; Tue, 3 Sep 2002 07:39:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83Bec518117 for midcom-archive@odin.ietf.org; Tue, 3 Sep 2002 07:40:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83Bbio17969; Tue, 3 Sep 2002 07:37:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83BZeo17327 for ; Tue, 3 Sep 2002 07:35:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21965; Tue, 3 Sep 2002 07:34:01 -0400 (EDT) Message-Id: <200209031134.HAA21965@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 03 Sep 2002 07:34:01 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-protocol-eval-04.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communications (MIDCOM) Protocol Evaluation Author(s) : M. Barnes Filename : draft-ietf-midcom-protocol-eval-04.txt Pages : 34 Date : 2002-8-30 This document provides an evaluation of the applicability of SNMP, RSIP, MEGACO, DIAMETER and COPS as the MIDCOM protocol. A summary of each of the proposed protocols against the MIDCOM requirements and MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-protocol-eval-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-protocol-eval-04.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: <2002-8-30145213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-protocol-eval-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-protocol-eval-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-30145213.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 3 10:42:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29037 for ; Tue, 3 Sep 2002 10:42:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83Ei3528300 for midcom-archive@odin.ietf.org; Tue, 3 Sep 2002 10:44:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83Ecco28013; Tue, 3 Sep 2002 10:38:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83Ebwo27962 for ; Tue, 3 Sep 2002 10:37:58 -0400 Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28666 for ; Tue, 3 Sep 2002 10:36:17 -0400 (EDT) Received: from host213-122-170-17.in-addr.btopenworld.com ([213.122.170.17] helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #8) id 17mEnz-0000sx-00; Tue, 03 Sep 2002 15:37:23 +0100 Message-ID: <002701c25357$b3a9b920$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , "Christian Huitema" Cc: "Cullen Jennings" , "Melinda Shore" , References: <3D746784.3070704@dynamicsoft.com> Subject: Re: [midcom] Moving SPAN along Date: Tue, 3 Sep 2002 15:39:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Maybe it's worth doing some sort of quick SPAN evaluation document covering VPN techniques and other such things. I'm away on holiday for a week after today, but I can produce a rough outline when I get back and then we can all pile in a build some consensus around it. (The document needn't become an RFC. We would just need to keep it alive long enough to either produce a SPAN protocol or decide there were other ways to do it. If another way was selected we'ed presumably produce an informational draft, but that's a little way off for the time being.) For the time being, what other IETF standard VPN techniques are there (other than L2TP)? IP over UDP (a la Teredo)? PPP over IP or UDP? We should mention RSIP in the document. What other things? Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: "Christian Huitema" Cc: "Cullen Jennings" ; "Melinda Shore" ; Sent: 03 September 2002 08:40 Subject: Re: [midcom] Moving SPAN along > > > Christian Huitema wrote: > > We already have a generic solution for crossing firewalls with the help > > of a 3rd party: tunneling IP through a VPN service; this allows both TCP > > and UDP. There is even an IETF proposed standard: RFC 2661, Layer Two > > Tunneling Protocol "L2TP". Sure, there are severe security issues with > > allowing a VPN connection to the outside, but any solution that will > > allow establishment of arbitrary TCP connection will run into the exact > > same issue, and will end up with the same class of solutions: establish > > some form of firewall at the tunnel endpoint. I don't think that MIDCOM > > should try reinventing another way to do VPN, and I am thus not terribly > > interested with any solution that implies relaying the data packets > > through a 3rd party. > > I think its worth investigating in what ways our problem here is the > same as VPN, and in what ways its not. I think the biggest difference is > that the protocol is targeted by use for applications instead of the > underlying host. Practically speaking, this means that what you want to > allocate is an IP address and port, as opposed to just an IP address, > which is what you typically get through a VPN. I wonder if any existing > VPN protocol can do that, or be extended to do that... > > We also want low overhead, as Pete has pointed out, since the target > applications are multimedia, although this is a general goal that any > VPN protocol would probably also have. > > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 3 13:56:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07317 for ; Tue, 3 Sep 2002 13:56:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g83HvZ709360 for midcom-archive@odin.ietf.org; Tue, 3 Sep 2002 13:57:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83Hu6o09293; Tue, 3 Sep 2002 13:56:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83HqXo09140 for ; Tue, 3 Sep 2002 13:52:33 -0400 Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07034 for ; Tue, 3 Sep 2002 13:50:48 -0400 (EDT) Received: from host62-6-92-142.in-addr.btopenworld.com ([62.6.92.142] helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #8) id 17mHqf-0000gQ-00 for midcom@ietf.org; Tue, 03 Sep 2002 18:52:22 +0100 Message-ID: <003001c25372$ef5075c0$0200000a@tkw> From: "Pete Cordell" To: Date: Tue, 3 Sep 2002 18:54:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] SPAN issues discussion draft Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear All, I've submitted an Internet Draft discussing various design issues relating to a SPAN like protocol. This was started early on when the pre-midcom design team was established. I'm hoping that it will act as a framework around which to have further discussion about a SPAN type protocol. Note that intentionally not much effort has gone into making it editorially perfect as it is expected that further revisions will be required before all issues are sufficiently captured. Further, it is not intended that this progress beyond an internet draft so doesn't need the polish that an RFC would require. The draft will hopefully be called: draft-cordell-midcom-span-discuss-00.txt and should hopefully be available over the next few days. One thing is that I an on holiday after today for a week. The timing isn't great, but I'll get over it !!! (Note: the evaluation document that I suggested earlier is a separate effort and I plan to make a start on that when I get back.) Pete. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Sep 4 14:31:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14579 for ; Wed, 4 Sep 2002 14:31:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g84IWJk07832 for midcom-archive@odin.ietf.org; Wed, 4 Sep 2002 14:32:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84IUYo07632; Wed, 4 Sep 2002 14:30:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84ITko07586 for ; Wed, 4 Sep 2002 14:29:46 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14442 for ; Wed, 4 Sep 2002 14:28:06 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g84IT741015002 for ; Wed, 4 Sep 2002 11:29:07 -0700 (PDT) Received: from fluffyw2k (dhcp-128-107-209-53.cisco.com [128.107.209.53]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADX57430; Wed, 4 Sep 2002 11:29:18 -0700 (PDT) From: "Cullen Jennings" To: Subject: RE: [midcom] Moving SPAN along Date: Wed, 4 Sep 2002 11:29:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D746784.3070704@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] ... > We also want low overhead, as Pete has pointed out, since the target > applications are multimedia, although this is a general goal that any > VPN protocol would probably also have. To take this a step further - I think zero overhead would be desirable unless it was not possible. Cullen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Sep 5 07:21:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15249 for ; Thu, 5 Sep 2002 07:21:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g85BN1323139 for midcom-archive@odin.ietf.org; Thu, 5 Sep 2002 07:23:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85BLMo23092; Thu, 5 Sep 2002 07:21:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85BKeo23044 for ; Thu, 5 Sep 2002 07:20:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15070; Thu, 5 Sep 2002 07:19:02 -0400 (EDT) Message-Id: <200209051119.HAA15070@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, 05 Sep 2002 07:19:01 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-protocol-eval-05.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communications (MIDCOM) Protocol Evaluation Author(s) : M. Barnes Filename : draft-ietf-midcom-protocol-eval-05.txt Pages : 34 Date : 2002-9-4 This document provides an evaluation of the applicability of SNMP, RSIP, MEGACO, DIAMETER and COPS as the MIDCOM protocol. A summary of each of the proposed protocols against the MIDCOM requirements and MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-protocol-eval-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-protocol-eval-05.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: <2002-9-4143208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-protocol-eval-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-protocol-eval-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-4143208.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Sep 5 10:08:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19930 for ; Thu, 5 Sep 2002 10:08:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g85E9X202198 for midcom-archive@odin.ietf.org; Thu, 5 Sep 2002 10:09:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85E8Do02161; Thu, 5 Sep 2002 10:08:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85E72o02106 for ; Thu, 5 Sep 2002 10:07:02 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19873 for ; Thu, 5 Sep 2002 10:05:23 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g85E6P3x020420 for ; Thu, 5 Sep 2002 07:06:26 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AFA32722; Thu, 5 Sep 2002 07:02:31 -0700 (PDT) Message-Id: <200209051402.AFA32722@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 05 Sep 2002 10:06:28 -0400 Subject: [midcom] Internet-Drafts@ietf.org: I-D ACTION:draft-cordell-midcom-span-discuss-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , For those who didn't see the announcement, this document attempts to enumerate open, unresolved SPAN issues. Melinda ------- Forwarded Message Date: Thu, 05 Sep 2002 07:19:24 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-cordell-midcom-span-discuss-00.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPAN Discussion Issues Author(s) : P. Cordell Filename : draft-cordell-midcom-span-discuss-00.txt Pages : 12 Date : 2002-9-4 This document collects points of discussion surrounding the pre-midcom SPAN deliverable (SPAN = Simple Protocol for Augmenting NATs). As far as possible it is intended to act as a collation point for facts surrounding the SPAN deliverable. Where a discussion item is not black and white it attempts to collate opinion from all angles as far as the author is able to without bias. It does not draw conclusions of any sort. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-discuss-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-cordell-midcom-span-discuss-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-cordell-midcom-span-discuss-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-4143540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cordell-midcom-span-discuss-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-cordell-midcom-span-discuss-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-4143540.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Sep 5 11:10:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22273 for ; Thu, 5 Sep 2002 11:10:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g85FBFq05320 for midcom-archive@odin.ietf.org; Thu, 5 Sep 2002 11:11:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85FAHo05262; Thu, 5 Sep 2002 11:10:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85F9po05214 for ; Thu, 5 Sep 2002 11:09:52 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22194 for ; Thu, 5 Sep 2002 11:08:11 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g85F7t3x022556 for ; Thu, 5 Sep 2002 08:07:55 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AFA33930; Thu, 5 Sep 2002 08:04:00 -0700 (PDT) Message-Id: <200209051504.AFA33930@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 05 Sep 2002 11:07:57 -0400 Subject: [midcom] Update Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here's where we stand: 1) the STUN document is currently under scrutiny by security-type folks and they may or may not come back with suggested changes. Watch this space. 2) the protocol evaluation document is on the agenda for a future IESG meeting (I would not expect speedy feedback on either document) 3) we're still stalled on SPAN - are there people interested in volunteering to help with that? 4) there's still no resolution of the two semantics document. If people have a preference for one over the other it's time to make that preference known. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Sep 6 11:23:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06816 for ; Fri, 6 Sep 2002 11:23:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g86FO9G13955 for midcom-archive@odin.ietf.org; Fri, 6 Sep 2002 11:24:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g86FKXX13479; Fri, 6 Sep 2002 11:20:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85MXEt03536 for ; Thu, 5 Sep 2002 18:33:14 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10171 for ; Thu, 5 Sep 2002 18:31:30 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g85MWX3x008749 for ; Thu, 5 Sep 2002 15:32:33 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AFA52025; Thu, 5 Sep 2002 15:28:38 -0700 (PDT) Message-Id: <200209052228.AFA52025@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 05 Sep 2002 18:32:35 -0400 Subject: [midcom] More on the NAT MIB document Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , They're trying to get draft-ietf-nat-natmib-04.txt wrapped up for publication, so it would be helpful if comments could get in pretty quickly. Please try to give the document a review before next Wednesday, 11 September. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Sep 9 10:28:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03667 for ; Mon, 9 Sep 2002 10:28:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g89ETkw03488 for midcom-archive@odin.ietf.org; Mon, 9 Sep 2002 10:29:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89ES3v03318; Mon, 9 Sep 2002 10:28:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89EPev02045 for ; Mon, 9 Sep 2002 10:25:40 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03368 for ; Mon, 9 Sep 2002 10:24:03 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g89EPDU50368 for ; Mon, 9 Sep 2002 16:25:13 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 69AC049CDD for ; Mon, 9 Sep 2002 16:25:12 +0200 (CEST) Message-ID: <3D7CAF48.2050207@ccrle.nec.de> Date: Mon, 09 Sep 2002 16:25:12 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Subject: Re: [midcom] Semantics documents References: <4D79C746863DD51197690002A52CDA0001E8A80D@zcard0kc.ca.nortel.com> <33128616.1030559048@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, We couldn't agree with Tom on a joined semantics document. We have just submitted a new version of our suggestion for the MIDCOM semantics. You can preview it at: ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-stiemerling-midcom-semantics-02.txt The semantics now include: - semantics specification - conformance requirements for concrete protocols - transaction usage examples - statements on compliance with MIDCOM requirements This new version is much more elaborated and reflects all discussions items from the Yokohama meeting. Martin Juergen Quittek wrote: > Melinda, > > We already have a version of the document, which > - includes contributions from both documents > - considers all the comments and discussions of the last meeting and > - is much more elaborated. > > The document is ready for posting from Martin's and > my side. But still Tom needs to review it, because he > was out of the office for the last weeks. > > Juergen > > > --On 28 August 2002 11:26 -0400 Tom-PT Taylor > wrote: > >> >> I have to apologize -- my recent vacation has held up the effort to >> issue a >> single document. I, Martin, and Juergen have found ourselves in general >> agreement that this is possible. Essentially the detailed specification >> would be theirs, modified to take account of comments received, >> particularly >> at the meeting. As I understand it, we would still have a general >> lead-in >> which summarizes the implications of the framework and requirements >> documents, as presented in my draft. Again, this will be modified to fit >> what follows. >> >> -----Original Message----- >> From: Melinda Shore [mailto:mshore@cisco.com] >> Sent: Wednesday, August 28, 2002 11:06 AM >> To: midcom@ietf.org >> Subject: [midcom] Semantics documents >> >> >> We currently have two internet drafts describing what the >> authors see as the semantics of a midcom protocol. As we >> move closer to completing the evaluation document (WG last >> call closes tomorrow) and begin thinking about choosing a >> base protocol and designing the midcom protocol, the >> semantics description becomes more pressing. >> >> It appears that it's not going to be possible to combine the >> two drafts into one, and we're going to have to select one. >> Please take a look at both and try to select one as the >> basis for a working group document. The decision should >> revolve around document clarity and utility as the basis for >> creating an actual protocol. >> >> The URLs are: >> http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-semantics-01.tx >> >> t >> http://www.ietf.org/internet-drafts/draft-taylor-midcom-semantics-00.txt >> >> Thanks, >> >> Melinda >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Sep 9 12:20:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09222 for ; Mon, 9 Sep 2002 12:20:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g89GLJF15718 for midcom-archive@odin.ietf.org; Mon, 9 Sep 2002 12:21:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89GKAv15624; Mon, 9 Sep 2002 12:20:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89GHGv15483 for ; Mon, 9 Sep 2002 12:17:16 -0400 Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08987 for ; Mon, 9 Sep 2002 12:15:35 -0400 (EDT) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id MAA17024 for ; Mon, 9 Sep 2002 12:15:53 -0400 (EDT) To: midcom@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Mon, 9 Sep 2002 12:16:48 -0400 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 09/09/2002 12:15:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] STUN - draft-ietf-midocm-stun-02.txt questions Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Greetings to all. Can some give me a scenario where the use of the "Discard" flag is required? Peter _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Sep 9 12:49:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09885 for ; Mon, 9 Sep 2002 12:49:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g89Go7n17330 for midcom-archive@odin.ietf.org; Mon, 9 Sep 2002 12:50:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89GmCv17271; Mon, 9 Sep 2002 12:48:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89GlYv17232 for ; Mon, 9 Sep 2002 12:47:34 -0400 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09840 for ; Mon, 9 Sep 2002 12:45:57 -0400 (EDT) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g89GkvYH019362; Mon, 9 Sep 2002 12:46:58 -0400 (EDT) Message-ID: <3D7CD080.7000403@dynamicsoft.com> Date: Mon, 09 Sep 2002 12:46:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Panayiotis A. Thermos" CC: midcom@ietf.org Subject: Re: [midcom] STUN - draft-ietf-midocm-stun-02.txt questions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This discard flag is a simple way to keep a binding alive without having the server do any real work. STUN is a toolbag for accomplishing a variety of different things; this seemed a useful capability to have. -Jonathan R. Panayiotis A. Thermos wrote: > Greetings to all. > > Can some give me a scenario where the use of the "Discard" flag is > required? > > > Peter > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Sep 9 21:05:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21106 for ; Mon, 9 Sep 2002 21:05:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8A16dV12335 for midcom-archive@odin.ietf.org; Mon, 9 Sep 2002 21:06:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8A15Xv12289; Mon, 9 Sep 2002 21:05:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8A14cv12247 for ; Mon, 9 Sep 2002 21:04:38 -0400 Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21073 for ; Mon, 9 Sep 2002 21:02:56 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8A13lY11935; Mon, 9 Sep 2002 21:03:48 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Sep 2002 21:03:52 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A881@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Martin Stiemerling'" , midcom@ietf.org Subject: RE: [midcom] Semantics documents Date: Mon, 9 Sep 2002 21:03:43 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Sorry, misunderstanding. I'm submitting my document, reworked somewhat, as soon as I can, with the detailed semantics removed. Martin and Jouergen's document is more or less consistent with it, I think. > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Monday, September 09, 2002 10:25 AM > To: midcom@ietf.org > Subject: Re: [midcom] Semantics documents > > > Dear all, > > We couldn't agree with Tom on a joined semantics document. > > We have just submitted a new version of our suggestion for > the MIDCOM semantics. > > You can preview it at: > ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-stiemerling-m > idcom-semantics-02.txt > > The semantics now include: > - semantics specification > - conformance requirements for concrete protocols > - transaction usage examples > - statements on compliance with MIDCOM requirements > > This new version is much more elaborated and reflects all discussions > items from the Yokohama meeting. > > Martin > > Juergen Quittek wrote: > > Melinda, > > > > We already have a version of the document, which > > - includes contributions from both documents > > - considers all the comments and discussions of the last > meeting and > > - is much more elaborated. > > > > The document is ready for posting from Martin's and > > my side. But still Tom needs to review it, because he > > was out of the office for the last weeks. > > > > Juergen > > > > > > --On 28 August 2002 11:26 -0400 Tom-PT Taylor > > wrote: > > > >> > >> I have to apologize -- my recent vacation has held up the effort to > >> issue a > >> single document. I, Martin, and Juergen have found > ourselves in general > >> agreement that this is possible. Essentially the detailed > specification > >> would be theirs, modified to take account of comments received, > >> particularly > >> at the meeting. As I understand it, we would still have a general > >> lead-in > >> which summarizes the implications of the framework and requirements > >> documents, as presented in my draft. Again, this will be > modified to fit > >> what follows. > >> > >> -----Original Message----- > >> From: Melinda Shore [mailto:mshore@cisco.com] > >> Sent: Wednesday, August 28, 2002 11:06 AM > >> To: midcom@ietf.org > >> Subject: [midcom] Semantics documents > >> > >> > >> We currently have two internet drafts describing what the > authors see > >> as the semantics of a midcom protocol. As we move closer to > >> completing the evaluation document (WG last call closes > tomorrow) and > >> begin thinking about choosing a base protocol and designing the > >> midcom protocol, the semantics description becomes more pressing. > >> > >> It appears that it's not going to be possible to combine the two > >> drafts into one, and we're going to have to select one. > Please take a > >> look at both and try to select one as the basis for a > working group > >> document. The decision should revolve around document clarity and > >> utility as the basis for creating an actual protocol. > >> > >> The URLs are: > >> > http://www.ietf.org/internet-drafts/draft-> stiemerling-midcom-semantic > >> s-01.tx > >> > >> t > >> > http://www.ietf.org/internet-drafts/draft-> taylor-midcom-semantics-00. > >> txt > >> > >> Thanks, > >> > >> Melinda > >> _______________________________________________ > >> midcom mailing list > >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom > >> _______________________________________________ > >> midcom mailing list > >> midcom@ietf.org > >> https://www1.ietf.org/mailman/listinfo/midcom > > > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > -- > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 10 06:16:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08843 for ; Tue, 10 Sep 2002 06:16:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8AAHVU14997 for midcom-archive@odin.ietf.org; Tue, 10 Sep 2002 06:17:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8AAGAv14964; Tue, 10 Sep 2002 06:16:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8AAFFv14927 for ; Tue, 10 Sep 2002 06:15:15 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08797 for ; Tue, 10 Sep 2002 06:13:34 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g8AAEhU80768; Tue, 10 Sep 2002 12:14:43 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B4DE25E8EF; Tue, 10 Sep 2002 12:14:41 +0200 (CEST) Date: Tue, 10 Sep 2002 12:14:42 +0200 From: Juergen Quittek To: Tom-PT Taylor , "'Martin Stiemerling'" , midcom@ietf.org Subject: RE: [midcom] Semantics documents Message-ID: <7452245.1031660082@[192.168.102.164]> In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A881@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA0001E8A881@zcard0kc.ca.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, Yes, correct: our ideas are consistent now. Martin just said that three of us could not agree on a joint document. That's why we post two individual ones. Juergen -- Tom-PT Taylor wrote on 09 September 2002 21:03 -0400: > Sorry, misunderstanding. I'm submitting my document, reworked somewhat, as > soon as I can, with the detailed semantics removed. Martin and Jouergen's > document is more or less consistent with it, I think. > >> -----Original Message----- >> From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] >> Sent: Monday, September 09, 2002 10:25 AM >> To: midcom@ietf.org >> Subject: Re: [midcom] Semantics documents >> >> >> Dear all, >> >> We couldn't agree with Tom on a joined semantics document. >> >> We have just submitted a new version of our suggestion for >> the MIDCOM semantics. >> >> You can preview it at: >> ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-stiemerling-m >> idcom-semantics-02.txt >> >> The semantics now include: >> - semantics specification >> - conformance requirements for concrete protocols >> - transaction usage examples >> - statements on compliance with MIDCOM requirements >> >> This new version is much more elaborated and reflects all discussions >> items from the Yokohama meeting. >> >> Martin >> >> Juergen Quittek wrote: >> > Melinda, >> > >> > We already have a version of the document, which >> > - includes contributions from both documents >> > - considers all the comments and discussions of the last >> meeting and >> > - is much more elaborated. >> > >> > The document is ready for posting from Martin's and >> > my side. But still Tom needs to review it, because he >> > was out of the office for the last weeks. >> > >> > Juergen >> > >> > >> > --On 28 August 2002 11:26 -0400 Tom-PT Taylor >> > wrote: >> > >> >> >> >> I have to apologize -- my recent vacation has held up the effort to >> >> issue a >> >> single document. I, Martin, and Juergen have found >> ourselves in general >> >> agreement that this is possible. Essentially the detailed >> specification >> >> would be theirs, modified to take account of comments received, >> >> particularly >> >> at the meeting. As I understand it, we would still have a general >> >> lead-in >> >> which summarizes the implications of the framework and requirements >> >> documents, as presented in my draft. Again, this will be >> modified to fit >> >> what follows. >> >> >> >> -----Original Message----- >> >> From: Melinda Shore [mailto:mshore@cisco.com] >> >> Sent: Wednesday, August 28, 2002 11:06 AM >> >> To: midcom@ietf.org >> >> Subject: [midcom] Semantics documents >> >> >> >> >> >> We currently have two internet drafts describing what the >> authors see >> >> as the semantics of a midcom protocol. As we move closer to >> >> completing the evaluation document (WG last call closes >> tomorrow) and >> >> begin thinking about choosing a base protocol and designing the >> >> midcom protocol, the semantics description becomes more pressing. >> >> >> >> It appears that it's not going to be possible to combine the two >> >> drafts into one, and we're going to have to select one. >> Please take a >> >> look at both and try to select one as the basis for a >> working group >> >> document. The decision should revolve around document clarity and >> >> utility as the basis for creating an actual protocol. >> >> >> >> The URLs are: >> >> >> http://www.ietf.org/internet-drafts/draft-> stiemerling-midcom-semantic >> >> s-01.tx >> >> >> >> t >> >> >> http://www.ietf.org/internet-drafts/draft-> taylor-midcom-semantics-00. >> >> txt >> >> >> >> Thanks, >> >> >> >> Melinda >> >> _______________________________________________ >> >> midcom mailing list >> >> midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom >> >> _______________________________________________ >> >> midcom mailing list >> >> midcom@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/midcom >> > >> > >> > >> > _______________________________________________ >> > midcom mailing list >> > midcom@ietf.org >> > https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> -- >> Martin Stiemerling >> >> NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de >> IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom >> > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 10 08:10:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10363 for ; Tue, 10 Sep 2002 08:10:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8ACBsf20086 for midcom-archive@odin.ietf.org; Tue, 10 Sep 2002 08:11:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8ACACv20052; Tue, 10 Sep 2002 08:10:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8AC9mv20028 for ; Tue, 10 Sep 2002 08:09:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10233; Tue, 10 Sep 2002 08:08:05 -0400 (EDT) Message-Id: <200209101208.IAA10233@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 10 Sep 2002 08:08:05 -0400 Subject: [midcom] I-D ACTION:draft-stiemerling-midcom-semantics-02.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIDCOM Protocol Semantics Author(s) : M. Stiemerling, J. Quittek Filename : draft-stiemerling-midcom-semantics-02.txt Pages : 51 Date : 2002-9-9 This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-semantics-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stiemerling-midcom-semantics-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-midcom-semantics-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-9145440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stiemerling-midcom-semantics-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-stiemerling-midcom-semantics-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-9145440.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Sep 11 10:32:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11004 for ; Wed, 11 Sep 2002 10:32:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8BEY1519128 for midcom-archive@odin.ietf.org; Wed, 11 Sep 2002 10:34:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BEWYv19003; Wed, 11 Sep 2002 10:32:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BESZv18714 for ; Wed, 11 Sep 2002 10:28:35 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10801 for ; Wed, 11 Sep 2002 10:26:50 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g8BERbU37575; Wed, 11 Sep 2002 16:27:37 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 7D22E5C952; Wed, 11 Sep 2002 16:27:28 +0200 (CEST) Date: Wed, 11 Sep 2002 16:27:28 +0200 From: Juergen Quittek To: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] More on the NAT MIB document Message-ID: <21701805.1031761648@[192.168.102.164]> In-Reply-To: <200209052228.AFA52025@mira-sjc5-4.cisco.com> References: <200209052228.AFA52025@mira-sjc5-4.cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda, Here are my comments on the NAT MIB: ========================================== General comment (from MIDCOM perspective): ========================================== It appears that if SNMP would be selected as MIDCOM protocol, we could completely re-use the NAT MIB and just add one or two tables and a few objects for having a MIDCOM MIB. However, the functionality of the NAT MIB is probably more than MIDCOM requires. Missing functionality includes grouping of bindings and port oddity requests. ========================== MIB objects and semantics: ========================== - The NatConfAddrMapEntry of the NatConfAddrMapTable is missing an object for requesting specific oddity of port numbers provided by the NAT. Reference: MIDCOM requirement described in section 2.2.9 of RFC 3304. - In the NatAddrBindTable a local address, a gloabal address, and a direction can be specified. However, the managed object natAddrBindDirection has a value of either 'uniDirectional' or 'biDirectional'. This does not appear to be sufficient in the unidirectional case, because you do not know whether it is inbound or outbound. I would suggest to use 'inbound', 'outbound', and 'biDirectional' as set of allowed values for this object. - The same applies to NatAddrPortBindTable. - A related issue is object natSessionDirection: Why is there no support for bi-diractional sessions? - I would suggest adding another object to the NatAddrBindEntry specifying the origin (or creator) of the entry. This can be done very general {SNMP, CLI, other protcol} or it can be an authenticated (SNMP) user ID. - The same applies to NatAddrPortBindTable. - I wonder why NatAddrBindTable and NatAddrPortBindTable are different tables. A single table should be sufficient for serving both purposes. Most objects are the same in both tables and another object acting as a flag for distinguishing AddrBindings and AddrPortBindings should be sufficient. =========== SMI syntax: =========== There is a missing comma in definition of natConfProtGroup just after object natConfProtConfigName. ========= Phrasing: ========= In the description of object natAddrBindAddrMapName I would replace "the Management System" by "an SNMP manager". Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- Melinda Shore wrote on 05 September 2002 18:32 -0400: > They're trying to get draft-ietf-nat-natmib-04.txt wrapped > up for publication, so it would be helpful if comments could > get in pretty quickly. Please try to give the document a > review before next Wednesday, 11 September. > > Thanks, > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Sep 13 04:50:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28882 for ; Fri, 13 Sep 2002 04:50:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8D8pg909943 for midcom-archive@odin.ietf.org; Fri, 13 Sep 2002 04:51:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8D8mfv09817; Fri, 13 Sep 2002 04:48:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8D8ldv09774 for ; Fri, 13 Sep 2002 04:47:39 -0400 Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28642 for ; Fri, 13 Sep 2002 04:45:40 -0400 (EDT) Received: from host213-1-184-35.in-addr.btopenworld.com ([213.1.184.35] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 17pm6i-0004zo-00; Fri, 13 Sep 2002 09:47:21 +0100 Message-ID: <007a01c25b02$7c5b0fc0$0200000a@tkw> From: "Pete Cordell" To: , "Melinda Shore" References: <200209051402.AFA32722@mira-sjc5-4.cisco.com> Subject: Re: [midcom] Internet-Drafts@ietf.org: I-D ACTION:draft-cordell-midcom-span-discuss-00.txt Date: Fri, 13 Sep 2002 09:46:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This document really discusses issues relating to a SPAN deliverable hopefully without bias to any particular solution. SPAN-A (Candidate SPAN protocol 'A' and the earlier SPAN related document), obviously has to fall one side or other of the fence on the various issues raised in the discussion document. As such, from a SPAN-A point of view, the issues are resolved. Naturally it can jump the other side of the fence if its determined that the wrong decisions have been made. Pete. (Back from holiday) ----- Original Message ----- From: "Melinda Shore" To: Sent: 05 September 2002 15:06 Subject: [midcom] Internet-Drafts@ietf.org: I-D ACTION:draft-cordell-midcom-span-discuss-00.txt > For those who didn't see the announcement, this document > attempts to enumerate open, unresolved SPAN issues. > > Melinda > > ------- Forwarded Message > > Date: Thu, 05 Sep 2002 07:19:24 -0400 > From: Internet-Drafts@ietf.org > To: IETF-Announce: ; > Subject: I-D ACTION:draft-cordell-midcom-span-discuss-00.txt > > - --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SPAN Discussion Issues > Author(s) : P. Cordell > Filename : draft-cordell-midcom-span-discuss-00.txt > Pages : 12 > Date : 2002-9-4 > > This document collects points of discussion surrounding the > pre-midcom SPAN deliverable (SPAN = Simple Protocol for Augmenting > NATs). As far as possible it is intended to act as a collation point > for facts surrounding the SPAN deliverable. Where a discussion item > is not black and white it attempts to collate opinion from all angles > as far as the author is able to without bias. It does not draw > conclusions of any sort. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-discuss-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-cordell-midcom-span-discuss-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-cordell-midcom-span-discuss-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > - --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > - --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <2002-9-4143540.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-cordell-midcom-span-discuss-00.txt > > - --OtherAccess > Content-Type: Message/External-body; > name="draft-cordell-midcom-span-discuss-00.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <2002-9-4143540.I-D@ietf.org> > > - --OtherAccess-- > > - --NextPart-- > > > > ------- End of Forwarded Message > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Sep 13 23:21:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24961 for ; Fri, 13 Sep 2002 23:21:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8E3MNr00872 for midcom-archive@odin.ietf.org; Fri, 13 Sep 2002 23:22:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8E3JWv00771; Fri, 13 Sep 2002 23:19:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8E3IWv00754 for ; Fri, 13 Sep 2002 23:18:32 -0400 Received: from web40412.mail.yahoo.com (web40412.mail.yahoo.com [66.218.78.109]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24824 for ; Fri, 13 Sep 2002 23:16:40 -0400 (EDT) Message-ID: <20020914031752.87752.qmail@web40412.mail.yahoo.com> Received: from [12.36.127.12] by web40412.mail.yahoo.com via HTTP; Fri, 13 Sep 2002 20:17:52 PDT Date: Fri, 13 Sep 2002 20:17:52 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] More on the NAT MIB document To: Juergen Quittek , Melinda Shore , midcom@ietf.org Cc: rohit.rohit@worldwidepackets.com, npai@cisco.com, rrajiv@cisco.com, cwang@smartpipes.com, srisuresh@yahoo.com In-Reply-To: <21701805.1031761648@[192.168.102.164]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Juergen, Thanks very much for your detailed comments. NAT MIB functioanlity was meant principally for configuring the NAT devices - Not as a MIDCOM protocol per se. However, as you noticed, the NAT MIB may be meeting the MIDCOM protocol requirements for a NAT Middlebox. Please see my specific responses below. regards, sures --- Juergen Quittek wrote: > Melinda, > > Here are my comments on the NAT MIB: > > ========================================== > General comment (from MIDCOM perspective): > ========================================== > > It appears that if SNMP would be selected as MIDCOM > protocol, we could completely re-use the NAT MIB and > just add one or two tables and a few objects for > having a MIDCOM MIB. However, the functionality of > the NAT MIB is probably more than MIDCOM requires. > Missing functionality includes grouping of bindings > and port oddity requests. > > ========================== > MIB objects and semantics: > ========================== > > - The NatConfAddrMapEntry of the NatConfAddrMapTable is missing > an object for requesting specific oddity of port numbers > provided by the NAT. Reference: MIDCOM requirement described > in section 2.2.9 of RFC 3304. > The odditt requirement is covered by the fact that a static port map range can be defined. Please refer the mapping fields - (natConfLocalPortFrom, natConfLocalPortTo) --> (natConfGlobalAddrFrom, natConfGlobalPortto) > - In the NatAddrBindTable a local address, a gloabal address, > and a direction can be specified. However, the managed object > natAddrBindDirection has a value of either 'uniDirectional' or > 'biDirectional'. This does not appear to be sufficient in the > unidirectional case, because you do not know whether it is > inbound or outbound. I would suggest to use 'inbound', > 'outbound', and 'biDirectional' as set of allowed values for > this object. > BIND itself has to be derived from the address map and the associated direction specific in the address map. Please refer the description, which I reproduced below for your convenience. "This object represents the direction of the BIND. A BIND may be either uni-directional or bi-directional, same as the orientation of the address map, based on which this bind is formed." > - The same applies to NatAddrPortBindTable. > Please see the explanation above. > - A related issue is object natSessionDirection: Why is there > no support for bi-diractional sessions? > Every session traversing a NAT device has a session direction. It has to be inbound or outbound - not both, right. > - I would suggest adding another object to the NatAddrBindEntry > specifying the origin (or creator) of the entry. This can be > done very general {SNMP, CLI, other protcol} or it can be > an authenticated (SNMP) user ID. What did you mean by the origin - The address map the BIND refers to (or) the session that triggered this. If you meant the first, it exists already - natAddrBindAddrMapName. As for the second, sessions are fleeting and could have disappeared even as the BIND remained. So, I dont believe, it wouldnt be right to keep reference to the session in BIND. > > - The same applies to NatAddrPortBindTable. > Please see the comment above. > - I wonder why NatAddrBindTable and NatAddrPortBindTable > are different tables. A single table should be sufficient > for serving both purposes. Most objects are the same in both > tables and another object acting as a flag for distinguishing > AddrBindings and AddrPortBindings should be sufficient. Makes sense to me. However, I will let my co-authors comment on this. > > =========== > SMI syntax: > =========== > > There is a missing comma in definition of natConfProtGroup > just after object natConfProtConfigName. > > Got it. Thanks. > ========= > Phrasing: > ========= > > In the description of object natAddrBindAddrMapName I would > replace "the Management System" by "an SNMP manager". > > Will do. > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > -- Melinda Shore wrote on 05 September 2002 18:32 -0400: > > > They're trying to get draft-ietf-nat-natmib-04.txt wrapped > > up for publication, so it would be helpful if comments could > > get in pretty quickly. Please try to give the document a > > review before next Wednesday, 11 September. > > > > Thanks, > > > > Melinda > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom ===== __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sun Sep 15 17:25:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11317 for ; Sun, 15 Sep 2002 17:25:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8FLQs614190 for midcom-archive@odin.ietf.org; Sun, 15 Sep 2002 17:26:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8FLMGv14119; Sun, 15 Sep 2002 17:22:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8FLFTv13966 for ; Sun, 15 Sep 2002 17:15:29 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11204; Sun, 15 Sep 2002 17:13:39 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8FLEqW4028493; Sun, 15 Sep 2002 14:14:52 -0700 (PDT) Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id AEA22891; Sun, 15 Sep 2002 14:14:57 -0700 (PDT) From: "Cullen Jennings" To: , Cc: , , , "Midcom" Date: Sun, 15 Sep 2002 14:15:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [midcom] Comments on draft-sen-sipping-intrarealm-stun-00 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is an interesting approach to solving this problem and it got my thinking about it. First I have a few suggestions, then a few concerns, and final an idea for a bit of a change. A few suggestions ..... You could easily abstract the sip part of this draft out and make it a midcom draft by just saying that the initial address information get passed by some protocol from A to B. I think it would be better for the originating UA to provide a supported connected-stun not a requires - the call will still work even if the other side does not do connected-stun. If A and B have discovered different IP address for their public media address - it is very unlikely they are in the same private space. (The previous statement might not be true - it is based on the assumption that NAT is not really used but that PAT is). However the converse of this is not true - just because they are behind the same outermost NAT, does not mean there are not other NATs along the path. For example, a cable provider may NAT all their customers but each customer may have their own NAT at their home. In this example the outmost NAT for two cable customers is the same, it is the ISPs NAT but the customers phones are in separate private spaces because they have further NATs My big concern ....... The idea that I could send a packet from outside the firewall to a port on the NAT which would send it to a stun server on the inside of the NAT and firewall which would send it to any machine I wished inside someone's private network is very concerning for me. An idea ........ So let me summarize a change to this idea. I would like this to work for many things that use STUN not just SIP. I see that that there are two things we are trying to learn by the technique covered in this draft. The first is "Are these two devices in the same private address space?" and the second is "Does the outermost NAT support hairpinning?" On the first questions - I think that at a very high level the solution needs to look something like A passes B a token and his private address via some previously established channel. B tries to send the token to A's private address. If A receives it he knows how to communicate with B over the private network. I think you have hit on a good idea that STUN, or something like it might be a good protocol to send the token to B to A. The part of STUN that I think makes it good for this is it's security properties. Stop snickering, seriously I think it has about the right security attributes. So how about simplifying your proposal to something along the lines of A generates a normal STUN OTP (One Time Password) puts it in the SIP signaling along with a Supported connected-stun and sends it along. When B receives this, B can first check if the media ports look like they might be behind the same outermost NAT. If so it can proceed with trying to send a STUN PING request to A. If A gets a OTP that matches - it sends a reply to B to stop the retransmissions and knows it can communicate with B. One part I like of this is that in the case that A is not in the same domain as A, B is spamming only other devices on it's private network with packets that it created. The STUN server on A would need to be defined to not be a proper STUN server but a new type, lets call it a STUN PING server. It would always ignore the change address and change port stuff, would also send a response to where the request had come from, and would not need to do the TLS stuff to hand out OTP. Because of retransmission this whole process could take some time so the main communications (the RTP in the SIP case) need to proceed as if they were not in the same domain then be switched to the private domain mid call. The second question is how to figure out if the outermost NAT supports hairpinning. It would be really nice to do this before the phone started ringing because if it does not, and you are not in the same private space, you pretty much need to go to a media relay solution such as TURN. I think this could be done around the same time that the device figures out if the NAT is symmetric or no. The device finds it's public address, sends it's self a packet from a different port and sees if it receives it or not. Sorry this email is so long but I hope it is helpful, Cullen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Sep 16 07:42:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00602 for ; Mon, 16 Sep 2002 07:42:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GBiCf25032 for midcom-archive@odin.ietf.org; Mon, 16 Sep 2002 07:44:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GBdcv24860; Mon, 16 Sep 2002 07:39:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8G9pPv20195 for ; Mon, 16 Sep 2002 05:51:25 -0400 Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29318 for ; Mon, 16 Sep 2002 05:49:33 -0400 (EDT) Received: from host213-122-131-243.in-addr.btopenworld.com ([213.122.131.243] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #8) id 17qsXC-0005eR-00; Mon, 16 Sep 2002 10:51:14 +0100 Message-ID: <008501c25d66$dbc89c00$0200000a@tkw> From: "Pete Cordell" To: "Cullen Jennings" , References: Subject: Re: [midcom] Moving SPAN along Date: Mon, 16 Sep 2002 10:52:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen, [Catching up after holiday...] Just to let you know, I agree with the objective you stated below. However I'm also aware that you don't (usually) get something for nothing. If there is stuff that is superfluous, then it should be cut out. There's no point in carrying bits around just for the sake of it (unless it's XML :-) Pete. ----- Original Message ----- From: "Cullen Jennings" To: Sent: 04 September 2002 19:29 Subject: RE: [midcom] Moving SPAN along > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > ... > > We also want low overhead, as Pete has pointed out, since the target > > applications are multimedia, although this is a general goal that any > > VPN protocol would probably also have. > > To take this a step further - I think zero overhead would be desirable > unless it was not possible. > > Cullen > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Sep 16 12:40:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10387 for ; Mon, 16 Sep 2002 12:40:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8GGfaC11027 for midcom-archive@odin.ietf.org; Mon, 16 Sep 2002 12:41:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GGeJv10991; Mon, 16 Sep 2002 12:40:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GGdDv10933 for ; Mon, 16 Sep 2002 12:39:13 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10319 for ; Mon, 16 Sep 2002 12:37:25 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g8GGc6U92889; Mon, 16 Sep 2002 18:38:06 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 693DC4F70A; Mon, 16 Sep 2002 18:38:01 +0200 (CEST) Date: Mon, 16 Sep 2002 18:38:01 +0200 From: Juergen Quittek To: Pyda Srisuresh , Melinda Shore , midcom@ietf.org Cc: rohit.rohit@worldwidepackets.com, npai@cisco.com, rrajiv@cisco.com, cwang@smartpipes.com Subject: Re: [midcom] More on the NAT MIB document Message-ID: <34894575.1032201481@[192.168.102.164]> In-Reply-To: <20020914031752.87752.qmail@web40412.mail.yahoo.com> References: <20020914031752.87752.qmail@web40412.mail.yahoo.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Pyda, First of all, I think you did a great job in defining this MIB. It appears to be very mature and to cover all requirements. However, some more text explaining the MIB might be helpful. For example, the operational model of the natConfAddrMapTable is not explained in detail: how to create an entry (and set up the corresponding binding) using natConfProtRowStatus or how to configura all required entries for a single TCP connection. But things like these can be added in a later version of the MIB document when implementations are available and a progress in standardization status is ahead. Please see some more comments inline. Juergen -- Pyda Srisuresh wrote on 13 September 2002 20:17 -0700: > Juergen, > > Thanks very much for your detailed comments. > > NAT MIB functioanlity was meant principally for configuring the NAT > devices - Not as a MIDCOM protocol per se. > However, as you noticed, the NAT MIB may be meeting the MIDCOM > protocol requirements for a NAT Middlebox. > > Please see my specific responses below. > > regards, > sures > > --- Juergen Quittek wrote: >> Melinda, >> >> Here are my comments on the NAT MIB: >> >> ========================================== >> General comment (from MIDCOM perspective): >> ========================================== >> >> It appears that if SNMP would be selected as MIDCOM >> protocol, we could completely re-use the NAT MIB and >> just add one or two tables and a few objects for >> having a MIDCOM MIB. However, the functionality of >> the NAT MIB is probably more than MIDCOM requires. >> Missing functionality includes grouping of bindings >> and port oddity requests. >> >> ========================== >> MIB objects and semantics: >> ========================== >> >> - The NatConfAddrMapEntry of the NatConfAddrMapTable is missing >> an object for requesting specific oddity of port numbers >> provided by the NAT. Reference: MIDCOM requirement described >> in section 2.2.9 of RFC 3304. >> > The odditt requirement is covered by the fact that a static port map range > can be defined. Please refer the mapping fields - > (natConfLocalPortFrom, natConfLocalPortTo) --> > (natConfGlobalAddrFrom, natConfGlobalPortto) OK, so if you want fixed port oddity, you have to select the port numbers yourself, and you cannot use dynamic assignment. >> - In the NatAddrBindTable a local address, a gloabal address, >> and a direction can be specified. However, the managed object >> natAddrBindDirection has a value of either 'uniDirectional' or >> 'biDirectional'. This does not appear to be sufficient in the >> unidirectional case, because you do not know whether it is >> inbound or outbound. I would suggest to use 'inbound', >> 'outbound', and 'biDirectional' as set of allowed values for >> this object. >> > > BIND itself has to be derived from the address map and the associated > direction specific in the address map. Please refer the description, > which I reproduced below for your convenience. > > "This object represents the direction of the BIND. > A BIND may be either uni-directional or bi-directional, > same as the orientation of the address map, based on > which this bind is formed." I see. But unfortunately, I do not fully understand. Could you comment on possible combinations of {inbound, outbound, both} maps and {uni-dir, bi-dir} bindings? >> - The same applies to NatAddrPortBindTable. >> > Please see the explanation above. > >> - A related issue is object natSessionDirection: Why is there >> no support for bi-diractional sessions? >> > > Every session traversing a NAT device has a session direction. It has > to be inbound or outbound - not both, right. So this is the direction of session creation and not necessarily related to the directions of the corresponding map and/or binding? >> - I would suggest adding another object to the NatAddrBindEntry >> specifying the origin (or creator) of the entry. This can be >> done very general {SNMP, CLI, other protcol} or it can be >> an authenticated (SNMP) user ID. > > What did you mean by the origin - The address map the BIND refers to > (or) the session that triggered this. > If you meant the first, it exists already - natAddrBindAddrMapName. > > As for the second, sessions are fleeting and could have disappeared > even as the BIND remained. So, I dont believe, it wouldnt be right to keep > reference to the session in BIND. Sorry, I referred to the wrong table. I wanted to refer to the natConfAddrMapTable, not to the natAddrBindTable. My point is, that it might be useful to know, whether an entry was created by an SNMP manager, at the CLI, or by a configuraton file, ... >> >> - The same applies to NatAddrPortBindTable. >> > Please see the comment above. > >> - I wonder why NatAddrBindTable and NatAddrPortBindTable >> are different tables. A single table should be sufficient >> for serving both purposes. Most objects are the same in both >> tables and another object acting as a flag for distinguishing >> AddrBindings and AddrPortBindings should be sufficient. > > Makes sense to me. However, I will let my co-authors comment on this. >> >> =========== >> SMI syntax: >> =========== >> >> There is a missing comma in definition of natConfProtGroup >> just after object natConfProtConfigName. >> >> > Got it. Thanks. > >> ========= >> Phrasing: >> ========= >> >> In the description of object natAddrBindAddrMapName I would >> replace "the Management System" by "an SNMP manager". >> >> > > Will do. Sorry about this. I already found that this comment of mine was nonsense. "management station" is the proper term. Juergen >> -- >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> >> >> -- Melinda Shore wrote on 05 September 2002 18:32 -0400: >> >> > They're trying to get draft-ietf-nat-natmib-04.txt wrapped >> > up for publication, so it would be helpful if comments could >> > get in pretty quickly. Please try to give the document a >> > review before next Wednesday, 11 September. >> > >> > Thanks, >> > >> > Melinda >> > _______________________________________________ >> > midcom mailing list >> > midcom@ietf.org >> > https://www1.ietf.org/mailman/listinfo/midcom >> >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom > > > ===== > > > __________________________________________________ > Do you Yahoo!? > Yahoo! News - Today's headlines > http://news.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 17 02:43:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05893 for ; Tue, 17 Sep 2002 02:43:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8H6icT25667 for midcom-archive@odin.ietf.org; Tue, 17 Sep 2002 02:44:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8H6Xwv24757; Tue, 17 Sep 2002 02:33:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8H6W4v24674 for ; Tue, 17 Sep 2002 02:32:04 -0400 Received: from web40403.mail.yahoo.com (web40403.mail.yahoo.com [66.218.78.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05684 for ; Tue, 17 Sep 2002 02:30:08 -0400 (EDT) Message-ID: <20020917063122.78436.qmail@web40403.mail.yahoo.com> Received: from [12.36.127.12] by web40403.mail.yahoo.com via HTTP; Mon, 16 Sep 2002 23:31:22 PDT Date: Mon, 16 Sep 2002 23:31:22 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] More on the NAT MIB document To: Juergen Quittek , Melinda Shore , midcom@ietf.org Cc: rohit.rohit@worldwidepackets.com, npai@cisco.com, rrajiv@cisco.com, cwang@smartpipes.com In-Reply-To: <34894575.1032201481@[192.168.102.164]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Juergen Quittek wrote: > Hi Pyda, > > First of all, I think you did a great job in defining this MIB. > It appears to be very mature and to cover all requirements. Thanks. It has been a team effort. > > However, some more text explaining the MIB might be helpful. > For example, the operational model of the natConfAddrMapTable > is not explained in detail: how to create an entry (and set up > the corresponding binding) using natConfProtRowStatus or > how to configura all required entries for a single TCP > connection. > No problem. > But things like these can be added in a later version of > the MIB document when implementations are available and > a progress in standardization status is ahead. > > Please see some more comments inline. > > Juergen > Thanks, Juergen. My responses below. regards, suresh > -- Pyda Srisuresh wrote on 13 September 2002 20:17 -0700: > > > Juergen, > > > > Thanks very much for your detailed comments. > > > > NAT MIB functioanlity was meant principally for configuring the NAT > > devices - Not as a MIDCOM protocol per se. > > However, as you noticed, the NAT MIB may be meeting the MIDCOM > > protocol requirements for a NAT Middlebox. > > > > Please see my specific responses below. > > > > regards, > > sures > > > > --- Juergen Quittek wrote: > >> Melinda, > >> > >> Here are my comments on the NAT MIB: > >> > >> ========================================== > >> General comment (from MIDCOM perspective): > >> ========================================== > >> > >> It appears that if SNMP would be selected as MIDCOM > >> protocol, we could completely re-use the NAT MIB and > >> just add one or two tables and a few objects for > >> having a MIDCOM MIB. However, the functionality of > >> the NAT MIB is probably more than MIDCOM requires. > >> Missing functionality includes grouping of bindings > >> and port oddity requests. > >> > >> ========================== > >> MIB objects and semantics: > >> ========================== > >> > >> - The NatConfAddrMapEntry of the NatConfAddrMapTable is missing > >> an object for requesting specific oddity of port numbers > >> provided by the NAT. Reference: MIDCOM requirement described > >> in section 2.2.9 of RFC 3304. > >> > > The odditt requirement is covered by the fact that a static port map range > > can be defined. Please refer the mapping fields - > > (natConfLocalPortFrom, natConfLocalPortTo) --> > > (natConfGlobalAddrFrom, natConfGlobalPortto) > > OK, so if you want fixed port oddity, you have to select the port > numbers yourself, and you cannot use dynamic assignment. Actually, I misstated this in my previouss e-mail. Specifying static port maps in the AddressMap Table is a way. But, that would be a poor way to do. However, specifying the above through NatAddrPortBindEntry would be the right way to do. For example, the external agent could add two PortBind entires - one after the other. Extending NatAddrPortBindEntry to specify port range (i.e., PortFrom and PortTo), instead of a single port would be another way to do this. But, I believe, the current approach of making two entries with NatAddrPortBindEntry as it stands would be adequate. > > >> - In the NatAddrBindTable a local address, a gloabal address, > >> and a direction can be specified. However, the managed object > >> natAddrBindDirection has a value of either 'uniDirectional' or > >> 'biDirectional'. This does not appear to be sufficient in the > >> unidirectional case, because you do not know whether it is > >> inbound or outbound. I would suggest to use 'inbound', > >> 'outbound', and 'biDirectional' as set of allowed values for > >> this object. > >> > > > > BIND itself has to be derived from the address map and the associated > > direction specific in the address map. Please refer the description, > > which I reproduced below for your convenience. > > > > "This object represents the direction of the BIND. > > A BIND may be either uni-directional or bi-directional, > > same as the orientation of the address map, based on > > which this bind is formed." > > I see. But unfortunately, I do not fully understand. > Could you comment on possible combinations of {inbound, outbound, both} > maps and {uni-dir, bi-dir} bindings? Well, a BIND may be derived by NAT, based on the sessions noticed in the ingress direction, Egress direction or both. ex: You could generate a BIND for a bi-directional NAT by looking up the address maps for sessions in either direction. Whereas, you would create and reuse the BINDS only for outbound sessions with a traditional NAT. Hope this helps. > > >> - The same applies to NatAddrPortBindTable. > >> > > Please see the explanation above. > > > >> - A related issue is object natSessionDirection: Why is there > >> no support for bi-diractional sessions? > >> > > > > Every session traversing a NAT device has a session direction. It has > > to be inbound or outbound - not both, right. > > So this is the direction of session creation and not necessarily > related to the directions of the corresponding map and/or binding? Yes. > > >> - I would suggest adding another object to the NatAddrBindEntry > >> specifying the origin (or creator) of the entry. This can be > >> done very general {SNMP, CLI, other protcol} or it can be > >> an authenticated (SNMP) user ID. > > > > What did you mean by the origin - The address map the BIND refers to > > (or) the session that triggered this. > > If you meant the first, it exists already - natAddrBindAddrMapName. > > > > As for the second, sessions are fleeting and could have disappeared > > even as the BIND remained. So, I dont believe, it wouldnt be right to keep > > reference to the session in BIND. > > Sorry, I referred to the wrong table. I wanted to refer to the > natConfAddrMapTable, not to the natAddrBindTable. My point is, that > it might be useful to know, whether an entry was created by an SNMP > manager, at the CLI, or by a configuraton file, ... > Well, address maps are not changed frequently. Usually, they are set just once for the box. BINDs, on the other hand, may be created dynamically, either by the NAT (based on address maps), or by SNMP mgmt application or by CLI. So, you original query was fine. However, this is a tricky item. Where do you stop the line? Wouldnt you wish to further identify which specific application usign the MGMT application set this etc.. I think, it is best to keep this information on the SNMP application side rather than in the MIB. > >> > >> - The same applies to NatAddrPortBindTable. > >> > > Please see the comment above. > > > >> - I wonder why NatAddrBindTable and NatAddrPortBindTable > >> are different tables. A single table should be sufficient > >> for serving both purposes. Most objects are the same in both > >> tables and another object acting as a flag for distinguishing > >> AddrBindings and AddrPortBindings should be sufficient. > > > > Makes sense to me. However, I will let my co-authors comment on this. > >> > >> =========== > >> SMI syntax: > >> =========== > >> > >> There is a missing comma in definition of natConfProtGroup > >> just after object natConfProtConfigName. > >> > >> > > Got it. Thanks. > > > >> ========= > >> Phrasing: > >> ========= > >> > >> In the description of object natAddrBindAddrMapName I would > >> replace "the Management System" by "an SNMP manager". > >> > >> > > > > Will do. > > Sorry about this. I already found that this comment > of mine was nonsense. "management station" is the proper term. > > Juergen > > >> -- > >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > >> > >> > >> -- Melinda Shore wrote on 05 September 2002 18:32 -0400: > >> > >> > They're trying to get draft-ietf-nat-natmib-04.txt wrapped > >> > up for publication, so it would be helpful if comments could > >> > get in pretty quickly. Please try to give the document a > >> > review before next Wednesday, 11 September. > >> > > >> > Thanks, > >> > > >> > Melinda > >> > _______________________________________________ > >> > midcom mailing list > >> > midcom@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/midcom > >> > >> > >> _______________________________________________ > >> midcom mailing list > >> midcom@ietf.org > >> https://www1.ietf.org/mailman/listinfo/midcom > > > > > > ===== > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! News - Today's headlines > > http://news.yahoo.com > > ===== __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 17 06:16:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09327 for ; Tue, 17 Sep 2002 06:16:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HAIE604221 for midcom-archive@odin.ietf.org; Tue, 17 Sep 2002 06:18:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HA5Sv03388; Tue, 17 Sep 2002 06:05:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HA4bv03350 for ; Tue, 17 Sep 2002 06:04:37 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08988 for ; Tue, 17 Sep 2002 06:02:50 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g8HA3uU16133; Tue, 17 Sep 2002 12:03:56 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A393150A78; Tue, 17 Sep 2002 12:03:48 +0200 (CEST) Date: Tue, 17 Sep 2002 12:03:48 +0200 From: Juergen Quittek To: nalpai@cisco.com Cc: Pyda Srisuresh , Melinda Shore , midcom@ietf.org, rohit.rohit@worldwidepackets.com, npai@cisco.com, rrajiv@cisco.com, cwang@smartpipes.com Subject: Re: [midcom] More on the NAT MIB document Message-ID: <4189484.1032264228@[192.168.102.164]> In-Reply-To: <3D86D4A6.F20D7D28@cisco.com> References: <3D86D4A6.F20D7D28@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Nalin, -- Nalin Pai wrote on 17 September 2002 12:37 +0530: > Thanks Juergen, for your comments. > > I think most of the issues you raised have/are been/being addressed > by Suresh, except this one. > >> >> - I wonder why NatAddrBindTable and NatAddrPortBindTable >> >> are different tables. A single table should be sufficient >> >> for serving both purposes. Most objects are the same in both >> >> tables and another object acting as a flag for distinguishing >> >> AddrBindings and AddrPortBindings should be sufficient. >> > > > Yes on first glance, both tables seem to be similar, however if > you notice the indices for the 2 tables are different. > > For natAddrBindTable, they are > INDEX { natAddrBindLocalAddrType, natAddrBindLocalAddr } > > For natAddrPortBindTable, they are > INDEX { natAddrPortBindLocalAddrType, natAddrPortBindLocalAddr, > natAddrPortBindLocalPort, natAddrPortBindProtocol } > > The different indexing schemes makes it difficult (impossible?) > to merge the two tables into one. Thank you for this clarification. Now I understand. > So to summarize the comments (so far) that will be addressed in the > next draft. > > 1) There is a missing comma in definition of natConfProtGroup > just after object natConfProtConfigName. > > 2) However, some more text explaining the MIB might be helpful. > For example, the operational model of the natConfAddrMapTable > is not explained in detail: how to create an entry (and set up > the corresponding binding) using natConfProtRowStatus or > how to configura all required entries for a single TCP > connection. I have a further comment concerning the operational model. I am missing clear statements about the relations between map table, bind tables and session table, such as - Can I create a bind entry without having a corresponding map entry? - What are further entity relationships of entries in these tables? - May I create a session entry with a single bind ID first and later add a second one? If yes, how to do so? And a very minor last comment: In the NAT-TC module you can omit the line ::= { mib-2 xx } -- to be assigned by RFC-editor because you are not defining any object within the module. Then also the import of mib-2 is not needed. Juergen > Thanks once again, > Nalin > > Pyda Srisuresh wrote: >> >> --- Juergen Quittek wrote: >> > Hi Pyda, >> > >> > First of all, I think you did a great job in defining this MIB. >> > It appears to be very mature and to cover all requirements. >> >> Thanks. It has been a team effort. >> > >> > However, some more text explaining the MIB might be helpful. >> > For example, the operational model of the natConfAddrMapTable >> > is not explained in detail: how to create an entry (and set up >> > the corresponding binding) using natConfProtRowStatus or >> > how to configura all required entries for a single TCP >> > connection. >> > >> No problem. >> >> > But things like these can be added in a later version of >> > the MIB document when implementations are available and >> > a progress in standardization status is ahead. >> > >> > Please see some more comments inline. >> > >> > Juergen >> > >> Thanks, Juergen. My responses below. >> >> regards, >> suresh >> >> > -- Pyda Srisuresh wrote on 13 September 2002 20:17 -0700: >> > >> > > Juergen, >> > > >> > > Thanks very much for your detailed comments. >> > > >> > > NAT MIB functioanlity was meant principally for configuring the NAT >> > > devices - Not as a MIDCOM protocol per se. >> > > However, as you noticed, the NAT MIB may be meeting the MIDCOM >> > > protocol requirements for a NAT Middlebox. >> > > >> > > Please see my specific responses below. >> > > >> > > regards, >> > > sures >> > > >> > > --- Juergen Quittek wrote: >> > >> Melinda, >> > >> >> > >> Here are my comments on the NAT MIB: >> > >> >> > >> ========================================== >> > >> General comment (from MIDCOM perspective): >> > >> ========================================== >> > >> >> > >> It appears that if SNMP would be selected as MIDCOM >> > >> protocol, we could completely re-use the NAT MIB and >> > >> just add one or two tables and a few objects for >> > >> having a MIDCOM MIB. However, the functionality of >> > >> the NAT MIB is probably more than MIDCOM requires. >> > >> Missing functionality includes grouping of bindings >> > >> and port oddity requests. >> > >> >> > >> ========================== >> > >> MIB objects and semantics: >> > >> ========================== >> > >> >> > >> - The NatConfAddrMapEntry of the NatConfAddrMapTable is missing >> > >> an object for requesting specific oddity of port numbers >> > >> provided by the NAT. Reference: MIDCOM requirement described >> > >> in section 2.2.9 of RFC 3304. >> > >> >> > > The odditt requirement is covered by the fact that a static port map range >> > > can be defined. Please refer the mapping fields - >> > > (natConfLocalPortFrom, natConfLocalPortTo) --> >> > > (natConfGlobalAddrFrom, natConfGlobalPortto) >> > >> > OK, so if you want fixed port oddity, you have to select the port >> > numbers yourself, and you cannot use dynamic assignment. >> >> Actually, I misstated this in my previouss e-mail. >> Specifying static port maps in the AddressMap Table is a way. But, that >> would be a poor way to do. However, specifying the above through >> NatAddrPortBindEntry would be the right way to do. For example, the >> external agent could add two PortBind entires - one after the other. >> Extending NatAddrPortBindEntry to specify port range (i.e., PortFrom >> and PortTo), instead of a single port would be another way to do this. >> But, I believe, the current approach of making two entries with >> NatAddrPortBindEntry as it stands would be adequate. >> >> > >> > >> - In the NatAddrBindTable a local address, a gloabal address, >> > >> and a direction can be specified. However, the managed object >> > >> natAddrBindDirection has a value of either 'uniDirectional' or >> > >> 'biDirectional'. This does not appear to be sufficient in the >> > >> unidirectional case, because you do not know whether it is >> > >> inbound or outbound. I would suggest to use 'inbound', >> > >> 'outbound', and 'biDirectional' as set of allowed values for >> > >> this object. >> > >> >> > > >> > > BIND itself has to be derived from the address map and the associated >> > > direction specific in the address map. Please refer the description, >> > > which I reproduced below for your convenience. >> > > >> > > "This object represents the direction of the BIND. >> > > A BIND may be either uni-directional or bi-directional, >> > > same as the orientation of the address map, based on >> > > which this bind is formed." >> > >> > I see. But unfortunately, I do not fully understand. >> > Could you comment on possible combinations of {inbound, outbound, both} >> > maps and {uni-dir, bi-dir} bindings? >> >> Well, a BIND may be derived by NAT, based on the sessions noticed in >> the ingress direction, Egress direction or both. ex: You could generate >> a BIND for a bi-directional NAT by looking up the address maps for >> sessions in either direction. Whereas, you would create and reuse the >> BINDS only for outbound sessions with a traditional NAT. Hope this helps. >> >> > >> > >> - The same applies to NatAddrPortBindTable. >> > >> >> > > Please see the explanation above. >> > > >> > >> - A related issue is object natSessionDirection: Why is there >> > >> no support for bi-diractional sessions? >> > >> >> > > >> > > Every session traversing a NAT device has a session direction. It has >> > > to be inbound or outbound - not both, right. >> > >> > So this is the direction of session creation and not necessarily >> > related to the directions of the corresponding map and/or binding? >> >> Yes. >> >> > >> > >> - I would suggest adding another object to the NatAddrBindEntry >> > >> specifying the origin (or creator) of the entry. This can be >> > >> done very general {SNMP, CLI, other protcol} or it can be >> > >> an authenticated (SNMP) user ID. >> > > >> > > What did you mean by the origin - The address map the BIND refers to >> > > (or) the session that triggered this. >> > > If you meant the first, it exists already - natAddrBindAddrMapName. >> > > >> > > As for the second, sessions are fleeting and could have disappeared >> > > even as the BIND remained. So, I dont believe, it wouldnt be right to keep >> > > reference to the session in BIND. >> > >> > Sorry, I referred to the wrong table. I wanted to refer to the >> > natConfAddrMapTable, not to the natAddrBindTable. My point is, that >> > it might be useful to know, whether an entry was created by an SNMP >> > manager, at the CLI, or by a configuraton file, ... >> > >> >> Well, address maps are not changed frequently. Usually, they are set >> just once for the box. BINDs, on the other hand, may be created dynamically, >> either by the NAT (based on address maps), or by SNMP mgmt application >> or by CLI. So, you original query was fine. However, this is a tricky >> item. Where do you stop the line? Wouldnt you wish to further identify which >> specific application usign the MGMT application set this etc.. I think, >> it is best to keep this information on the SNMP application side rather >> than in the MIB. >> >> > >> >> > >> - The same applies to NatAddrPortBindTable. >> > >> >> > > Please see the comment above. >> > > >> > >> - I wonder why NatAddrBindTable and NatAddrPortBindTable >> > >> are different tables. A single table should be sufficient >> > >> for serving both purposes. Most objects are the same in both >> > >> tables and another object acting as a flag for distinguishing >> > >> AddrBindings and AddrPortBindings should be sufficient. >> > > >> > > Makes sense to me. However, I will let my co-authors comment on this. >> > >> >> > >> =========== >> > >> SMI syntax: >> > >> =========== >> > >> >> > >> There is a missing comma in definition of natConfProtGroup >> > >> just after object natConfProtConfigName. >> > >> >> > >> >> > > Got it. Thanks. >> > > >> > >> ========= >> > >> Phrasing: >> > >> ========= >> > >> >> > >> In the description of object natAddrBindAddrMapName I would >> > >> replace "the Management System" by "an SNMP manager". >> > >> >> > >> >> > > >> > > Will do. >> > >> > Sorry about this. I already found that this comment >> > of mine was nonsense. "management station" is the proper term. >> > >> > Juergen >> > >> > >> -- >> > >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> > >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> > >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> > >> >> > >> >> > >> -- Melinda Shore wrote on 05 September 2002 18:32 -0400: >> > >> >> > >> > They're trying to get draft-ietf-nat-natmib-04.txt wrapped >> > >> > up for publication, so it would be helpful if comments could >> > >> > get in pretty quickly. Please try to give the document a >> > >> > review before next Wednesday, 11 September. >> > >> > >> > >> > Thanks, >> > >> > >> > >> > Melinda >> > >> > _______________________________________________ >> > >> > midcom mailing list >> > >> > midcom@ietf.org >> > >> > https://www1.ietf.org/mailman/listinfo/midcom >> > >> >> > >> >> > >> _______________________________________________ >> > >> midcom mailing list >> > >> midcom@ietf.org >> > >> https://www1.ietf.org/mailman/listinfo/midcom >> > > >> > > >> > > ===== >> > > >> > > >> > > __________________________________________________ >> > > Do you Yahoo!? >> > > Yahoo! News - Today's headlines >> > > http://news.yahoo.com >> > >> > >> >> ===== >> >> __________________________________________________ >> Do you Yahoo!? >> Yahoo! News - Today's headlines >> http://news.yahoo.com > > -- > > Nalinaksh Pai > Software Engineer > Cisco Systems > Phone: 91-080-5321300 Ext: 6354 > Email: npai@cisco.com > Epage: nalpai@cbinpage.cisco.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 17 06:18:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09388 for ; Tue, 17 Sep 2002 06:18:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HAJjV04269 for midcom-archive@odin.ietf.org; Tue, 17 Sep 2002 06:19:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HA5Mv03372; Tue, 17 Sep 2002 06:05:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HA4Ov03346 for ; Tue, 17 Sep 2002 06:04:24 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08986 for ; Tue, 17 Sep 2002 06:02:36 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g8HA3dU16115; Tue, 17 Sep 2002 12:03:39 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 43DD450A74; Tue, 17 Sep 2002 12:03:31 +0200 (CEST) Date: Tue, 17 Sep 2002 12:03:30 +0200 From: Juergen Quittek To: Pyda Srisuresh , Melinda Shore , midcom@ietf.org Cc: rohit.rohit@worldwidepackets.com, npai@cisco.com, rrajiv@cisco.com, cwang@smartpipes.com Subject: Re: [midcom] More on the NAT MIB document Message-ID: <4171628.1032264210@[192.168.102.164]> In-Reply-To: <20020917063122.78436.qmail@web40403.mail.yahoo.com> References: <20020917063122.78436.qmail@web40403.mail.yahoo.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Pyda, -- Pyda Srisuresh wrote on 16 September 2002 23:31 -0700: > > --- Juergen Quittek wrote: >> Hi Pyda, >> >> First of all, I think you did a great job in defining this MIB. >> It appears to be very mature and to cover all requirements. > > Thanks. It has been a team effort. Yes, of course. I intended to address all of you. >> However, some more text explaining the MIB might be helpful. >> For example, the operational model of the natConfAddrMapTable >> is not explained in detail: how to create an entry (and set up >> the corresponding binding) using natConfProtRowStatus or >> how to configura all required entries for a single TCP >> connection. >> > No problem. > >> But things like these can be added in a later version of >> the MIB document when implementations are available and >> a progress in standardization status is ahead. >> >> Please see some more comments inline. >> >> Juergen >> > Thanks, Juergen. My responses below. > > regards, > suresh > >> -- Pyda Srisuresh wrote on 13 September 2002 20:17 -0700: >> >> > Juergen, >> > >> > Thanks very much for your detailed comments. >> > >> > NAT MIB functioanlity was meant principally for configuring the NAT >> > devices - Not as a MIDCOM protocol per se. >> > However, as you noticed, the NAT MIB may be meeting the MIDCOM >> > protocol requirements for a NAT Middlebox. >> > >> > Please see my specific responses below. >> > >> > regards, >> > sures >> > >> > --- Juergen Quittek wrote: >> >> Melinda, >> >> >> >> Here are my comments on the NAT MIB: >> >> >> >> ========================================== >> >> General comment (from MIDCOM perspective): >> >> ========================================== >> >> >> >> It appears that if SNMP would be selected as MIDCOM >> >> protocol, we could completely re-use the NAT MIB and >> >> just add one or two tables and a few objects for >> >> having a MIDCOM MIB. However, the functionality of >> >> the NAT MIB is probably more than MIDCOM requires. >> >> Missing functionality includes grouping of bindings >> >> and port oddity requests. >> >> >> >> ========================== >> >> MIB objects and semantics: >> >> ========================== >> >> >> >> - The NatConfAddrMapEntry of the NatConfAddrMapTable is missing >> >> an object for requesting specific oddity of port numbers >> >> provided by the NAT. Reference: MIDCOM requirement described >> >> in section 2.2.9 of RFC 3304. >> >> >> > The odditt requirement is covered by the fact that a static port map range >> > can be defined. Please refer the mapping fields - >> > (natConfLocalPortFrom, natConfLocalPortTo) --> >> > (natConfGlobalAddrFrom, natConfGlobalPortto) >> >> OK, so if you want fixed port oddity, you have to select the port >> numbers yourself, and you cannot use dynamic assignment. > > Actually, I misstated this in my previouss e-mail. > Specifying static port maps in the AddressMap Table is a way. But, that > would be a poor way to do. However, specifying the above throu gh > NatAddrPortBindEntry would be the right way to do. For example, the > external agent could add two PortBind entires - one after the other. > Extending NatAddrPortBindEntry to specify port range (i.e., PortFrom > and PortTo), instead of a single port would be another way to do this. Now I understand. > But, I believe, the current approach of making two entries with > NatAddrPortBindEntry as it stands would be adequate. Agreed. >> >> >> - In the NatAddrBindTable a local address, a gloabal address, >> >> and a direction can be specified. However, the managed object >> >> natAddrBindDirection has a value of either 'uniDirectional' or >> >> 'biDirectional'. This does not appear to be sufficient in the >> >> unidirectional case, because you do not know whether it is >> >> inbound or outbound. I would suggest to use 'inbound', >> >> 'outbound', and 'biDirectional' as set of allowed values for >> >> this object. >> >> >> > >> > BIND itself has to be derived from the address map and the associated >> > direction specific in the address map. Please refer the description, >> > which I reproduced below for your convenience. >> > >> > "This object represents the direction of the BIND. >> > A BIND may be either uni-directional or bi-directional, >> > same as the orientation of the address map, based on >> > which this bind is formed." >> >> I see. But unfortunately, I do not fully understand. >> Could you comment on possible combinations of {inbound, outbound, both} >> maps and {uni-dir, bi-dir} bindings? > > Well, a BIND may be derived by NAT, based on the sessions noticed in > the ingress direction, Egress direction or both. ex: You could generate > a BIND for a bi-directional NAT by looking up the address maps for > sessions in either direction. Whereas, you would create and reuse the > BINDS only for outbound sessions with a traditional NAT. Hope this helps. Yes, it helps. I think I was lacking clear statements about the relations between map table, bind tables and session table. >> >> >> - The same applies to NatAddrPortBindTable. >> >> >> > Please see the explanation above. >> > >> >> - A related issue is object natSessionDirection: Why is there >> >> no support for bi-diractional sessions? >> >> >> > >> > Every session traversing a NAT device has a session direction. It has >> > to be inbound or outbound - not both, right. >> >> So this is the direction of session creation and not necessarily >> related to the directions of the corresponding map and/or binding? > > Yes. > >> >> >> - I would suggest adding another object to the NatAddrBindEntry >> >> specifying the origin (or creator) of the entry. This can be >> >> done very general {SNMP, CLI, other protcol} or it can be >> >> an authenticated (SNMP) user ID. >> > >> > What did you mean by the origin - The address map the BIND refers to >> > (or) the session that triggered this. >> > If you meant the first, it exists already - natAddrBindAddrMapName. >> > >> > As for the second, sessions are fleeting and could have disappeared >> > even as the BIND remained. So, I dont believe, it wouldnt be right to keep >> > reference to the session in BIND. >> >> Sorry, I referred to the wrong table. I wanted to refer to the >> natConfAddrMapTable, not to the natAddrBindTable. My point is, that >> it might be useful to know, whether an entry was created by an SNMP >> manager, at the CLI, or by a configuraton file, ... >> > > Well, address maps are not changed frequently. Usually, they are set > just once for the box. BINDs, on the other hand, may be created dynamically, > either by the NAT (based on address maps), or by SNMP mgmt application > or by CLI. So, you original query was fine. However, this is a tricky > item. Where do you stop the line? Wouldnt you wish to further identify which > specific application usign the MGMT application set this etc.. I think, > it is best to keep this information on the SNMP application side rather > than in the MIB. I agree that there is no strong requirement in doing so. However, for both tables a management might like to know about the origin of an entry, particularly whether it was created by the station itself or whether someone else did so, for example at the command line, or via another NAT configuration protocol. Furthermore, since SNMPv1 and v2c are on their way to become "historic" you can assume having a notion of an (authenticated?) user in SNMPv3 agents. Juergen >> >> >> >> - The same applies to NatAddrPortBindTable. >> >> >> > Please see the comment above. >> > >> >> - I wonder why NatAddrBindTable and NatAddrPortBindTable >> >> are different tables. A single table should be sufficient >> >> for serving both purposes. Most objects are the same in both >> >> tables and another object acting as a flag for distinguishing >> >> AddrBindings and AddrPortBindings should be sufficient. >> > >> > Makes sense to me. However, I will let my co-authors comment on this. >> >> >> >> =========== >> >> SMI syntax: >> >> =========== >> >> >> >> There is a missing comma in definition of natConfProtGroup >> >> just after object natConfProtConfigName. >> >> >> >> >> > Got it. Thanks. >> > >> >> ========= >> >> Phrasing: >> >> ========= >> >> >> >> In the description of object natAddrBindAddrMapName I would >> >> replace "the Management System" by "an SNMP manager". >> >> >> >> >> > >> > Will do. >> >> Sorry about this. I already found that this comment >> of mine was nonsense. "management station" is the proper term. >> >> Juergen >> >> >> -- >> >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> >> >> >> >> >> -- Melinda Shore wrote on 05 September 2002 18:32 -0400: >> >> >> >> > They're trying to get draft-ietf-nat-natmib-04.txt wrapped >> >> > up for publication, so it would be helpful if comments could >> >> > get in pretty quickly. Please try to give the document a >> >> > review before next Wednesday, 11 September. >> >> > >> >> > Thanks, >> >> > >> >> > Melinda >> >> > _______________________________________________ >> >> > midcom mailing list >> >> > midcom@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> >> >> _______________________________________________ >> >> midcom mailing list >> >> midcom@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/midcom >> > >> > >> > ===== >> > >> > >> > __________________________________________________ >> > Do you Yahoo!? >> > Yahoo! News - Today's headlines >> > http://news.yahoo.com >> >> > > > ===== > > > __________________________________________________ > Do you Yahoo!? > Yahoo! News - Today's headlines > http://news.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 17 08:21:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11943 for ; Tue, 17 Sep 2002 08:21:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HCMcm10344 for midcom-archive@odin.ietf.org; Tue, 17 Sep 2002 08:22:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HCA9v09915; Tue, 17 Sep 2002 08:10:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HBakv07571 for ; Tue, 17 Sep 2002 07:36:46 -0400 Received: from india-msg-core-1.cisco.com (india-msg-core-1.cisco.com [64.104.129.221]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10630 for ; Tue, 17 Sep 2002 07:34:58 -0400 (EDT) Received: from cbin2-mira-01.cisco.com (localhost [127.0.0.1]) by india-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8HH4bEb014580; Tue, 17 Sep 2002 17:04:37 GMT Received: from cisco.com ([64.104.147.100]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AQD01977 (AUTH nalpai); Tue, 17 Sep 2002 17:02:35 +0530 (IST) Message-ID: <3D871380.51456455@cisco.com> Date: Tue, 17 Sep 2002 17:05:28 +0530 From: Nalin Pai Reply-To: nalpai@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Pyda Srisuresh , Melinda Shore , midcom@ietf.org, rohit.rohit@worldwidepackets.com, npai@cisco.com, rrajiv@cisco.com, cwang@smartpipes.com Subject: Re: [midcom] More on the NAT MIB document References: <3D86D4A6.F20D7D28@cisco.com> <4189484.1032264228@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Juergen, Juergen Quittek wrote: > > Hi Nalin, > > -- Nalin Pai wrote on 17 September 2002 12:37 +0530: > > > Thanks Juergen, for your comments. > > > > I think most of the issues you raised have/are been/being addressed > > by Suresh, except this one. > > > >> >> - I wonder why NatAddrBindTable and NatAddrPortBindTable > >> >> are different tables. A single table should be sufficient > >> >> for serving both purposes. Most objects are the same in both > >> >> tables and another object acting as a flag for distinguishing > >> >> AddrBindings and AddrPortBindings should be sufficient. > >> > > > > > Yes on first glance, both tables seem to be similar, however if > > you notice the indices for the 2 tables are different. > > > > For natAddrBindTable, they are > > INDEX { natAddrBindLocalAddrType, natAddrBindLocalAddr } > > > > For natAddrPortBindTable, they are > > INDEX { natAddrPortBindLocalAddrType, natAddrPortBindLocalAddr, > > natAddrPortBindLocalPort, natAddrPortBindProtocol } > > > > The different indexing schemes makes it difficult (impossible?) > > to merge the two tables into one. > > Thank you for this clarification. Now I understand. > > > So to summarize the comments (so far) that will be addressed in the > > next draft. > > > > 1) There is a missing comma in definition of natConfProtGroup > > just after object natConfProtConfigName. > > > > 2) However, some more text explaining the MIB might be helpful. > > For example, the operational model of the natConfAddrMapTable > > is not explained in detail: how to create an entry (and set up > > the corresponding binding) using natConfProtRowStatus or > > how to configura all required entries for a single TCP > > connection. > > I have a further comment concerning the operational model. > I am missing clear statements about the relations > between map table, bind tables and session table, such as > - Can I create a bind entry without having a corresponding map entry? > - What are further entity relationships of entries in these tables? > - May I create a session entry with a single bind ID first and later > add a second one? If yes, how to do so? > OK, we will clarify such relations in the MIB. > And a very minor last comment: > In the NAT-TC module you can omit the line > ::= { mib-2 xx } -- to be assigned by RFC-editor > because you are not defining any object within the module. > Then also the import of mib-2 is not needed. > Will look into this. Thanks, Nalin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 17 08:21:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11965 for ; Tue, 17 Sep 2002 08:21:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HCNBW10375 for midcom-archive@odin.ietf.org; Tue, 17 Sep 2002 08:23:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HCA6v09900; Tue, 17 Sep 2002 08:10:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8H78Iv26942 for ; Tue, 17 Sep 2002 03:08:18 -0400 Received: from india-msg-core-1.cisco.com (india-msg-core-1.cisco.com [64.104.129.221]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06255 for ; Tue, 17 Sep 2002 03:06:20 -0400 (EDT) Received: from cbin2-mira-01.cisco.com (localhost [127.0.0.1]) by india-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8HCaLld004190; Tue, 17 Sep 2002 12:36:22 GMT Received: from cisco.com ([64.104.147.100]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AQC07915 (AUTH nalpai); Tue, 17 Sep 2002 12:34:25 +0530 (IST) Message-ID: <3D86D4A6.F20D7D28@cisco.com> Date: Tue, 17 Sep 2002 12:37:18 +0530 From: Nalin Pai Reply-To: nalpai@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Pyda Srisuresh , Melinda Shore , midcom@ietf.org, rohit.rohit@worldwidepackets.com, npai@cisco.com, rrajiv@cisco.com, cwang@smartpipes.com Subject: Re: [midcom] More on the NAT MIB document References: <20020917063122.78436.qmail@web40403.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks Juergen, for your comments. I think most of the issues you raised have/are been/being addressed by Suresh, except this one. > >> - I wonder why NatAddrBindTable and NatAddrPortBindTable > >> are different tables. A single table should be sufficient > >> for serving both purposes. Most objects are the same in both > >> tables and another object acting as a flag for distinguishing > >> AddrBindings and AddrPortBindings should be sufficient. > > Yes on first glance, both tables seem to be similar, however if you notice the indices for the 2 tables are different. For natAddrBindTable, they are INDEX { natAddrBindLocalAddrType, natAddrBindLocalAddr } For natAddrPortBindTable, they are INDEX { natAddrPortBindLocalAddrType, natAddrPortBindLocalAddr, natAddrPortBindLocalPort, natAddrPortBindProtocol } The different indexing schemes makes it difficult (impossible?) to merge the two tables into one. So to summarize the comments (so far) that will be addressed in the next draft. 1) There is a missing comma in definition of natConfProtGroup just after object natConfProtConfigName. 2) However, some more text explaining the MIB might be helpful. For example, the operational model of the natConfAddrMapTable is not explained in detail: how to create an entry (and set up the corresponding binding) using natConfProtRowStatus or how to configura all required entries for a single TCP connection. Thanks once again, Nalin Pyda Srisuresh wrote: > > --- Juergen Quittek wrote: > > Hi Pyda, > > > > First of all, I think you did a great job in defining this MIB. > > It appears to be very mature and to cover all requirements. > > Thanks. It has been a team effort. > > > > However, some more text explaining the MIB might be helpful. > > For example, the operational model of the natConfAddrMapTable > > is not explained in detail: how to create an entry (and set up > > the corresponding binding) using natConfProtRowStatus or > > how to configura all required entries for a single TCP > > connection. > > > No problem. > > > But things like these can be added in a later version of > > the MIB document when implementations are available and > > a progress in standardization status is ahead. > > > > Please see some more comments inline. > > > > Juergen > > > Thanks, Juergen. My responses below. > > regards, > suresh > > > -- Pyda Srisuresh wrote on 13 September 2002 20:17 -0700: > > > > > Juergen, > > > > > > Thanks very much for your detailed comments. > > > > > > NAT MIB functioanlity was meant principally for configuring the NAT > > > devices - Not as a MIDCOM protocol per se. > > > However, as you noticed, the NAT MIB may be meeting the MIDCOM > > > protocol requirements for a NAT Middlebox. > > > > > > Please see my specific responses below. > > > > > > regards, > > > sures > > > > > > --- Juergen Quittek wrote: > > >> Melinda, > > >> > > >> Here are my comments on the NAT MIB: > > >> > > >> ========================================== > > >> General comment (from MIDCOM perspective): > > >> ========================================== > > >> > > >> It appears that if SNMP would be selected as MIDCOM > > >> protocol, we could completely re-use the NAT MIB and > > >> just add one or two tables and a few objects for > > >> having a MIDCOM MIB. However, the functionality of > > >> the NAT MIB is probably more than MIDCOM requires. > > >> Missing functionality includes grouping of bindings > > >> and port oddity requests. > > >> > > >> ========================== > > >> MIB objects and semantics: > > >> ========================== > > >> > > >> - The NatConfAddrMapEntry of the NatConfAddrMapTable is missing > > >> an object for requesting specific oddity of port numbers > > >> provided by the NAT. Reference: MIDCOM requirement described > > >> in section 2.2.9 of RFC 3304. > > >> > > > The odditt requirement is covered by the fact that a static port map range > > > can be defined. Please refer the mapping fields - > > > (natConfLocalPortFrom, natConfLocalPortTo) --> > > > (natConfGlobalAddrFrom, natConfGlobalPortto) > > > > OK, so if you want fixed port oddity, you have to select the port > > numbers yourself, and you cannot use dynamic assignment. > > Actually, I misstated this in my previouss e-mail. > Specifying static port maps in the AddressMap Table is a way. But, that > would be a poor way to do. However, specifying the above through > NatAddrPortBindEntry would be the right way to do. For example, the > external agent could add two PortBind entires - one after the other. > Extending NatAddrPortBindEntry to specify port range (i.e., PortFrom > and PortTo), instead of a single port would be another way to do this. > But, I believe, the current approach of making two entries with > NatAddrPortBindEntry as it stands would be adequate. > > > > > >> - In the NatAddrBindTable a local address, a gloabal address, > > >> and a direction can be specified. However, the managed object > > >> natAddrBindDirection has a value of either 'uniDirectional' or > > >> 'biDirectional'. This does not appear to be sufficient in the > > >> unidirectional case, because you do not know whether it is > > >> inbound or outbound. I would suggest to use 'inbound', > > >> 'outbound', and 'biDirectional' as set of allowed values for > > >> this object. > > >> > > > > > > BIND itself has to be derived from the address map and the associated > > > direction specific in the address map. Please refer the description, > > > which I reproduced below for your convenience. > > > > > > "This object represents the direction of the BIND. > > > A BIND may be either uni-directional or bi-directional, > > > same as the orientation of the address map, based on > > > which this bind is formed." > > > > I see. But unfortunately, I do not fully understand. > > Could you comment on possible combinations of {inbound, outbound, both} > > maps and {uni-dir, bi-dir} bindings? > > Well, a BIND may be derived by NAT, based on the sessions noticed in > the ingress direction, Egress direction or both. ex: You could generate > a BIND for a bi-directional NAT by looking up the address maps for > sessions in either direction. Whereas, you would create and reuse the > BINDS only for outbound sessions with a traditional NAT. Hope this helps. > > > > > >> - The same applies to NatAddrPortBindTable. > > >> > > > Please see the explanation above. > > > > > >> - A related issue is object natSessionDirection: Why is there > > >> no support for bi-diractional sessions? > > >> > > > > > > Every session traversing a NAT device has a session direction. It has > > > to be inbound or outbound - not both, right. > > > > So this is the direction of session creation and not necessarily > > related to the directions of the corresponding map and/or binding? > > Yes. > > > > > >> - I would suggest adding another object to the NatAddrBindEntry > > >> specifying the origin (or creator) of the entry. This can be > > >> done very general {SNMP, CLI, other protcol} or it can be > > >> an authenticated (SNMP) user ID. > > > > > > What did you mean by the origin - The address map the BIND refers to > > > (or) the session that triggered this. > > > If you meant the first, it exists already - natAddrBindAddrMapName. > > > > > > As for the second, sessions are fleeting and could have disappeared > > > even as the BIND remained. So, I dont believe, it wouldnt be right to keep > > > reference to the session in BIND. > > > > Sorry, I referred to the wrong table. I wanted to refer to the > > natConfAddrMapTable, not to the natAddrBindTable. My point is, that > > it might be useful to know, whether an entry was created by an SNMP > > manager, at the CLI, or by a configuraton file, ... > > > > Well, address maps are not changed frequently. Usually, they are set > just once for the box. BINDs, on the other hand, may be created dynamically, > either by the NAT (based on address maps), or by SNMP mgmt application > or by CLI. So, you original query was fine. However, this is a tricky > item. Where do you stop the line? Wouldnt you wish to further identify which > specific application usign the MGMT application set this etc.. I think, > it is best to keep this information on the SNMP application side rather > than in the MIB. > > > >> > > >> - The same applies to NatAddrPortBindTable. > > >> > > > Please see the comment above. > > > > > >> - I wonder why NatAddrBindTable and NatAddrPortBindTable > > >> are different tables. A single table should be sufficient > > >> for serving both purposes. Most objects are the same in both > > >> tables and another object acting as a flag for distinguishing > > >> AddrBindings and AddrPortBindings should be sufficient. > > > > > > Makes sense to me. However, I will let my co-authors comment on this. > > >> > > >> =========== > > >> SMI syntax: > > >> =========== > > >> > > >> There is a missing comma in definition of natConfProtGroup > > >> just after object natConfProtConfigName. > > >> > > >> > > > Got it. Thanks. > > > > > >> ========= > > >> Phrasing: > > >> ========= > > >> > > >> In the description of object natAddrBindAddrMapName I would > > >> replace "the Management System" by "an SNMP manager". > > >> > > >> > > > > > > Will do. > > > > Sorry about this. I already found that this comment > > of mine was nonsense. "management station" is the proper term. > > > > Juergen > > > > >> -- > > >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > > >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > >> > > >> > > >> -- Melinda Shore wrote on 05 September 2002 18:32 -0400: > > >> > > >> > They're trying to get draft-ietf-nat-natmib-04.txt wrapped > > >> > up for publication, so it would be helpful if comments could > > >> > get in pretty quickly. Please try to give the document a > > >> > review before next Wednesday, 11 September. > > >> > > > >> > Thanks, > > >> > > > >> > Melinda > > >> > _______________________________________________ > > >> > midcom mailing list > > >> > midcom@ietf.org > > >> > https://www1.ietf.org/mailman/listinfo/midcom > > >> > > >> > > >> _______________________________________________ > > >> midcom mailing list > > >> midcom@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/midcom > > > > > > > > > ===== > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! News - Today's headlines > > > http://news.yahoo.com > > > > > > ===== > > __________________________________________________ > Do you Yahoo!? > Yahoo! News - Today's headlines > http://news.yahoo.com -- Nalinaksh Pai Software Engineer Cisco Systems Phone: 91-080-5321300 Ext: 6354 Email: npai@cisco.com Epage: nalpai@cbinpage.cisco.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Sep 18 08:19:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09919 for ; Wed, 18 Sep 2002 08:19:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8ICL4A30295 for midcom-archive@odin.ietf.org; Wed, 18 Sep 2002 08:21:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8ICJ0v30154; Wed, 18 Sep 2002 08:19:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8I5ADv32236 for ; Wed, 18 Sep 2002 01:10:13 -0400 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09232 for ; Wed, 18 Sep 2002 01:08:16 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id WAA03621 for ; Tue, 17 Sep 2002 22:10:02 -0700 (MST)] Received: [from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id WAA22796 for ; Tue, 17 Sep 2002 22:07:20 -0700 (MST)] Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 18 Sep 2002 10:39:08 +0530 Message-ID: <653138C25D8AD6118292000347080A37A0D405@zin05exm02.corp.mot.com> From: Aradhya Rohit V-A15094 Cc: midcom@ietf.org Date: Wed, 18 Sep 2002 10:38:59 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25ED1.7F789560" Subject: [midcom] Few Q's on Requirements of MIDCOM Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This 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_01C25ED1.7F789560 Content-Type: text/plain; charset="iso-8859-1" Hi, 'am new to this mailing list, i have few questions regarding RFC 3304 " Middlebox Communications (midcom) Protocol Requirements" any pointers or directions are highly appreciated. 1.What are the charcterstics of association between midcom agent and middlebox?? Is the association defined here are specific to a particular service, if a midcom agent wants to have two types of services, then does he has to have two associations?.. Is a lifetime associated with association. 2.Is midcom agent is the final authority in determining the traffic behaviour at middlebox, is there a possibility that middlebox may decide to override any of the expected behavior by midcom agent at later point of stage after associations are established, if middlebox does so does that means it is a end of association?? Or its permissiable for middlebox to alter the characterstics of associations (with notification to midcom agent ofcourse..), but the association is not renegotiatated. 3.Is there any threat perception analysis done for this protocol?.. any pointers are really appreciated.. Is security needed??.. 4. Is there a restriction that the machines lying on immediately attached network to middlebox can only become midcom agents? May be its good to have a concept of REALMs, which are valid and should be allowed to be midcom agents, any machine lying outside this realm should not be allowed to be a midcom agent. 5.Why there is a need for mutual authentication??.. isn't it a overhead, whats the gain from it.. ya.. I understand there will be attacks on middlebox agents like session hijaking, dos etc, but I guess it will be pretty visible to end user or midcom agents immediately.. -Regards Rohit ------_=_NextPart_001_01C25ED1.7F789560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] MIDCOM SEmantics: Policy Rule Content
Hi,
     =20 'am new to this mailing list, i have few questions regarding  RFC = 3304 "=20 Middlebox=20 Communications (midcom) Protocol Requirements" any pointers or = directions=20 are highly appreciated.
 
 
1.What=20 are the charcterstics of association between midcom agent and = middlebox??=20 Is=20 the association defined here are specific to a particular service, if a = midcom=20 agent wants to have two types of services, then does he has to have two = associations?.. Is a lifetime associated with=20 association.
2.Is=20 midcom agent is the final authority in determining the traffic = behaviour at=20 middlebox,  is there a = possibility=20 that middlebox may decide to override any of the expected behavior by = midcom=20 agent at later point of stage after associations are established, if = middlebox=20 does so does that means it is a end of association?? Or its = permissiable for=20 middlebox to alter the characterstics of =20 associations (with notification to midcom agent ofcourse..), but = the=20 association is not=20 renegotiatated.
3.Is=20 there any threat perception analysis done for this protocol?.. any = pointers are=20 really appreciated.. Is security needed??..=20
4. Is there a restriction that the machines lying on = immediately attached=20 network to middlebox can only become midcom agents? May=20 be its good to have a concept of REALMs, which are valid and should be = allowed=20 to be midcom agents, any machine lying outside this realm should not be = allowed=20 to be a midcom=20 agent.
5.Why=20 there is a need for mutual authentication??.. isn't it a overhead, = whats the=20 gain from it.. ya.. I understand there will be attacks on middlebox = agents like=20 session hijaking, dos etc, but I guess it will be pretty visible to end = user or=20 midcom agents immediately..=20
 
 
-Regards<= /FONT>
 =20 Rohit
------_=_NextPart_001_01C25ED1.7F789560-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Sep 19 07:52:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00870 for ; Thu, 19 Sep 2002 07:52:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8JBrZV01591 for midcom-archive@odin.ietf.org; Thu, 19 Sep 2002 07:53:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8JBnEv01287; Thu, 19 Sep 2002 07:49:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8JBmWv01239 for ; Thu, 19 Sep 2002 07:48:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00494; Thu, 19 Sep 2002 07:46:41 -0400 (EDT) Message-Id: <200209191146.HAA00494@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, 19 Sep 2002 07:46:41 -0400 Subject: [midcom] I-D ACTION:draft-taylor-midcom-semgen-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : General Considerations For MIDCOM Semantics Author(s) : T. Taylor Filename : draft-taylor-midcom-semgen-00.txt Pages : 17 Date : 2002-9-18 This document is written to aid the process of selecting and completing the definition of the MIDCOM protocol, which will operate between MIDCOM agents and middleboxes such as firewalls and NATs. It describes the semantics which the protocol must support. These semantics are derived from the MIDCOM requirements and the MIDCOM usage scenarios which helped to inspire the requirements. This document was derived from draft-taylor-midcom-semantics-00.txt. The present version incorporates tentative conclusions reached in discussion at the IETF 54 meeting of the MIDCOM WG. It removes the concrete expression of the MIDCOM requests, responses, and notifications in favour of those presented in draft-stiemerling- midcom-semantics-xx.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-taylor-midcom-semgen-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-taylor-midcom-semgen-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-taylor-midcom-semgen-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-18151154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-taylor-midcom-semgen-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-taylor-midcom-semgen-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-18151154.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 24 10:14:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28715 for ; Tue, 24 Sep 2002 10:14:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8OEFut03138 for midcom-archive@odin.ietf.org; Tue, 24 Sep 2002 10:15:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OECiv02992; Tue, 24 Sep 2002 10:12:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OEBev02937 for ; Tue, 24 Sep 2002 10:11:40 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28568 for ; Tue, 24 Sep 2002 10:09:46 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8OEAwa23065; Tue, 24 Sep 2002 10:10:58 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Sep 2002 10:11:01 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A925@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: midcom@ietf.org Cc: "'Juergen Quittek'" , "'Martin Stiemerling'" Date: Tue, 24 Sep 2002 10:10:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C263D4.343DF54C" Subject: [midcom] Comments on draft-stiemerling-midcom-semantics-02.txt: Session/Pe er Identification Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This 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_01C263D4.343DF54C Content-Type: text/plain This is a series of notes on the content of draft-stiemerling-midcom-semantics-01.txt. This note discusses the need for content in each message which identifies the sender and possibly the session with which the message is associated. I'll deal with the session identifier first. The first paragraph of section 2.2 of the draft says that: "Both agent and middlebox may participate in several sessions at the same time." As I argue in draft-taylor-midcom-semgen-00.txt, this means at the very least that every message must identify the sender, so that the receiver can associate it with the right session. Thus every request from the agent must contain the agent identifier, and every response and notification from the middlebox must contain the middlebox identifier, as one of its parameters. Does this identification have to go so far as to require an authentication token in every message? Aside from this general question, I believe it would make sense for the middlebox to authenticate itself in a Session Establishment reply in the failure case as well as in the success case, to forestall a man-in-the-middle DOS attack based on spurious rejection. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C263D4.343DF54C Content-Type: text/html Content-Transfer-Encoding: quoted-printable Comments on draft-stiemerling-midcom-semantics-02.txt: = Session/Peer Identification

This is a series of notes on the content of = draft-stiemerling-midcom-semantics-01.txt.  This note discusses = the need for content in each message which identifies the sender and = possibly the session with which the message is associated.

I'll deal with the session identifier first.  = The first paragraph of section 2.2 of the draft says that:
 "Both agent and middlebox may participate = in several sessions at the same time."

As I argue in draft-taylor-midcom-semgen-00.txt, this = means at the very least that every message must identify the sender, so = that the receiver can associate it with the right session.  Thus = every request from the agent must contain the agent identifier, and = every response and notification from the middlebox must contain the = middlebox identifier, as one of its parameters.

Does this identification have to go so far as to = require an authentication token in every message?

Aside from this general question, I believe it would = make sense for the middlebox to authenticate itself in a Session = Establishment reply in the failure case as well as in the success case, = to forestall a man-in-the-middle DOS attack based on spurious = rejection.

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

------_=_NextPart_001_01C263D4.343DF54C-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 24 10:55:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00657 for ; Tue, 24 Sep 2002 10:55:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8OEv9G05822 for midcom-archive@odin.ietf.org; Tue, 24 Sep 2002 10:57:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OEtpv05732; Tue, 24 Sep 2002 10:55:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OEsbv05678 for ; Tue, 24 Sep 2002 10:54:37 -0400 Received: from mx2.etsi.org (mx2.etsi.fr [212.234.161.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00538 for ; Tue, 24 Sep 2002 10:52:43 -0400 (EDT) Received: from email10.etsihq.org ([172.27.1.62]) by mx2.etsi.org with Microsoft SMTPSVC(5.0.2195.4905); Tue, 24 Sep 2002 16:46:08 +0200 X-Mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C263D9.1DB6EA90" Subject: RE: [midcom] Comments on draft-stiemerling-midcom-semantics-02.txt: Session/Peer Identification Date: Tue, 24 Sep 2002 16:46:07 +0200 Message-ID: <4091553999CBE4409CC2B562152B5A3340CA4C@email10.etsihq.org> Thread-Topic: [midcom] Comments on draft-stiemerling-midcom-semantics-02.txt: Session/Peer Identification Thread-Index: AcJj1W0L8JNjNhvCS4SPiq9kK1uExgAAKMGw From: "Scott Cadzow" To: "Tom-PT Taylor" , Cc: "Juergen Quittek" , "Martin Stiemerling" X-OriginalArrivalTime: 24 Sep 2002 14:46:08.0173 (UTC) FILETIME=[1DF95DD0:01C263D9] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C263D9.1DB6EA90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Whilst authentication as a goal is good it is the impact of that authentication we need to worry about. What entity is authenticated and against what knowledge? If every transaction is authenticated and a middlebox randomly serves many users then authentication state maintenance cannot be guaranteed. Key management (symmetric or asymmetric) then becomes the dominant problem over and above the other functions of the middlebox. =20 Tread warily. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: 24 September 2002 16:11 To: midcom@ietf.org Cc: 'Juergen Quittek'; 'Martin Stiemerling' Subject: [midcom] Comments on draft-stiemerling-midcom-semantics-02.txt: Session/Peer Identification This is a series of notes on the content of draft-stiemerling-midcom-semantics-01.txt. This note discusses the need for content in each message which identifies the sender and possibly the session with which the message is associated. I'll deal with the session identifier first. The first paragraph of section 2.2 of the draft says that:=20 "Both agent and middlebox may participate in several sessions at the same time."=20 As I argue in draft-taylor-midcom-semgen-00.txt, this means at the very least that every message must identify the sender, so that the receiver can associate it with the right session. Thus every request from the agent must contain the agent identifier, and every response and notification from the middlebox must contain the middlebox identifier, as one of its parameters. Does this identification have to go so far as to require an authentication token in every message?=20 Aside from this general question, I believe it would make sense for the middlebox to authenticate itself in a Session Establishment reply in the failure case as well as in the success case, to forestall a man-in-the-middle DOS attack based on spurious rejection. Tom Taylor=20 taylor@nortelnetworks.com=20 Ph. +1 613 736 0961 (ESN 396 1490)=20 =20 ------_=_NextPart_001_01C263D9.1DB6EA90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-stiemerling-midcom-semantics-02.txt: = Session/Peer Identification
Whilst=20 authentication as a goal is good it is the impact of that authentication = we need=20 to worry about. What entity is authenticated and against what knowledge? = If=20 every transaction is authenticated and a middlebox randomly serves many = users=20 then authentication state maintenance cannot be guaranteed. Key = management=20 (symmetric or asymmetric) then becomes the dominant problem over and = above the=20 other functions of the middlebox.
 
Tread=20 warily.
-----Original Message-----
From: Tom-PT Taylor=20 [mailto:taylor@nortelnetworks.com]
Sent: 24 September 2002=20 16:11
To: midcom@ietf.org
Cc: 'Juergen Quittek'; = 'Martin=20 Stiemerling'
Subject: [midcom] Comments on=20 draft-stiemerling-midcom-semantics-02.txt: Session/Peer=20 Identification

This is a series of notes on the content of=20 draft-stiemerling-midcom-semantics-01.txt.  This note discusses = the need=20 for content in each message which identifies the sender and possibly = the=20 session with which the message is associated.

I'll deal with the session identifier first.  = The first=20 paragraph of section 2.2 of the draft says that:
 "Both agent and middlebox may participate in several = sessions at=20 the same time."

As I argue in draft-taylor-midcom-semgen-00.txt, = this means at=20 the very least that every message must identify the sender, so that = the=20 receiver can associate it with the right session.  Thus every = request=20 from the agent must contain the agent identifier, and every response = and=20 notification from the middlebox must contain the middlebox identifier, = as one=20 of its parameters.

Does this identification have to go so far as to = require an=20 authentication token in every message?

Aside from this general question, I believe it would = make=20 sense for the middlebox to authenticate itself in a Session = Establishment=20 reply in the failure case as well as in the success case, to forestall = a=20 man-in-the-middle DOS attack based on spurious rejection.

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

------_=_NextPart_001_01C263D9.1DB6EA90-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Sep 24 11:17:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01934 for ; Tue, 24 Sep 2002 11:17:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8OFJ2Q07664 for midcom-archive@odin.ietf.org; Tue, 24 Sep 2002 11:19:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OFI5v07609; Tue, 24 Sep 2002 11:18:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OFHdv07537 for ; Tue, 24 Sep 2002 11:17:39 -0400 Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01778 for ; Tue, 24 Sep 2002 11:15:45 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8OFGto11117; Tue, 24 Sep 2002 11:16:55 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Sep 2002 11:17:00 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A929@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: midcom@ietf.org Cc: "'Juergen Quittek'" , "'Martin Stiemerling'" Date: Tue, 24 Sep 2002 11:16:57 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Comments on draft-stiemerling-midcom-semantics-02.txt: Role of Gr oups Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is the second note on draft-stiemerling-midcom-semantics-02.txt. This note discusses the role of policy groups (AKA session bundles). The draft makes this statement about groups (sec. 2.3 third para): "Group transactions are redundant in the sense that a transaction on a group can be replaced by the corresponding transaction on each member of a group (except for the GE transaction)." The main part of this statement is consistent with the opinion ventured at IETF 54, that a group is simply a shortcut for operating on multiple policy rules at once. In fact, the idea that a group should have a separate lifetime of its own was disparaged. Based on the IETF 54 discussion, the following changes would be appropriate in draft-stiemerling-midcom-semantics-02.txt: Sec. 2.3 sixth para currently reads: "Each group that is not a default group has its individual lifetime. If the group lifetime expires, the group and all member policies will be deleted at the middlebox. A group lifetime change (GLC) transaction may extend the lifetime of the group up to the limit specified at session setup, when the middlebox informs the agent about its capabilities. Also a GLC transaction may be used for deleting a group by requesting a lifetime of 0. After a successful GLC transaction, all member policies have the same lifetime as the group. Please note that by policy-specific transactions, the lifetime of an individual policy may be set to other values than the group lifetime, but an individual policy lifetime may never exceed the group lifetime." This should instead become: "A group lifetime change (GLC) may extend the lifetime OF THE POLICY RULES IN THE GROUP up to the limit specified at session setup, when the middlebox informs the agent about its capabilities. Also a GLC transaction may be used for deleting a group by requesting a lifetime of 0. After a successful GLC transaction, all member policies have the same lifetime as the group. Please note that by policy-specific transactions, the lifetime of an individual policy may be set to other values than the group lifetime." In the Group Establishment request, if the group lifetime parameter is retained at all, it would be the default lifetime for new policy rules assigned to the group if not stated explicitly in the request establishing the policy rule. I'm even less sure of the usefulness of this parameter in the Group Establishment reply. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Sep 25 04:22:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18934 for ; Wed, 25 Sep 2002 04:22:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8P8NZr05081 for midcom-archive@odin.ietf.org; Wed, 25 Sep 2002 04:23:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8P8MJv05038; Wed, 25 Sep 2002 04:22:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8P8L4v04995 for ; Wed, 25 Sep 2002 04:21:04 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18887 for ; Wed, 25 Sep 2002 04:18:59 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g8P8KGU94807; Wed, 25 Sep 2002 10:20:16 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D19286589C; Wed, 25 Sep 2002 10:20:15 +0200 (CEST) Date: Wed, 25 Sep 2002 10:20:16 +0200 From: Juergen Quittek To: Tom-PT Taylor , midcom@ietf.org Cc: "'Martin Stiemerling'" Message-ID: <2966525.1032949216@[192.168.102.164]> In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A925@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA0001E8A925@zcard0kc.ca.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Comments on draft-stiemerling-midcom-semantics-02.txt: Session/Pe er Identification Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, Thank you for commenting! Please see comments inline. Juergen -- Tom-PT Taylor wrote on 24 September 2002 10:10 -0400: > This is a series of notes on the content of > draft-stiemerling-midcom-semantics-01.txt. This note discusses the need for > content in each message which identifies the sender and possibly the session > with which the message is associated. > > I'll deal with the session identifier first. The first paragraph of section > 2.2 of the draft says that: > "Both agent and middlebox may participate in several sessions at the same > time." > > As I argue in draft-taylor-midcom-semgen-00.txt, this means at the very > least that every message must identify the sender, so that the receiver can > associate it with the right session. Thus every request from the agent must > contain the agent identifier, and every response and notification from the > middlebox must contain the middlebox identifier, as one of its parameters. I agree. An identifier should be explicitly mentioned in the semantics specification. However, it does not necessarily need to be an agent identifier and a middlebox idenitfier. A session identifier would sufficiently serve the same prupose. Furthermore, when discussing this in the semantics draft, we should mention that session/agent/middlebox identifiers are already there for almost any selected underlying communication channel. It certainly is there already when encryption or other security functions are applied, and enven if not, most time IP address and port number can serve this purpose. > Does this identification have to go so far as to require an authentication > token in every message? It may. The semantics document says that you may extend each transaction. However, I don't think it is required. Authenticating once and setting up a secure channel is already sufficient. > Aside from this general question, I believe it would make sense for the > middlebox to authenticate itself in a Session Establishment reply in the > failure case as well as in the success case, to forestall a > man-in-the-middle DOS attack based on spurious rejection. Interesting point. I agree on the advantage concerning the DOS attck against the client, but I am not sure whether or not this increases the impact of potential attacks against the middlebox. > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Sep 25 04:59:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19615 for ; Wed, 25 Sep 2002 04:59:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8P90Nb07355 for midcom-archive@odin.ietf.org; Wed, 25 Sep 2002 05:00:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8P8u8v07181; Wed, 25 Sep 2002 04:56:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8P8tYv07154 for ; Wed, 25 Sep 2002 04:55:34 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19545 for ; Wed, 25 Sep 2002 04:53:31 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g8P8sqU96236; Wed, 25 Sep 2002 10:54:52 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0357A65425; Wed, 25 Sep 2002 10:54:51 +0200 (CEST) Date: Wed, 25 Sep 2002 10:54:51 +0200 From: Juergen Quittek To: Tom-PT Taylor , midcom@ietf.org Cc: "'Martin Stiemerling'" Message-ID: <5041449.1032951291@[192.168.102.164]> In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A929@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA0001E8A929@zcard0kc.ca.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Comments on draft-stiemerling-midcom-semantics-02.txt: Role of Gr oups Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, I aggee to your arguments. When defining the semantics, we started exactly like this following the discussion we had at the Yokohama WG meeting: Basically, there is no need for a group timer. And consequently there is no need to negotiate group lifetime when creating a group, as you correctly state in your last paragraph. However, reality prove to be more complicated than expected. If you don'y use group timers, you need other means for deleting groups. For the semantics definition we considered four alternative choices of group deletion: 1. You don't care: a group once established lives forever. Please not that we support policies surviving an interruption of the session and hand-over from one session to another. In this context also groups should survive. But groups existing forever might not be a desirable choice, because group garbage might sum up at the middlebox. 2. You request that a group is deleted if the number of member policies becomes 0. This implies the following semantical problems: When you delete a policy, you might also delete a group. This group deletion needs to be signaled to the agent (known and stable state!). So you would need either to reply on the policy deletion request with a group deletion reply or with a special policy deletion reply indicating that also the group was deleted. Both choices would conflict with the clean separation between group transactions and policy transactions we achieved. 3. You explicitly add a group deletion transaction. 4. You add a group timer to the group creation request and to its reply. Because of the reasons given above, we first eliminated 1. and 2. Then we had to decide between 3. and 4. Out of these, we chose 4. for the following reasons: - It is less overhead adding an additional parameter to an existing transaction and to its reply than adding and entire transaction - Group timers are handled in exact analogy to policy timers. his is easy to understand and implement. So, we introduced group timers again, because we considered them the best solution for the group deletion problem. Juergen -- Tom-PT Taylor wrote on 24 September 2002 11:16 -0400: > This is the second note on draft-stiemerling-midcom-semantics-02.txt. This > note discusses the role of policy groups (AKA session bundles). > > The draft makes this statement about groups (sec. 2.3 third para): > > "Group transactions are redundant in the sense that a transaction on a > group can be replaced by the corresponding transaction on each member > of a group (except for the GE transaction)." > > The main part of this statement is consistent with the opinion ventured at > IETF 54, that a group is simply a shortcut for operating on multiple policy > rules at once. In fact, the idea that a group should have a separate > lifetime of its own was disparaged. Based on the IETF 54 discussion, the > following changes would be appropriate in > draft-stiemerling-midcom-semantics-02.txt: > > Sec. 2.3 sixth para currently reads: > > "Each group that is not a default group has its individual lifetime. > If the group lifetime expires, the group and all member policies will > be deleted at the middlebox. A group lifetime change (GLC) > transaction may extend the lifetime of the group up to the limit > specified at session setup, when the middlebox informs the agent > about its capabilities. Also a GLC transaction may be used for > deleting a group by requesting a lifetime of 0. After a successful > GLC transaction, all member policies have the same lifetime as the > group. Please note that by policy-specific transactions, the > lifetime of an individual policy may be set to other values than the > group lifetime, but an individual policy lifetime may never exceed > the group lifetime." > > This should instead become: > > "A group lifetime change (GLC) may extend the lifetime OF THE POLICY > RULES IN THE GROUP up to the limit specified at session setup, when > the middlebox informs the agent about its capabilities. Also a GLC > transaction may be used for > deleting a group by requesting a lifetime of 0. After a successful > GLC transaction, all member policies have the same lifetime as the > group. Please note that by policy-specific transactions, the > lifetime of an individual policy may be set to other values than the > group lifetime." > > In the Group Establishment request, if the group lifetime parameter is > retained at all, it would be the default lifetime for new policy rules > assigned to the group if not stated explicitly in the request establishing > the policy rule. I'm even less sure of the usefulness of this parameter in > the Group Establishment reply. > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Sep 25 09:31:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25492 for ; Wed, 25 Sep 2002 09:31:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8PDWfa21033 for midcom-archive@odin.ietf.org; Wed, 25 Sep 2002 09:32:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8PDVBv20998; Wed, 25 Sep 2002 09:31:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8PDUov20949 for ; Wed, 25 Sep 2002 09:30:50 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25461 for ; Wed, 25 Sep 2002 09:28:56 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8PDU6H21895; Wed, 25 Sep 2002 09:30:06 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Sep 2002 09:30:09 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A934@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Juergen Quittek'" , midcom@ietf.org Cc: "'Martin Stiemerling'" Date: Wed, 25 Sep 2002 09:30:06 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] RE: Comments on draft-stiemerling-midcom-semantics-02.txt: Role o f Gr oups Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , With the changes in wording I proposed, I intended that any group timer setting would reset the time to live on on policy rules currently in the group, even if these times had been set previously on a per-policy basis. Thus your group deletion mechanism still holds. > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Wednesday, September 25, 2002 4:55 AM > To: Taylor, Tom-PT [CAR:B602:EXCH]; midcom@ietf.org > Cc: 'Martin Stiemerling' > Subject: Re: Comments on > draft-stiemerling-midcom-semantics-02.txt: Role of Gr oups > > > Tom, > > I aggee to your arguments. When defining the semantics, we > started exactly like this following the discussion we had at > the Yokohama WG meeting: > > Basically, there is no need for a group timer. > > And consequently there is no need to negotiate group lifetime > when creating a group, as you correctly state in your last paragraph. > > However, reality prove to be more complicated than expected. > If you don'y use group timers, you need other means for > deleting groups. > > For the semantics definition we considered four alternative > choices of group deletion: > > 1. You don't care: a group once established lives forever. > Please not that we support policies surviving an interruption > of the session and hand-over from one session to another. > In this context also groups should survive. > But groups existing forever might not be a desirable choice, > because group garbage might sum up at the middlebox. > > 2. You request that a group is deleted if the number of member > policies becomes 0. This implies the following semantical > problems: When you delete a policy, you might also delete a > group. This group deletion needs to be signaled to the agent > (known and stable state!). So you would need either to reply > on the policy deletion request with a group deletion reply > or with a special policy deletion reply indicating that also > the group was deleted. Both choices would conflict with the > clean separation between group transactions and policy > transactions we achieved. > > 3. You explicitly add a group deletion transaction. > > 4. You add a group timer to the group creation request and to > its reply. > > Because of the reasons given above, we first eliminated 1. > and 2. Then we had to decide between 3. and 4. Out of these, > we chose 4. for the following reasons: > > - It is less overhead adding an additional parameter to > an existing transaction and to its reply than adding > and entire transaction > > - Group timers are handled in exact analogy to policy timers. > his is easy to understand and implement. > > So, we introduced group timers again, because we considered > them the best solution for the group deletion problem. > > Juergen > > > -- Tom-PT Taylor wrote on 24 September 2002 11:16 -0400: > > > This is the second note on > draft-stiemerling-midcom-semantics-02.txt. > > This note discusses the role of policy groups (AKA session bundles). > > > > The draft makes this statement about groups (sec. 2.3 third para): > > > > "Group transactions are redundant in the sense that a > transaction on a > > group can be replaced by the corresponding transaction > on each member > > of a group (except for the GE transaction)." > > > > The main part of this statement is consistent with the opinion > > ventured at IETF 54, that a group is simply a shortcut for > operating > > on multiple policy rules at once. In fact, the idea that a group > > should have a separate lifetime of its own was disparaged. > Based on > > the IETF 54 discussion, the following changes would be > appropriate in > > draft-stiemerling-midcom-semantics-02.txt: > > > > Sec. 2.3 sixth para currently reads: > > > > "Each group that is not a default group has its > individual lifetime. > > If the group lifetime expires, the group and all member > policies will > > be deleted at the middlebox. A group lifetime change (GLC) > > transaction may extend the lifetime of the group up to the limit > > specified at session setup, when the middlebox informs the agent > > about its capabilities. Also a GLC transaction may be used for > > deleting a group by requesting a lifetime of 0. After a > successful > > GLC transaction, all member policies have the same > lifetime as the > > group. Please note that by policy-specific transactions, the > > lifetime of an individual policy may be set to other > values than the > > group lifetime, but an individual policy lifetime may > never exceed > > the group lifetime." > > > > This should instead become: > > > > "A group lifetime change (GLC) may extend the lifetime OF > THE POLICY > > RULES IN THE GROUP up to the limit specified at session > setup, when > > the middlebox informs the agent about its capabilities. > Also a GLC > > transaction may be used for > > deleting a group by requesting a lifetime of 0. After a > successful > > GLC transaction, all member policies have the same > lifetime as the > > group. Please note that by policy-specific transactions, the > > lifetime of an individual policy may be set to other > values than the > > group lifetime." > > > > In the Group Establishment request, if the group lifetime > parameter is > > retained at all, it would be the default lifetime for new > policy rules > > assigned to the group if not stated explicitly in the request > > establishing the policy rule. I'm even less sure of the > usefulness of > > this parameter in the Group Establishment reply. > > > > Tom Taylor > > taylor@nortelnetworks.com > > Ph. +1 613 736 0961 (ESN 396 1490) > > > > > > > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Sep 25 10:08:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26763 for ; Wed, 25 Sep 2002 10:08:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8PE9iI23584 for midcom-archive@odin.ietf.org; Wed, 25 Sep 2002 10:09:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8PE5Bv22892; Wed, 25 Sep 2002 10:05:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8PE4bv22851 for ; Wed, 25 Sep 2002 10:04:37 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26528 for ; Wed, 25 Sep 2002 10:02:42 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g8PE43U10804; Wed, 25 Sep 2002 16:04:03 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C653D65AB5; Wed, 25 Sep 2002 16:04:01 +0200 (CEST) Date: Wed, 25 Sep 2002 16:04:02 +0200 From: Juergen Quittek To: Tom-PT Taylor , midcom@ietf.org Cc: "'Martin Stiemerling'" Message-ID: <17403374.1032969842@[192.168.102.164]> In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A934@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA0001E8A934@zcard0kc.ca.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] RE: Comments on draft-stiemerling-midcom-semantics-02.txt: Role o f Gr oups Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, -- Tom-PT Taylor wrote on 25 September 2002 09:30 -0400: > With the changes in wording I proposed, I intended that any group timer > setting would reset the time to live on on policy rules currently in the > group, even if these times had been set previously on a per-policy basis. > Thus your group deletion mechanism still holds. Then we have full agreement. Maybe, we just phrased it not clear enough in our draft when describint the group lifetime change (GLC) transaction: "After a successful GLC transaction, all member policies have the same lifetime as the group." Juergen >> -----Original Message----- >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> Sent: Wednesday, September 25, 2002 4:55 AM >> To: Taylor, Tom-PT [CAR:B602:EXCH]; midcom@ietf.org >> Cc: 'Martin Stiemerling' >> Subject: Re: Comments on >> draft-stiemerling-midcom-semantics-02.txt: Role of Gr oups >> >> >> Tom, >> >> I aggee to your arguments. When defining the semantics, we >> started exactly like this following the discussion we had at >> the Yokohama WG meeting: >> >> Basically, there is no need for a group timer. >> >> And consequently there is no need to negotiate group lifetime >> when creating a group, as you correctly state in your last paragraph. >> >> However, reality prove to be more complicated than expected. >> If you don'y use group timers, you need other means for >> deleting groups. >> >> For the semantics definition we considered four alternative >> choices of group deletion: >> >> 1. You don't care: a group once established lives forever. >> Please not that we support policies surviving an interruption >> of the session and hand-over from one session to another. >> In this context also groups should survive. >> But groups existing forever might not be a desirable choice, >> because group garbage might sum up at the middlebox. >> >> 2. You request that a group is deleted if the number of member >> policies becomes 0. This implies the following semantical >> problems: When you delete a policy, you might also delete a >> group. This group deletion needs to be signaled to the agent >> (known and stable state!). So you would need either to reply >> on the policy deletion request with a group deletion reply >> or with a special policy deletion reply indicating that also >> the group was deleted. Both choices would conflict with the >> clean separation between group transactions and policy >> transactions we achieved. >> >> 3. You explicitly add a group deletion transaction. >> >> 4. You add a group timer to the group creation request and to >> its reply. >> >> Because of the reasons given above, we first eliminated 1. >> and 2. Then we had to decide between 3. and 4. Out of these, >> we chose 4. for the following reasons: >> >> - It is less overhead adding an additional parameter to >> an existing transaction and to its reply than adding >> and entire transaction >> >> - Group timers are handled in exact analogy to policy timers. >> his is easy to understand and implement. >> >> So, we introduced group timers again, because we considered >> them the best solution for the group deletion problem. >> >> Juergen >> >> >> -- Tom-PT Taylor wrote on 24 September 2002 11:16 -0400: >> >> > This is the second note on >> draft-stiemerling-midcom-semantics-02.txt. >> > This note discusses the role of policy groups (AKA session bundles). >> > >> > The draft makes this statement about groups (sec. 2.3 third para): >> > >> > "Group transactions are redundant in the sense that a >> transaction on a >> > group can be replaced by the corresponding transaction >> on each member >> > of a group (except for the GE transaction)." >> > >> > The main part of this statement is consistent with the opinion >> > ventured at IETF 54, that a group is simply a shortcut for >> operating >> > on multiple policy rules at once. In fact, the idea that a group >> > should have a separate lifetime of its own was disparaged. >> Based on >> > the IETF 54 discussion, the following changes would be >> appropriate in >> > draft-stiemerling-midcom-semantics-02.txt: >> > >> > Sec. 2.3 sixth para currently reads: >> > >> > "Each group that is not a default group has its >> individual lifetime. >> > If the group lifetime expires, the group and all member >> policies will >> > be deleted at the middlebox. A group lifetime change (GLC) >> > transaction may extend the lifetime of the group up to the limit >> > specified at session setup, when the middlebox informs the agent >> > about its capabilities. Also a GLC transaction may be used for >> > deleting a group by requesting a lifetime of 0. After a >> successful >> > GLC transaction, all member policies have the same >> lifetime as the >> > group. Please note that by policy-specific transactions, the >> > lifetime of an individual policy may be set to other >> values than the >> > group lifetime, but an individual policy lifetime may >> never exceed >> > the group lifetime." >> > >> > This should instead become: >> > >> > "A group lifetime change (GLC) may extend the lifetime OF >> THE POLICY >> > RULES IN THE GROUP up to the limit specified at session >> setup, when >> > the middlebox informs the agent about its capabilities. >> Also a GLC >> > transaction may be used for >> > deleting a group by requesting a lifetime of 0. After a >> successful >> > GLC transaction, all member policies have the same >> lifetime as the >> > group. Please note that by policy-specific transactions, the >> > lifetime of an individual policy may be set to other >> values than the >> > group lifetime." >> > >> > In the Group Establishment request, if the group lifetime >> parameter is >> > retained at all, it would be the default lifetime for new >> policy rules >> > assigned to the group if not stated explicitly in the request >> > establishing the policy rule. I'm even less sure of the >> usefulness of >> > this parameter in the Group Establishment reply. >> > >> > Tom Taylor >> > taylor@nortelnetworks.com >> > Ph. +1 613 736 0961 (ESN 396 1490) >> > >> > >> > >> >> >> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Sep 25 11:31:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29551 for ; Wed, 25 Sep 2002 11:31:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8PFXJI28027 for midcom-archive@odin.ietf.org; Wed, 25 Sep 2002 11:33:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8PFVXv27971; Wed, 25 Sep 2002 11:31:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8PFUwv27931 for ; Wed, 25 Sep 2002 11:30:58 -0400 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 LAA29450 for ; Wed, 25 Sep 2002 11:29:02 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8PFUN1X027728 for ; Wed, 25 Sep 2002 08:30:23 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AFG00708; Wed, 25 Sep 2002 08:26:26 -0700 (PDT) Message-Id: <200209251526.AFG00708@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Wed, 25 Sep 2002 11:30:22 -0400 Subject: [midcom] STUN update Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , FYI - The STUN draft has been scrutinized by security types in the IESG and IAB, and we've gotten some feedback. The main concern is about the DDoS potential, although given the topological requirements to pull it off, this attack is not peculiar to STUN. They've also asked for some clarifications on two points: 1) how to check the DNS name, and 2) what is meant by the recommendation that a check be performed to see whether or not a server is authorized to provide STUN responses. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Sep 30 12:15:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10445 for ; Mon, 30 Sep 2002 12:15:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8UGHK416044 for midcom-archive@odin.ietf.org; Mon, 30 Sep 2002 12:17:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UGFbv15972; Mon, 30 Sep 2002 12:15:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UGDNv15825 for ; Mon, 30 Sep 2002 12:13:23 -0400 Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10201 for ; Mon, 30 Sep 2002 12:11:23 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8UGCbF03329; Mon, 30 Sep 2002 12:12:37 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 12:12:41 -0400 Message-ID: <4D79C746863DD51197690002A52CDA000400DCD0@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Juergen Quittek'" , midcom@ietf.org Cc: "'Martin Stiemerling'" Date: Mon, 30 Sep 2002 12:12:32 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] RE: Comments on draft-stiemerling-midcom-semantics-02.txt: Role o f Gr oups Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Just to be clear: I intended in my comments that it be possible, after setting a group lifetime, to set individual policy rule lifetimes which exceed the lifetime of their group. > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Wednesday, September 25, 2002 10:04 AM > To: Taylor, Tom-PT [CAR:B602:EXCH]; midcom@ietf.org > Cc: 'Martin Stiemerling' > Subject: RE: Comments on > draft-stiemerling-midcom-semantics-02.txt: Role o f Gr oups > > > Tom, > > -- Tom-PT Taylor wrote on 25 September 2002 09:30 -0400: > > > With the changes in wording I proposed, I intended that any group > > timer setting would reset the time to live on on policy rules > > currently in the group, even if these times had been set > previously on > > a per-policy basis. Thus your group deletion mechanism still holds. > > Then we have full agreement. Maybe, we just phrased it not > clear enough in our draft when describint the group lifetime > change (GLC) > transaction: > > "After a successful GLC transaction, all member policies > have the same lifetime as the group." > > Juergen > > >> -----Original Message----- > >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > >> Sent: Wednesday, September 25, 2002 4:55 AM > >> To: Taylor, Tom-PT [CAR:B602:EXCH]; midcom@ietf.org > >> Cc: 'Martin Stiemerling' > >> Subject: Re: Comments on > >> draft-stiemerling-midcom-semantics-02.txt: Role of Gr oups > >> > >> > >> Tom, > >> > >> I aggee to your arguments. When defining the semantics, we started > >> exactly like this following the discussion we had at the > Yokohama WG > >> meeting: > >> > >> Basically, there is no need for a group timer. > >> > >> And consequently there is no need to negotiate group lifetime when > >> creating a group, as you correctly state in your last paragraph. > >> > >> However, reality prove to be more complicated than > expected. If you > >> don'y use group timers, you need other means for deleting groups. > >> > >> For the semantics definition we considered four > alternative choices > >> of group deletion: > >> > >> 1. You don't care: a group once established lives forever. > >> Please not that we support policies surviving an interruption > >> of the session and hand-over from one session to another. > >> In this context also groups should survive. > >> But groups existing forever might not be a desirable choice, > >> because group garbage might sum up at the middlebox. > >> > >> 2. You request that a group is deleted if the number of member > >> policies becomes 0. This implies the following semantical > >> problems: When you delete a policy, you might also delete a > >> group. This group deletion needs to be signaled to the agent > >> (known and stable state!). So you would need either to reply > >> on the policy deletion request with a group deletion reply > >> or with a special policy deletion reply indicating that also > >> the group was deleted. Both choices would conflict with the > >> clean separation between group transactions and policy > >> transactions we achieved. > >> > >> 3. You explicitly add a group deletion transaction. > >> > >> 4. You add a group timer to the group creation request and to > >> its reply. > >> > >> Because of the reasons given above, we first eliminated 1. and 2. > >> Then we had to decide between 3. and 4. Out of these, we > chose 4. for > >> the following reasons: > >> > >> - It is less overhead adding an additional parameter to > >> an existing transaction and to its reply than adding > >> and entire transaction > >> > >> - Group timers are handled in exact analogy to policy timers. > >> his is easy to understand and implement. > >> > >> So, we introduced group timers again, because we > considered them the > >> best solution for the group deletion problem. > >> > >> Juergen > >> > >> > >> -- Tom-PT Taylor wrote on 24 September 2002 11:16 -0400: > >> > >> > This is the second note on > >> draft-stiemerling-midcom-semantics-02.txt. > >> > This note discusses the role of policy groups (AKA session > >> > bundles). > >> > > >> > The draft makes this statement about groups (sec. 2.3 > third para): > >> > > >> > "Group transactions are redundant in the sense that a > >> transaction on a > >> > group can be replaced by the corresponding transaction > >> on each member > >> > of a group (except for the GE transaction)." > >> > > >> > The main part of this statement is consistent with the opinion > >> > ventured at IETF 54, that a group is simply a shortcut for > >> operating > >> > on multiple policy rules at once. In fact, the idea > that a group > >> > should have a separate lifetime of its own was disparaged. > >> Based on > >> > the IETF 54 discussion, the following changes would be > >> appropriate in > >> > draft-stiemerling-midcom-semantics-02.txt: > >> > > >> > Sec. 2.3 sixth para currently reads: > >> > > >> > "Each group that is not a default group has its > >> individual lifetime. > >> > If the group lifetime expires, the group and all member > >> policies will > >> > be deleted at the middlebox. A group lifetime change (GLC) > >> > transaction may extend the lifetime of the group up > to the limit > >> > specified at session setup, when the middlebox > informs the agent > >> > about its capabilities. Also a GLC transaction may be used for > >> > deleting a group by requesting a lifetime of 0. After a > >> successful > >> > GLC transaction, all member policies have the same > >> lifetime as the > >> > group. Please note that by policy-specific transactions, the > >> > lifetime of an individual policy may be set to other > >> values than the > >> > group lifetime, but an individual policy lifetime may > >> never exceed > >> > the group lifetime." > >> > > >> > This should instead become: > >> > > >> > "A group lifetime change (GLC) may extend the lifetime OF > >> THE POLICY > >> > RULES IN THE GROUP up to the limit specified at session > >> setup, when > >> > the middlebox informs the agent about its capabilities. > >> Also a GLC > >> > transaction may be used for > >> > deleting a group by requesting a lifetime of 0. After a > >> successful > >> > GLC transaction, all member policies have the same > >> lifetime as the > >> > group. Please note that by policy-specific transactions, the > >> > lifetime of an individual policy may be set to other > >> values than the > >> > group lifetime." > >> > > >> > In the Group Establishment request, if the group lifetime > >> parameter is > >> > retained at all, it would be the default lifetime for new > >> policy rules > >> > assigned to the group if not stated explicitly in the request > >> > establishing the policy rule. I'm even less sure of the > >> usefulness of > >> > this parameter in the Group Establishment reply. > >> > > >> > Tom Taylor > >> > taylor@nortelnetworks.com > >> > Ph. +1 613 736 0961 (ESN 396 1490) > >> > > >> > > >> > > >> > >> > >> > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Sep 30 20:22:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25742 for ; Mon, 30 Sep 2002 20:22:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g910OUf32731 for midcom-archive@odin.ietf.org; Mon, 30 Sep 2002 20:24:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g910NHv32712; Mon, 30 Sep 2002 20:23:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g910MXv32690 for ; Mon, 30 Sep 2002 20:22:33 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25676 for ; Mon, 30 Sep 2002 20:20:29 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g910Lql19183; Mon, 30 Sep 2002 20:21:52 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 20:21:55 -0400 Message-ID: <4D79C746863DD51197690002A52CDA000400DCDC@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: midcom@ietf.org Cc: "'Juergen Quittek'" , "'Martin Stiemerling'" Date: Mon, 30 Sep 2002 20:21:45 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Midcom Semantics: Reserve vs. Address-Bind Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , In my analysis of Midcom semantics as presented in draft-taylor-midcom-semgen-00.txt, I separate rule instantiation into two phases: address binding and flow enabling. In draft-stiemerling-midcom-semantics-02.txt the separation instead is into address reservation and flow enabling. I have to ask the Working Group: which is a more realistic view of Middlebox operation? Just to show the difference: according to my analysis, setting up a combined NAT-firewall operation is done in two steps: (1) Provide the "actual" source and destination address-ports (one or the other may be "ANY"), and request a binding. The middlebox will return the intermediate source and destination addresses associated with the binding. In the twice-NAT case both of these will correspond to interfaces on the middlebox itself. Otherwise at least one will be the same as the actual source or destination respectively. (2) Request that a flow be enabled for packets with the given actual source and intermediate destination, mapping the matching packets to the intermediate source and actual destination. These two steps are the same regardless of whether we are dealing with an incoming or outgoing flow, and regardless of whether we are dealing with pure firewall, NAT-firewall, or twice NAT and firewall. As Juergen and Martin see it, the first step is to reserve addresses and ports on a given side of the middlebox. If they are needed on both sides (and I believe that is so for twice-NAT), then two reservation requests are made. Their second step is then to request a flow and binding. The basic difference is that they do not supply any information in the first step other than what they need reserved. It strikes me that this deprives the middlebox of the opportunity to apply policy to address-port reservation based on source or destination. The question is whether this matters. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom