From mailnull@www1.ietf.org Mon Jun 2 13:33:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16021 for ; Mon, 2 Jun 2003 13:33:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52HX7R02882 for midcom-archive@odin.ietf.org; Mon, 2 Jun 2003 13:33: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 h52HVbB02698; Mon, 2 Jun 2003 13:31: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 h52HMpB02263 for ; Mon, 2 Jun 2003 13:22:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15656 for ; Mon, 2 Jun 2003 13:22:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MszW-0004pM-00 for midcom@ietf.org; Mon, 02 Jun 2003 13:21:02 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19MszU-0004pE-00 for midcom@ietf.org; Mon, 02 Jun 2003 13:21:01 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h52HMDjS013881; Mon, 2 Jun 2003 10:22:14 -0700 (PDT) Received: from [10.61.34.188] (sjc-vpn4-300.cisco.com [10.21.81.44]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AER37759; Mon, 2 Jun 2003 10:22:12 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 01 Jun 2003 19:00:26 -0700 Subject: Re: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg From: Cullen Jennings To: , Midcom Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 5/27/03 2:12 AM, "john Holdsworth" wrote: > The big issue for STUN is that it won't work with most (95%+?) of corporate > NATs and firewalls which translate ports on a symmetric basis. That is if > any of the source or destination details change a new NAT mapping is > employed. This makes STUN useless. > This is simply not true and you probably don't understand what "symmetric" means as defined in the STUN RFC - the RFC does use "symmetric" to mean something somewhat different from what most NAT developers would mean by the term so I do forgive the confusion to most people. Go test a Cisco IOS or PIX based "corporate grade NAT" - you will find they are not symmetric. You might be surprised on tests from other NATs vendors too. You will find your 95% number is very wrong. The difference between "symmetric" and "port restricted" in STUN is nothing to do with the security of what packets are allowed through the NAT but is determined by if the NAT reuses port numbers when it can. Given "corporate grade" NATs only have 65k ports per IP and don't want to run out of ports, they generally choose to reuse the ports. This makes them port restricted instead of symmetric. This leads to a natural tendency away from symmetric on large NATs. On small NATs, such as the type that might be in your home, there is no worry on running out of ports so more or less random things are done between symmetric and port restricted on these devices. I have been talking to a few of the "home NAT" vendors and explaining that: 1) symmetric and port restricted are the same from a security point of view 2) they are about the same to implement from a complexity, memory footprint, and speed point of view 3) port restricted helps VoIP system 4) port restricted helps networked games None of them have identified any concerns on why symmetric might be preferred to port restricted. For some reason, 4 seems much more compelling to them than 3. Go figure. Of course an exception to the "ho-hum" about 3 is the vendor that has the number one market share in the SOHO NAT space is very interested about making sure they work well with VoIP :-) Cullen Cisco/Linksys _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Jun 7 08:17:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11767 for ; Sat, 7 Jun 2003 08:17:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h57CHPd29835 for midcom-archive@odin.ietf.org; Sat, 7 Jun 2003 08:17:25 -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 h57CG8B29804; Sat, 7 Jun 2003 08:16: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 h57CErB29754 for ; Sat, 7 Jun 2003 08:14:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11751 for ; Sat, 7 Jun 2003 08:14:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OcZ4-0003Na-00 for midcom@ietf.org; Sat, 07 Jun 2003 08:12:54 -0400 Received: from out002pub.verizon.net ([206.46.170.141] helo=out002.verizon.net) by ietf-mx with esmtp (Exim 4.12) id 19OcZ3-0003NQ-00 for midcom@ietf.org; Sat, 07 Jun 2003 08:12:53 -0400 Received: from [192.168.1.100] ([151.199.29.196]) by out002.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030607121419.KGVK13328.out002.verizon.net@[192.168.1.100]>; Sat, 7 Jun 2003 07:14:19 -0500 From: Bryan Ford Organization: Massachusetts Institute of Technology To: Cullen Jennings , , Midcom Subject: Re: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg Date: Sat, 7 Jun 2003 08:14:18 -0400 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200306070814.18921.baford@mit.edu> X-Authentication-Info: Submitted using SMTP AUTH at out002.verizon.net from [151.199.29.196] at Sat, 7 Jun 2003 07:14:19 -0500 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, Thank you for your informative post. > The difference between "symmetric" and "port restricted" in STUN is nothing > to do with the security of what packets are allowed through the NAT but is > determined by if the NAT reuses port numbers when it can. Given "corporate > grade" NATs only have 65k ports per IP and don't want to run out of ports, > they generally choose to reuse the ports. This makes them port restricted > instead of symmetric. This leads to a natural tendency away from symmetric > on large NATs. I have one question about this issue that has come up recently. I'd particularly like to get your view on this (as a knowledgable technical person from, presumably, the biggest vendor of corporate NATs :)), but also from others on this list who may have relevant information. Unfortunately the question involves a little bit of "setup"; I hope you'll bear with me... For the purpose of this message I would like to re-classify NATs into _three_ categories, based on how they allocate ports for translation sessions: - "Cone NAT": usual definition - allocates a public NAT port number for a (private IP, private port) pair when the first outgoing session is established from that (private IP, private port) pair; reuses that public/private mapping in future sessions that may involve different external hosts and/por ports. - "Wasteful Symmetric NAT": the typical kind of symmetric NAT - allocates a public NAT port each time a new outgoing session is initiated; each public NAT port remains allocated until that session terminates or times out and cannot be allocated concurrently to any other session during that time. - "Frugal Symmetric NAT": assigns a new NAT port to each new outgoing session initiated from within the firewall... BUT... allocation is not done on a basis of "whole" port numbers at all but on "session identifiers", which include all the details of the session (private IP/port, nat IP/port, external IP/port). Therefore, a given public NAT port can actually be reused concurrently by multiple simultaneous (perhaps completely unrelated) sessions, as long as each session remains uniquely distinguishable on both sides of the NAT. Since the behavior of a "frugal symmetric NAT" may not be obvious, here is a specific example of how one might work. The NAT has two internal hash tables for looking up sessions from the information found in TCP or UDP packets. The first table is for packets originating on the internal network, and is indexed on (internal IP, internal port, external IP, external port) - i.e., the "session identifier" as seen by internal hosts. The second is for packets originating on the external network, and is indexed on (NAT IP, NAT port, external IP, external port). The NAT has NO port allocation table or bitmap of any kind, because allocations are not done at a port granularity. Instead, when outgoing traffic initiates a new internal session, for which no entry is seen in the first (internal-packet-lookup) hash table, the NAT simply picks a public NAT port randomly to generate a corresponding external session tuple (NAT IP, NAT port, external IP, external port), and checks to see if an entry for that tuple already exists in the external-packet-lookup hash table. If not, the translation is created; if so, a new random port number is selected and the process is repeated until it succeeds or some fixed retry limit is reached. The upshot is that while a Cone NAT utilizes its port space more efficiently than a Wasteful Symmetric NAT, a Frugal Symmetric NAT could in turn utilize its port space several orders of magnitude more efficiently than a Cone NAT. Instead of being limited to 2^16 sessions total (Wasteful Symmetric NAT) or 2^16 translations (Cone NAT), a Frugal Symmetric NAT can potentially support 2^16 active sessions _per external endpoint_ from any number of internal clients in any combination. The space of concurrently active outgoing sessions possible for a given NAT IP address is effectively expanded from a 16-bit space (NAT port number alone) to a 64-bit space (NAT port number, external IP, external port). As far as realistic applications and protocols are concerned, a Frugal Symmetric NAT behaves indistinguishably from a Wasteful Symmetric NAT - i.e., it will work just fine for client/server traffic but will suck in the usual way for peer-to-peer traffic. So with all that setup out of the way, here are my questions: (a) Does anyone know if such a thing as a "Frugal Symmetric NAT" actually exists right now? I know that most existing symmetric NATs are of the "Wasteful" variety, but I don't know if _all_ of them are. (b) Do you think it's likely that corporate NAT vendors such as Cisco will feel increasing pressure to build Frugal Symmetric NATs in the forseeable future, as a result of the demand for larger NATs that can handle more and more simultaneous connections with fewer globally routable IP addresses? (I'm thinking AOL here as an example, which from what I hear runs "the world's largest NAT" in front of all its customers.) (c) Or, do you think the increasing economic/political/whatever pressure to make NATs more peer-to-peer friendly, in order to support VoIP and networked games and all that, is in practice going to outweigh the pressure for "port frugality", ensuring that almost all NATs in the future will be (port-restricted) cone NATs? (d) Finally, if there is a substantial amount of real pressure in _both_ directions (port frugality and P2P friendliness), do you see a possibility that vendors may start considering even more complex hybrid solutions, say, which may be able treat certain (P2P) traffic in Cone NAT fashion while behaving as a Frugal Symmetric NAT for other (client/server) traffic? I realize that there are no absolutes here - I'm looking for opinions and industry projections. Thanks very much, Bryan _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Jun 9 07:52:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29015 for ; Mon, 9 Jun 2003 07:52:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59BqBJ26577 for midcom-archive@odin.ietf.org; Mon, 9 Jun 2003 07:52: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 h59BmgB26412; Mon, 9 Jun 2003 07:48:42 -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 h59BjRB26280 for ; Mon, 9 Jun 2003 07:45:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28626; Mon, 9 Jun 2003 07:45:25 -0400 (EDT) Message-Id: <200306091145.HAA28626@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 09 Jun 2003 07:45:24 -0400 Subject: [midcom] I-D ACTION:draft-vainshtein-cesopsn-06.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 : TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) Author(s) : S. Vainshtein et al. Filename : draft-vainshtein-cesopsn-06.txt Pages : 38 Date : 2003-6-6 This document describes a method for encapsulating unstructured (T1, E1, T3, E3) and structured (n*DS0) TDM signals as pseudo-wires over packet-switching networks (PSN). In this regard, it complements similar work for SONET/SDH. Proposed PW encapsulation uses RTP for clock recovery and leverages RTP-based mixing capabilities for application state signaling between Customer Edge (CE) devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-vainshtein-cesopsn-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vainshtein-cesopsn-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-6133143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vainshtein-cesopsn-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-vainshtein-cesopsn-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-6133143.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Jun 9 08:23:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00077 for ; Mon, 9 Jun 2003 08:23:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59CMw228971 for midcom-archive@odin.ietf.org; Mon, 9 Jun 2003 08:22:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59CKPB28857; Mon, 9 Jun 2003 08:20:25 -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 h59CGnB28648 for ; Mon, 9 Jun 2003 08:16:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29562 for ; Mon, 9 Jun 2003 08:16:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PLXz-00028g-00 for midcom@ietf.org; Mon, 09 Jun 2003 08:14:47 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19PLXy-00028T-00 for midcom@ietf.org; Mon, 09 Jun 2003 08:14:46 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h59CGFI2016977; Mon, 9 Jun 2003 05:16:15 -0700 (PDT) Received: from [192.168.1.5] (sjc-vpn4-177.cisco.com [10.21.80.177]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEW92903; Mon, 9 Jun 2003 05:16:14 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 09 Jun 2003 05:16:15 -0700 Subject: Re: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg From: Cullen Jennings To: Bryan Ford , Midcom Message-ID: In-Reply-To: <200306070814.18921.baford@mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit What you are saying makes a lot of sense - I think your example helps clarify things - I will try and put some answers inline as best I can. Just to make the discussion easier, lets assume that that the NAT only has one external IP address. It does not really change much if it has more. I will also gloss over the multiple protocols but again that makes no difference - you can treat it as completely separate virtual NATs for each protocol. My apologies to folks who point out this is PAT not NAT. End of disclaimers :-) On 6/7/03 5:14 AM, "Bryan Ford" wrote: > Cullen, > > Thank you for your informative post. > >> The difference between "symmetric" and "port restricted" in STUN is nothing >> to do with the security of what packets are allowed through the NAT but is >> determined by if the NAT reuses port numbers when it can. Given "corporate >> grade" NATs only have 65k ports per IP and don't want to run out of ports, >> they generally choose to reuse the ports. This makes them port restricted >> instead of symmetric. This leads to a natural tendency away from symmetric >> on large NATs. > > I have one question about this issue that has come up recently. I'd > particularly like to get your view on this (as a knowledgable technical > person from, presumably, the biggest vendor of corporate NATs :)), but also (really I'm a VoIP guy who plans to work for a major IPv6 vendor but I know a guy who plays a ...) > from others on this list who may have relevant information. Unfortunately > the question involves a little bit of "setup"; I hope you'll bear with me... > > For the purpose of this message I would like to re-classify NATs into _three_ > categories, based on how they allocate ports for translation sessions: > > - "Cone NAT": usual definition - allocates a public NAT port number for a > (private IP, private port) pair when the first outgoing session is > established from that (private IP, private port) pair; reuses that > public/private mapping in future sessions that may involve different external > hosts and/por ports. > > - "Wasteful Symmetric NAT": the typical kind of symmetric NAT - allocates a > public NAT port each time a new outgoing session is initiated; each public > NAT port remains allocated until that session terminates or times out and > cannot be allocated concurrently to any other session during that time. It's worth noting that when a packet arrives on the external port, the NAT can figure where to send it on the inside by just looking at the port it arrived on. The NAT still needs to keep the full session mapping to decide if it should forward the packet at all - so the size of the state stored in memory between this NAT and your frugal NAT is going to be similar. > > - "Frugal Symmetric NAT": assigns a new NAT port to each new outgoing session > initiated from within the firewall... BUT... allocation is not done on a > basis of "whole" port numbers at all but on "session identifiers", which > include all the details of the session (private IP/port, nat IP/port, > external IP/port). Therefore, a given public NAT port can actually be reused > concurrently by multiple simultaneous (perhaps completely unrelated) > sessions, as long as each session remains uniquely distinguishable on both > sides of the NAT. > Yes, this is a good idea and some NATs do this today. However, the details are still in how they pick the NAT port. One way would be to use random ports as you suggest below. Another way would be to attempt to use the same external port for all sessions that have the same internal IP and internal port. Because each internal IP can only have 2^16 ports, the fact that the NAT has 2^16 external ports make for a nice mapping that the there will be enough ports on the NAT for it to assign a unique external port for each session that has a unique internal IP and internal port regardless of the number of internal IPs. Keep in mind this port allocation scheme still fully meets your frugal NAT definition but now consider this from the STUN terminology point of view. Because packets from the same internal IP/port use the same NAT port, this is a port restricted NAT. The terminology of "port restricted" in STUN was a little confusing because many of the NAT people consider this still to be a form of "symmetric" - the NAT folks mostly seem to define "symmetric" as you can only receive a packet from public IP/port if you have sent to that IP/port on the same protocol. Anyways, it is just a label defining a term so it's not worth worrying about but it is worth nothing that the STUN definition of "symmetric" might not line up exactly with some others. > Since the behavior of a "frugal symmetric NAT" may not be obvious, here is a > specific example of how one might work. The NAT has two internal hash tables > for looking up sessions from the information found in TCP or UDP packets. > The first table is for packets originating on the internal network, and is > indexed on (internal IP, internal port, external IP, external port) - i.e., > the "session identifier" as seen by internal hosts. The second is for > packets originating on the external network, and is indexed on (NAT IP, NAT > port, external IP, external port). The NAT has NO port allocation table or > bitmap of any kind, because allocations are not done at a port granularity. > Instead, when outgoing traffic initiates a new internal session, for which no > entry is seen in the first (internal-packet-lookup) hash table, the NAT > simply picks a public NAT port randomly to generate a corresponding external > session tuple (NAT IP, NAT port, external IP, external port), and checks to > see if an entry for that tuple already exists in the external-packet-lookup > hash table. If not, the translation is created; if so, a new random port > number is selected and the process is repeated until it succeeds or some > fixed retry limit is reached. > > The upshot is that while a Cone NAT utilizes its port space more efficiently > than a Wasteful Symmetric NAT, a Frugal Symmetric NAT could in turn utilize > its port space several orders of magnitude more efficiently than a Cone NAT. > Instead of being limited to 2^16 sessions total (Wasteful Symmetric NAT) or > 2^16 translations (Cone NAT), a Frugal Symmetric NAT can potentially support > 2^16 active sessions _per external endpoint_ from any number of internal > clients in any combination. The space of concurrently active outgoing > sessions possible for a given NAT IP address is effectively expanded from a > 16-bit space (NAT port number alone) to a 64-bit space (NAT port number, > external IP, external port). As far as realistic applications and protocols > are concerned, a Frugal Symmetric NAT behaves indistinguishably from a > Wasteful Symmetric NAT - i.e., it will work just fine for client/server > traffic but will suck in the usual way for peer-to-peer traffic. A frugal NAT like you describe could support 2^(16+32+16) session for each internal IP. A port restricted NAT can also do 2^(16+32+16) sessions for each internal IP. > > So with all that setup out of the way, here are my questions: > This has been a good example - I hope I have convinced you that it is possible to build a NAT that is simultaneously "port restricted" in the STUN terminology, "frugal" in this terminology and, from a security point of view, only lets exactly the same packets pass that a "symmetric" NAT would have let pass. > (a) Does anyone know if such a thing as a "Frugal Symmetric NAT" actually > exists right now? I know that most existing symmetric NATs are of the > "Wasteful" variety, but I don't know if _all_ of them are. > Yes they exist. (at least if you buy into my port restricted is a form a Frugal NAT) > (b) Do you think it's likely that corporate NAT vendors such as Cisco will > feel increasing pressure to build Frugal Symmetric NATs in the forseeable > future, as a result of the demand for larger NATs that can handle more and > more simultaneous connections with fewer globally routable IP addresses? > (I'm thinking AOL here as an example, which from what I hear runs "the > world's largest NAT" in front of all its customers.) I think the large NATs will feel pressure to support more than 2^16 sessions. There are some big NATs in China for instance. > > (c) Or, do you think the increasing economic/political/whatever pressure to > make NATs more peer-to-peer friendly, in order to support VoIP and networked > games and all that, is in practice going to outweigh the pressure for "port > frugality", ensuring that almost all NATs in the future will be > (port-restricted) cone NATs? > Well, it's not often you get win win - particularly with a NAT involved :-) but I think in this case you can have port-restricted for P2P support and lots of sessions at the same time. > (d) Finally, if there is a substantial amount of real pressure in _both_ > directions (port frugality and P2P friendliness), do you see a possibility > that vendors may start considering even more complex hybrid solutions, say, > which may be able treat certain (P2P) traffic in Cone NAT fashion while > behaving as a Frugal Symmetric NAT for other (client/server) traffic? > I really don't know the answer to this one - NAT vendors have a long history of doing strange and unnatural acts to packets. It's probably a good prediction they will do all sorts of weird things for reasons ranging from good to silly. > I realize that there are no absolutes here - I'm looking for opinions and > industry projections. > > Thanks very much, > Bryan > Hope that helps, Cullen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Jun 10 13:24:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09880 for ; Tue, 10 Jun 2003 13:24:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AHOJM10381 for midcom-archive@odin.ietf.org; Tue, 10 Jun 2003 13:24: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 h5AHMuB10334; Tue, 10 Jun 2003 13:23: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 h5AHLVB10283 for ; Tue, 10 Jun 2003 13:21:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09804 for ; Tue, 10 Jun 2003 13:21:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PmmK-0000hx-00 for midcom@ietf.org; Tue, 10 Jun 2003 13:19:24 -0400 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 19PmmJ-0000hi-00 for midcom@ietf.org; Tue, 10 Jun 2003 13:19:23 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Date: Tue, 10 Jun 2003 10:20:54 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: Thread-Topic: I-D ACTION:draft-takeda-symmetric-nat-traversal-00.txt Thread-Index: AcMvdKVCkAA75wPcSuuuhyfTKXgyAA== From: "Yutaka Takeda" To: Content-Transfer-Encoding: 7bit Subject: [midcom] I-D ACTION:draft-takeda-symmetric-nat-traversal-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: , Content-Transfer-Encoding: 7bit Please let me draw your attention to a new ietf draft that is posted on-line yesterday assuming that the previous I-D ACTION announcement was meant to be this one(?). Thanks, Yutaka -- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Symmetric NAT Traversal using STUN Author(s) : Y. Takeda Filename : draft-takeda-symmetric-nat-traversal-00.txt Pages : 24 Date : 2003-6-6 It is generally known that the binding acquisition for symmetric NATs with STUN (Simple Traversal of UDP through NATs) protocol will not yield a usable address for traversing symmetric NAT. The use of symmetric RTP allows you to accompolish symmetric NAT traversal only in situations where the other end is open to the Internet, or has a full-cone or a restricted-cone NAT. This document proposes an analytical method for symmetric NATs to obtain more detailed characteristics of the symmetric NAT using STUN, and describes how we can establish a peer-to-peer UDP connection even in situations where NATs (including symmetric NATs) are present at both ends. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-takeda-symmetric-nat-traversal-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-takeda-symmetric-nat-traversal-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-takeda-symmetric-nat-traversal-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. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Jun 12 13:26:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19772 for ; Thu, 12 Jun 2003 13:26:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CHQ9Z09262 for midcom-archive@odin.ietf.org; Thu, 12 Jun 2003 13:26: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 h5CHOpm09191; Thu, 12 Jun 2003 13:24: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 h5CGlTm06297 for ; Thu, 12 Jun 2003 12:47:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18261 for ; Thu, 12 Jun 2003 12:47:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QVCS-00046u-00 for midcom@ietf.org; Thu, 12 Jun 2003 12:45:20 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QVCR-000468-00 for midcom@ietf.org; Thu, 12 Jun 2003 12:45:20 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5CGktVI006459 for ; Thu, 12 Jun 2003 18:46:56 +0200 (CEST) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CB2BAACB76 for ; Thu, 12 Jun 2003 18:33:34 +0200 (CEST) Date: Thu, 12 Jun 2003 18:49:11 +0200 From: Juergen Quittek To: midcom@ietf.org Subject: Re: [midcom] multiple agents accessing the same policy rule Message-ID: <27529795.1055443750@[10.1.1.128]> In-Reply-To: <8753116.1053431158@[10.1.1.128]> References: <8753116.1053431158@[10.1.1.128]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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, Martin and I found a better solution to the problem. Please find it explained below. -- Juergen Quittek wrote on 20 May 2003 11:45 +0200: > Dear all, > > After working again on the semantics for some days, > I ran into a potential problem related to the point that > multiple agents may access the same policy rule on a middlebox. > > An example scenario contains a 'regular' agent authorized > to access just the policies rules created by itself and an > 'administrator' agent authorized to access all policies > created by any agent. > > Another exampe contains be a 'regular' agent and a 'fail-over' > agent running stand-by until the regular one fails. > > In both scenarios (and several others) it is possible that at a > time two or more agents have an open session with the middlebox > and there is a set of policy rules that both may access. > > Let's now assume that an agent deletes a policy rule that is > also accessible to another agent with an open session. The agent > deleting the policy rule sends a request for deletion and gets > a successful reply. What happens with the other agent? > > I think that according to requirement 2.1.5 (known and stable > state) the middlebox must send an ARD (Asynchronous Rule Deletion) > notification to the other agent in order to tell it that one of > the policies it can access was terminated. > > IS THIS AGREED BY THE WORKING GROUP? > > Consequences would be that: > > 1. Everytime a policy rule is terminated, each agent with open > sessions that can access this policy need to receive an > individual notification about this event. > > 2. Not just termiation of policy rules, but also creation and > modification need to be reported to all these agents. > Besides our ARD notification we would have to add one or > more notifications to the semantics covering at least > policy rule creation and lifetime change. > > If we agree on this, here are suggestion for modifying the > semantics: > > - Replace the Asynchronous Policy Rule Deletion (ARD) > transaction (that so far just indicated policy rule > termination) by a more general Asynchronous Policy Rule > Lifetime Event (ALE) notification that notifies the > agent about > - policy rule lifetime changes initiatd by other agents, > indicating the new remaining lifetime, > - policy rule termination by other agents, indicating a > new remaining lifetime of zero, > - policy rule termination by the middlebox, indicating a > new remaining lifetime of zero, > - regular policy rule termination by lifetime expiration, > indicating the remaining lifetime of zero, There is not need to change the set of transactions. What is just missing are further notification MESSAGES. We started to more clearly separate the concepts of message and transaction. When a new policy rule is created or when a policy rule lifetime is changed, then all we have to do is extending the transaction by optional notification messages that are sent to agents who are affected by the change (they can access the created/modified policy rule) but that are not the requesting agent. This applies to the PRR, PER, PLC and GLC transaction. PRR = policy reserve rule PER = policy enable rule PLC = policy rule lifetime change GLC = policy rule group lifetime change For asynchronous events, such as Asynchronous Session Termination (AST) and Asynchronous Policy Rule Deletion (ARD), there is no requesting agent anyway. For session termination, there is only one agent affected and there is no change required. For policy rule termination. We intend to change the semantics for the transactions slightly in a way that the middlebox checks for the list of agents that can access the affected policy rule and sends a notification to each of them. In order to realize this, we want to define three notification message formats: - session termination notification (so far called AST notification) sent in case of an AST transaction only - policy rule event notification This message carries a notification identifier, a policy rule identifier and the remaining policy rule lifetime. It is optionally sent within the PRR, PER, PLC, and ARD transaction - policy rule group event notification This message is similar to the previous one. Instead of a policy rule identifier, it contains a group identifier. It is optionally sent by the GLC transaction. Any further suggestions? Juergen > - Add a new Asynchronous Policy Rule Creation (APC) transaction > that indicates the new policy with all its properties to all > agents in open sessions that did not create the policy rule > but that can access it. > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Jun 14 02:26:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19653 for ; Sat, 14 Jun 2003 02:26:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E6Ptp07436 for midcom-archive@odin.ietf.org; Sat, 14 Jun 2003 02:25:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E1u1a10847; Fri, 13 Jun 2003 21:56:01 -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 h5E1tCm10806 for ; Fri, 13 Jun 2003 21:55:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01895 for ; Fri, 13 Jun 2003 21:55:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R0E0-0003Bg-00 for midcom@ietf.org; Fri, 13 Jun 2003 21:53:00 -0400 Received: from pop016pub.verizon.net ([206.46.170.173] helo=pop016.verizon.net) by ietf-mx with esmtp (Exim 4.12) id 19R0E0-0003BX-00 for midcom@ietf.org; Fri, 13 Jun 2003 21:53:00 -0400 Received: from [192.168.1.100] ([151.199.29.196]) by pop016.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030614015439.OOLZ3199.pop016.verizon.net@[192.168.1.100]>; Fri, 13 Jun 2003 20:54:39 -0500 From: Bryan Ford Organization: Massachusetts Institute of Technology To: Cullen Jennings , Midcom Subject: Re: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg Date: Fri, 13 Jun 2003 21:54:37 -0400 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306132154.38024.baford@mit.edu> X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [151.199.29.196] at Fri, 13 Jun 2003 20:54:38 -0500 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 Cullen, > > - "Cone NAT": usual definition - allocates a public NAT port number for a > > (private IP, private port) pair when the first outgoing session is > > established from that (private IP, private port) pair; reuses that > > public/private mapping in future sessions that may involve different > > external hosts and/or ports. > > > > - "Wasteful Symmetric NAT": the typical kind of symmetric NAT - allocates > > a public NAT port each time a new outgoing session is initiated; each > > public NAT port remains allocated until that session terminates or times > > out and cannot be allocated concurrently to any other session during that > > time. > > It's worth noting that when a packet arrives on the external port, the NAT > can figure where to send it on the inside by just looking at the port it > arrived on. The NAT still needs to keep the full session mapping to decide > if it should forward the packet at all - so the size of the state stored in > memory between this NAT and your frugal NAT is going to be similar. True. > > - "Frugal Symmetric NAT": assigns a new NAT port to each new outgoing > > session initiated from within the firewall... BUT... allocation is not > > done on a basis of "whole" port numbers at all but on "session > > identifiers", which include all the details of the session (private > > IP/port, nat IP/port, external IP/port). Therefore, a given public NAT > > port can actually be reused concurrently by multiple simultaneous > > (perhaps completely unrelated) sessions, as long as each session remains > > uniquely distinguishable on both sides of the NAT. > > Yes, this is a good idea and some NATs do this today. However, the details > are still in how they pick the NAT port. One way would be to use random > ports as you suggest below. > > Another way would be to attempt to use the same external port for all > sessions that have the same internal IP and internal port. That's just the same as "Cone NAT" as I described it above, right? If so... > Because each > internal IP can only have 2^16 ports, the fact that the NAT has 2^16 > external ports make for a nice mapping that the there will be enough ports > on the NAT for it to assign a unique external port for each session that > has a unique internal IP and internal port regardless of the number of > internal IPs. [and from later in your message...] > A frugal NAT like you describe could support 2^(16+32+16) session for each > internal IP. A port restricted NAT can also do 2^(16+32+16) sessions for > each internal IP. I don't quite understand what you're saying here. You seem to be saying that Cone NAT (or "port restricted NAT") is just as "frugal" with port space as the "Frugal Symmetric NAT" that I suggested, but I don't believe it is. (Though I really wish it was; then there'd be no question about what the "best" behavior is!) You are correct that a [port restricted] cone NAT can do 2^(16+32+16) sessions for a given internal IP, _but only ignoring the effects of interference with other internal hosts_. The potential for interference is much worse with cone NAT than with the frugal symmetric NAT that I suggested. When the first session from a given (internal IP, internal port) first causes a cone NAT to allocate a NAT port and establish a translation, the cone NAT _MUST_ reserve that port exclusively for the use of that particular (internal IP, internal port) endpoint. The NAT does not know what other external endpoints that internal endpoint will subsequently be used to communicate with in the future, and since the NAT has committed "a priori" to use the same NAT port for all sessions involving that internal endpoint, it must reserve that NAT port "up front" for all possible (external IP, external port) combinations. The upshot is that while a cone NAT can indeed do 2^(16+32+16) sessions for a given internal IP - or 2^(32+16) sessions for a given internal endpoint (IP/port pair) - the cone NAT is limited to servicing at most 2^16 distinct internal endpoints at once (i.e., 2^16 distinct mappings from internal IP/port to NAT port), while the "frugal symmetric NAT" I suggested has no such limitation. For a simple pathological-case example (but not a terribly unrealistic one), say there are a whole bunch of internal hosts iA, iB, iC, etc., behind the same cone NAT, and each internal host wants to communicate with a different external host xA, xB, xC, etc., respectively. Even if each internal host only initiates communication through the firewall from a single (internal) port at that host, a cone NAT (or a wasteful symmetric NAT) will run out of ports after at most 2^16 internal hosts have initiated sessions (overlapping in time) to their corresponding external hosts, because all the NAT's ports will have been allocated by then. The frugal symmetric NAT, in contrast, can re-use a single NAT port for multiple unrelated sessions from distinct internal endpoints - in this pathological case, for example, only a _single_ NAT port is theoretically needed for all of the sessions iA <-> xA, iB <-> xB, iC <-> xC, and so on. Of course, if many internal hosts try to open simultaneous sessions to the _same_ external endpoint (e.g., port 80 at a very popular web server), even the frugal symmetric NAT will be limited to 2^16 simultaneous active sessions to _that_ particular external endpoint. No getting around that as far as I can tell. But 2^16 simultaneous sessions to a single external endpoint is much less limiting than 2^16 simultanous internal/external translations total (for cone NAT), or worse, 2^16 simultaneous _sessions_ total (for wasteful symmetric NAT). > The terminology of "port restricted" in STUN was a little confusing because > many of the NAT people consider this still to be a form of "symmetric" - > the NAT folks mostly seem to define "symmetric" as you can only receive a > packet from public IP/port if you have sent to that IP/port on the same > protocol. Anyways, it is just a label defining a term so it's not worth > worrying about but it is worth nothing that the STUN definition of > "symmetric" might not line up exactly with some others. I'll keep that in mind. The way I understand it, the term "cone NAT" refers specifically to the NAT port allocation/mapping establishment behavior (i.e., re-using a single NAT port for all sessions originating at a single internal endpoint). The terms "unrestricted", "restricted", and "port restricted", in contrast, seem to refer to the middlebox's policy on allowing "apparently unsolicited" incoming traffic to initiate new sessions - these terms might theoretically be just as applicable to non-NAT firewalls as to full-fledged NATs. Though of course any remotely decent firewall will no doubt implement a "port restricted" policy towards incoming traffic by default. > This has been a good example - I hope I have convinced you that it is > possible to build a NAT that is simultaneously "port restricted" in the > STUN terminology, "frugal" in this terminology and, from a security point > of view, only lets exactly the same packets pass that a "symmetric" NAT > would have let pass. I'm not convinced yet, but maybe I misunderstood your argument...? > > (b) Do you think it's likely that corporate NAT vendors such as Cisco > > will feel increasing pressure to build Frugal Symmetric NATs in the > > forseeable future, as a result of the demand for larger NATs that can > > handle more and more simultaneous connections with fewer globally > > routable IP addresses? (I'm thinking AOL here as an example, which from > > what I hear runs "the world's largest NAT" in front of all its > > customers.) > > I think the large NATs will feel pressure to support more than 2^16 > sessions. There are some big NATs in China for instance. That's exactly the kind of thing I'm wondering about. And to me it seems likely that in the common case, most of the internal hosts behind these NATs will be web browsers - each initiating HTTP-over-TCP sessions from many different client-side port numbers to port 80 at many different external servers, rendering the "NAT port frugality" benefits of cone NAT mostly useless. Cone NAT only saves NAT ports over wasteful symmetric NAT if the internal hosts initiate multiple sessions from the same internal IP/port pair (which the cone NAT aggregates onto a single internal/external translation), and that is unlikely to happen much when the internal hosts are ordinary TCP clients initiating outgoing sessions via connect() without an explicit bind(), and letting the OS assign a new client-side port number to each one. Either a wasteful symmetric NAT _or_ a cone NAT will run out of steam at around 2^16 total simultaneous internal clients at best, and probably a lot less because each client will often be opening sessions from several different internal ports to several different external servers in relatively quick succession, during the course of ordinary web surfing. Only a true "frugal symmetric NAT", which can re-use a single NAT port for multiple simultaneous unrelated sessions from _different_ internal endpoints, will really be able to get around this problem and handle more than 2^16 distinct internal clients simultaneously. Anyway, let me know if I misunderstood your argument. Thanks again for your response, and I look forward to hearing from you again. Cheers, Bryan _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sun Jun 15 05:27:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26927 for ; Sun, 15 Jun 2003 05:27:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5F9RUR18915 for midcom-archive@odin.ietf.org; Sun, 15 Jun 2003 05:27: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 h5F6k1a05671; Sun, 15 Jun 2003 02:46:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F6jgm05659 for ; Sun, 15 Jun 2003 02:45:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24732 for ; Sun, 15 Jun 2003 02:45:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RREd-0002Eh-00 for midcom@ietf.org; Sun, 15 Jun 2003 02:43:27 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 19RREc-0002Ee-00 for midcom@ietf.org; Sun, 15 Jun 2003 02:43:26 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Sat, 14 Jun 2003 23:45:08 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sat, 14 Jun 2003 23:45:07 -0700 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 14 Jun 2003 23:45:07 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Jun 2003 23:45:07 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Jun 2003 23:45:06 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Sat, 14 Jun 2003 23:45:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg Date: Sat, 14 Jun 2003 23:42:59 -0700 Message-ID: Thread-Topic: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg Thread-Index: AcMyPdMV3nIaPMd/R6CAxBydw5d0dwAy4k1+ From: "Christian Huitema" To: "Bryan Ford" , "Cullen Jennings" , "Midcom" X-OriginalArrivalTime: 15 Jun 2003 06:45:06.0297 (UTC) FILETIME=[A8029690:01C33309] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5F6jgm05660 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 > That's exactly the kind of thing I'm wondering about. And to me it seems > likely that in the common case, most of the internal hosts behind these NATs > will be web browsers - each initiating HTTP-over-TCP sessions from many > different client-side port numbers to port 80 at many different external > servers, rendering the "NAT port frugality" benefits of cone NAT mostly > useless. The whole argument is about the handling of UDP, not TCP. Nobody insists for cone behavior in the case of TCP. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sun Jun 15 10:40:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03695 for ; Sun, 15 Jun 2003 10:40:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FEdtV04209 for midcom-archive@odin.ietf.org; Sun, 15 Jun 2003 10:39:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FE22a01161; Sun, 15 Jun 2003 10:02:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FE1um01141 for ; Sun, 15 Jun 2003 10:01:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01851 for ; Sun, 15 Jun 2003 10:01:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RY2n-0003ja-00 for midcom@ietf.org; Sun, 15 Jun 2003 09:59:41 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19RY2m-0003jH-00 for midcom@ietf.org; Sun, 15 Jun 2003 09:59:40 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5FE1Epa007402; Sun, 15 Jun 2003 07:01:15 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIK14523; Sun, 15 Jun 2003 07:01:14 -0700 (PDT) Message-Id: <200306151401.AIK14523@mira-sjc5-c.cisco.com> To: Juergen Quittek cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] multiple agents accessing the same policy rule In-Reply-To: Message from quittek@ccrle.nec.de of "Thu, 12 Jun 2003 18:49:11 +0200." <27529795.1055443750@[10.1.1.128]> Date: Sun, 15 Jun 2003 10:01:13 -0400 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: , The next version of the semantics document is the one that will go into WG last call. Is there any objection to Juergen's proposal: > In order to realize this, we want to define three notification > message formats: > - session termination notification (so far called AST notification) > sent in case of an AST transaction only > - policy rule event notification > This message carries a notification identifier, a policy rule > identifier and the remaining policy rule lifetime. It is > optionally sent within the PRR, PER, PLC, and ARD transaction > - policy rule group event notification > This message is similar to the previous one. Instead of a > policy rule identifier, it contains a group identifier. > It is optionally sent by the GLC transaction. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sun Jun 15 13:37:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06266 for ; Sun, 15 Jun 2003 13:37:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FHbKB13486 for midcom-archive@odin.ietf.org; Sun, 15 Jun 2003 13:37: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 h5FGM1a09369; Sun, 15 Jun 2003 12:22:01 -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 h5FGLBm09349 for ; Sun, 15 Jun 2003 12:21:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05267 for ; Sun, 15 Jun 2003 12:21:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RaDY-0004Cr-00 for midcom@ietf.org; Sun, 15 Jun 2003 12:18:56 -0400 Received: from out003pub.verizon.net ([206.46.170.103] helo=out003.verizon.net) by ietf-mx with esmtp (Exim 4.12) id 19RaDX-0004Cc-00 for midcom@ietf.org; Sun, 15 Jun 2003 12:18:56 -0400 Received: from [192.168.1.100] ([151.199.29.196]) by out003.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030615162038.VRAR4805.out003.verizon.net@[192.168.1.100]>; Sun, 15 Jun 2003 11:20:38 -0500 From: Bryan Ford Organization: Massachusetts Institute of Technology To: "Christian Huitema" , "Cullen Jennings" , "Midcom" Subject: Re: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg Date: Sun, 15 Jun 2003 12:20:37 -0400 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306151220.37657.baford@mit.edu> X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [151.199.29.196] at Sun, 15 Jun 2003 11:20:38 -0500 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 Christian, > The whole argument is about the handling of UDP, not TCP. Nobody insists > for cone behavior in the case of TCP. Excellent point - thanks. Once again I seem to be guilty of forgetting what utterly different beasts TCP and UDP are, particularly in light of the radically different usage models they have evolved historically. Cheers, Bryan _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Jun 16 14:33:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24607 for ; Mon, 16 Jun 2003 14:33:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GIWn824691 for midcom-archive@odin.ietf.org; Mon, 16 Jun 2003 14:32:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GED1a06070; Mon, 16 Jun 2003 10:13:01 -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 h5GECom06050 for ; Mon, 16 Jun 2003 10:12:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15137 for ; Mon, 16 Jun 2003 10:12:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rugr-0002rr-00 for midcom@ietf.org; Mon, 16 Jun 2003 10:10:33 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19Rugq-0002rk-00 for midcom@ietf.org; Mon, 16 Jun 2003 10:10:32 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5GECETr013297 for ; Mon, 16 Jun 2003 07:12:14 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIK59354; Mon, 16 Jun 2003 07:12:13 -0700 (PDT) Message-Id: <200306161412.AIK59354@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 16 Jun 2003 10:12:13 -0400 Subject: [midcom] Upcoming meeting 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: , We are currently scheduled to to meet in Vienna on Tuesday from 1415-1515. Also meeting during that time are 1415-1515 Afternoon Sessions II APP ldapbis LDAP (v3) Revision WG APP trade Internet Open Trading Protocol WG INT l2tpext Layer Two Tunneling Protocol Extensions WG INT magma Multicast & Anycast Group Membership WG OPS bmwg Benchmarking Methodology WG RTG ospf Open Shortest Path First IGP WG TSV midcom Middlebox Communication WG On the agenda are the state of the MIB, and possibly the semantics document (although I'd really like to get that into WG last call before the meeting). Please let me know if there's anything else, but note, as always, that the meeting time is to be used for discussion of open issues rather than presentation of new material. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Jun 17 01:21:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17334 for ; Tue, 17 Jun 2003 01:21:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H5LCc07514 for midcom-archive@odin.ietf.org; Tue, 17 Jun 2003 01:21: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 h5GGf1a17424; Mon, 16 Jun 2003 12:41:01 -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 h5GGeMm17394 for ; Mon, 16 Jun 2003 12:40:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20182 for ; Mon, 16 Jun 2003 12:40:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rwze-0003t0-00 for midcom@ietf.org; Mon, 16 Jun 2003 12:38:06 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19Rwzd-0003sq-00 for midcom@ietf.org; Mon, 16 Jun 2003 12:38:05 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5GGdkVI066289; Mon, 16 Jun 2003 18:39:46 +0200 (CEST) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A1A0DAD1FB; Mon, 16 Jun 2003 18:25:46 +0200 (CEST) Date: Mon, 16 Jun 2003 18:42:04 +0200 From: Juergen Quittek To: Tom Taylor Cc: midcom@ietf.org Subject: Re: [midcom] multiple agents accessing the same policy rule Message-ID: <36509698.1055788924@[10.1.1.128]> In-Reply-To: <3EEDE9EC.5070309@nortelnetworks.com> References: <3EEDE9EC.5070309@nortelnetworks.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, -- Tom Taylor wrote on 16 June 2003 12:01 -0400: > The requirement for this is what I meant by "consequential messaging" > in my earlier review of the document. The solution looks OK, except > that protocol terminology crept in slightly in your explanation. > We are interested in message content, not message format. Yep, you are right. We should replace the term. Would you consider message type a better term? Juergen > > Juergen Quittek wrote: > >> Dear all, >> >> Martin and I found a better solution to the problem. >> Please find it explained below. >> >> -- Juergen Quittek wrote on 20 May 2003 11:45 +0200: >> >>> Dear all, >>> >>> After working again on the semantics for some days, >>> I ran into a potential problem related to the point that >>> multiple agents may access the same policy rule on a middlebox. >>> >>> An example scenario contains a 'regular' agent authorized >>> to access just the policies rules created by itself and an >>> 'administrator' agent authorized to access all policies >>> created by any agent. >>> >>> Another exampe contains be a 'regular' agent and a 'fail-over' >>> agent running stand-by until the regular one fails. >>> >>> In both scenarios (and several others) it is possible that at a >>> time two or more agents have an open session with the middlebox >>> and there is a set of policy rules that both may access. >>> >>> Let's now assume that an agent deletes a policy rule that is >>> also accessible to another agent with an open session. The agent >>> deleting the policy rule sends a request for deletion and gets >>> a successful reply. What happens with the other agent? >>> >>> I think that according to requirement 2.1.5 (known and stable >>> state) the middlebox must send an ARD (Asynchronous Rule Deletion) >>> notification to the other agent in order to tell it that one of >>> the policies it can access was terminated. >>> >>> IS THIS AGREED BY THE WORKING GROUP? >>> >>> Consequences would be that: >>> >>> 1. Everytime a policy rule is terminated, each agent with open >>> sessions that can access this policy need to receive an >>> individual notification about this event. >>> >>> 2. Not just termiation of policy rules, but also creation and >>> modification need to be reported to all these agents. >>> Besides our ARD notification we would have to add one or >>> more notifications to the semantics covering at least >>> policy rule creation and lifetime change. >>> >>> If we agree on this, here are suggestion for modifying the >>> semantics: >>> >>> - Replace the Asynchronous Policy Rule Deletion (ARD) >>> transaction (that so far just indicated policy rule >>> termination) by a more general Asynchronous Policy Rule >>> Lifetime Event (ALE) notification that notifies the >>> agent about >>> - policy rule lifetime changes initiatd by other agents, >>> indicating the new remaining lifetime, >>> - policy rule termination by other agents, indicating a >>> new remaining lifetime of zero, >>> - policy rule termination by the middlebox, indicating a >>> new remaining lifetime of zero, >>> - regular policy rule termination by lifetime expiration, >>> indicating the remaining lifetime of zero, >> >> >> There is not need to change the set of transactions. What is just >> missing are further notification MESSAGES. We started to more >> clearly separate the concepts of message and transaction. >> >> When a new policy rule is created or when a policy rule lifetime is >> changed, then all we have to do is extending the transaction by >> optional notification messages that are sent to agents who are >> affected by the change (they can access the created/modified policy >> rule) but that are not the requesting agent. >> >> This applies to the PRR, PER, PLC and GLC transaction. >> PRR = policy reserve rule >> PER = policy enable rule >> PLC = policy rule lifetime change >> GLC = policy rule group lifetime change >> >> For asynchronous events, such as Asynchronous Session Termination >> (AST) and Asynchronous Policy Rule Deletion (ARD), >> there is no requesting agent anyway. For session termination, there >> is only one agent affected and there is no change required. For >> policy rule termination. We intend to change the semantics for the >> transactions slightly in a way that the middlebox checks for the >> list of agents that can access the affected policy rule and sends >> a notification to each of them. >> >> In order to realize this, we want to define three notification >> message formats: >> - session termination notification (so far called AST notification) >> sent in case of an AST transaction only >> - policy rule event notification >> This message carries a notification identifier, a policy rule >> identifier and the remaining policy rule lifetime. It is >> optionally sent within the PRR, PER, PLC, and ARD transaction >> - policy rule group event notification >> This message is similar to the previous one. Instead of a >> policy rule identifier, it contains a group identifier. >> It is optionally sent by the GLC transaction. >> >> Any further suggestions? >> >> Juergen >> >> >> >>> - Add a new Asynchronous Policy Rule Creation (APC) transaction >>> that indicates the new policy with all its properties to all >>> agents in open sessions that did not create the policy rule >>> but that can access it. >> >> >> >>> >>> Juergen >>> -- >>> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >>> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany >>> http://www.ccrle.nec.de >>> _______________________________________________ >>> midcom mailing list >>> midcom@ietf.org >>> https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> _______________________________________________ >> 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 Jun 17 01:24:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17409 for ; Tue, 17 Jun 2003 01:24:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H5NoM07639 for midcom-archive@odin.ietf.org; Tue, 17 Jun 2003 01:23: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 h5GG32a14105; Mon, 16 Jun 2003 12:03:02 -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 h5GG2am14083 for ; Mon, 16 Jun 2003 12:02:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18874 for ; Mon, 16 Jun 2003 12:02:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RwP6-0003Xb-00 for midcom@ietf.org; Mon, 16 Jun 2003 12:00:20 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19RwP5-0003XM-00 for midcom@ietf.org; Mon, 16 Jun 2003 12:00:19 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GG1rT16433; Mon, 16 Jun 2003 12:01:53 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAMN0YVG; Mon, 16 Jun 2003 12:01:54 -0400 Received: from nortelnetworks.com (acart1bd.ca.nortel.com [47.129.129.23]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA04F7; Mon, 16 Jun 2003 12:01:53 -0400 Message-ID: <3EEDE9EC.5070309@nortelnetworks.com> Date: Mon, 16 Jun 2003 12:01:48 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Juergen Quittek CC: midcom@ietf.org Subject: Re: [midcom] multiple agents accessing the same policy rule References: <8753116.1053431158@[10.1.1.128]> <27529795.1055443750@[10.1.1.128]> In-Reply-To: <27529795.1055443750@[10.1.1.128]> 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 The requirement for this is what I meant by "consequential messaging" in my earlier review of the document. The solution looks OK, except that protocol terminology crept in slightly in your explanation. We are interested in message content, not message format. Juergen Quittek wrote: > Dear all, > > Martin and I found a better solution to the problem. > Please find it explained below. > > -- Juergen Quittek wrote on 20 May 2003 11:45 +0200: > >> Dear all, >> >> After working again on the semantics for some days, >> I ran into a potential problem related to the point that >> multiple agents may access the same policy rule on a middlebox. >> >> An example scenario contains a 'regular' agent authorized >> to access just the policies rules created by itself and an >> 'administrator' agent authorized to access all policies >> created by any agent. >> >> Another exampe contains be a 'regular' agent and a 'fail-over' >> agent running stand-by until the regular one fails. >> >> In both scenarios (and several others) it is possible that at a >> time two or more agents have an open session with the middlebox >> and there is a set of policy rules that both may access. >> >> Let's now assume that an agent deletes a policy rule that is >> also accessible to another agent with an open session. The agent >> deleting the policy rule sends a request for deletion and gets >> a successful reply. What happens with the other agent? >> >> I think that according to requirement 2.1.5 (known and stable >> state) the middlebox must send an ARD (Asynchronous Rule Deletion) >> notification to the other agent in order to tell it that one of >> the policies it can access was terminated. >> >> IS THIS AGREED BY THE WORKING GROUP? >> >> Consequences would be that: >> >> 1. Everytime a policy rule is terminated, each agent with open >> sessions that can access this policy need to receive an >> individual notification about this event. >> >> 2. Not just termiation of policy rules, but also creation and >> modification need to be reported to all these agents. >> Besides our ARD notification we would have to add one or >> more notifications to the semantics covering at least >> policy rule creation and lifetime change. >> >> If we agree on this, here are suggestion for modifying the >> semantics: >> >> - Replace the Asynchronous Policy Rule Deletion (ARD) >> transaction (that so far just indicated policy rule >> termination) by a more general Asynchronous Policy Rule >> Lifetime Event (ALE) notification that notifies the >> agent about >> - policy rule lifetime changes initiatd by other agents, >> indicating the new remaining lifetime, >> - policy rule termination by other agents, indicating a >> new remaining lifetime of zero, >> - policy rule termination by the middlebox, indicating a >> new remaining lifetime of zero, >> - regular policy rule termination by lifetime expiration, >> indicating the remaining lifetime of zero, > > > There is not need to change the set of transactions. What is just > missing are further notification MESSAGES. We started to more > clearly separate the concepts of message and transaction. > > When a new policy rule is created or when a policy rule lifetime is > changed, then all we have to do is extending the transaction by > optional notification messages that are sent to agents who are > affected by the change (they can access the created/modified policy > rule) but that are not the requesting agent. > > This applies to the PRR, PER, PLC and GLC transaction. > PRR = policy reserve rule > PER = policy enable rule > PLC = policy rule lifetime change > GLC = policy rule group lifetime change > > For asynchronous events, such as Asynchronous Session Termination > (AST) and Asynchronous Policy Rule Deletion (ARD), > there is no requesting agent anyway. For session termination, there > is only one agent affected and there is no change required. For > policy rule termination. We intend to change the semantics for the > transactions slightly in a way that the middlebox checks for the > list of agents that can access the affected policy rule and sends > a notification to each of them. > > In order to realize this, we want to define three notification > message formats: > - session termination notification (so far called AST notification) > sent in case of an AST transaction only > - policy rule event notification > This message carries a notification identifier, a policy rule > identifier and the remaining policy rule lifetime. It is > optionally sent within the PRR, PER, PLC, and ARD transaction > - policy rule group event notification > This message is similar to the previous one. Instead of a > policy rule identifier, it contains a group identifier. > It is optionally sent by the GLC transaction. > > Any further suggestions? > > Juergen > > > >> - Add a new Asynchronous Policy Rule Creation (APC) transaction >> that indicates the new policy with all its properties to all >> agents in open sessions that did not create the policy rule >> but that can access it. > > > >> >> Juergen >> -- >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany >> http://www.ccrle.nec.de >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > 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 Jun 17 13:52:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28150 for ; Tue, 17 Jun 2003 13:52:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HHptx04910 for midcom-archive@odin.ietf.org; Tue, 17 Jun 2003 13:51:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDM1a27727; Tue, 17 Jun 2003 09:22:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDL9m27704 for ; Tue, 17 Jun 2003 09:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13778 for ; Tue, 17 Jun 2003 09:21:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SGMM-0006dQ-00 for midcom@ietf.org; Tue, 17 Jun 2003 09:18:50 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19SGML-0006bl-00 for midcom@ietf.org; Tue, 17 Jun 2003 09:18:49 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5HDKJw03342; Tue, 17 Jun 2003 09:20:20 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M7BYHVR9; Tue, 17 Jun 2003 09:20:20 -0400 Received: from nortelnetworks.com (acart1ed.ca.nortel.com [47.129.129.122]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NDJAJHA3; Tue, 17 Jun 2003 09:20:19 -0400 Message-ID: <3EEF1592.7020909@nortelnetworks.com> Date: Tue, 17 Jun 2003 09:20:18 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Juergen Quittek CC: midcom@ietf.org Subject: Re: [midcom] multiple agents accessing the same policy rule References: <3EEDE9EC.5070309@nortelnetworks.com> <36509698.1055788924@[10.1.1.128]> In-Reply-To: <36509698.1055788924@[10.1.1.128]> 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 Yes, that seems appropriate. Juergen Quittek wrote: > Tom, > > -- Tom Taylor wrote on 16 June 2003 12:01 -0400: > >> The requirement for this is what I meant by "consequential messaging" >> in my earlier review of the document. The solution looks OK, except >> that protocol terminology crept in slightly in your explanation. >> We are interested in message content, not message format. > > > Yep, you are right. We should replace the term. > Would you consider message type a better term? > > Juergen > >> [snip] >>> >>> In order to realize this, we want to define three notification >>> message formats: >>> - session termination notification (so far called AST notification) >>> sent in case of an AST transaction only >>> - policy rule event notification >>> This message carries a notification identifier, a policy rule >>> identifier and the remaining policy rule lifetime. It is >>> optionally sent within the PRR, PER, PLC, and ARD transaction >>> - policy rule group event notification >>> This message is similar to the previous one. Instead of a >>> policy rule identifier, it contains a group identifier. >>> It is optionally sent by the GLC transaction. >>> > [snip] _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Jun 17 14:51:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02616 for ; Tue, 17 Jun 2003 14:51:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIpOS23949 for midcom-archive@odin.ietf.org; Tue, 17 Jun 2003 14:51:24 -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 h5HEE1a31823; Tue, 17 Jun 2003 10:14:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEDem31791 for ; Tue, 17 Jun 2003 10:13:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17873 for ; Tue, 17 Jun 2003 10:13:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHBB-0007VV-00 for midcom@ietf.org; Tue, 17 Jun 2003 10:11:21 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19SHBB-0007VH-00 for midcom@ietf.org; Tue, 17 Jun 2003 10:11:21 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5HED2Tc023525; Tue, 17 Jun 2003 07:13:06 -0700 (PDT) Received: from [128.107.171.175] ([128.107.171.175]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFD65058; Tue, 17 Jun 2003 07:13:01 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 16 Jun 2003 23:11:18 -0700 Subject: Re: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg From: Cullen Jennings To: Bryan Ford , Midcom Message-ID: In-Reply-To: <200306132154.38024.baford@mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sorry for the short answer here but I think we are thinking different things on port restricted and cone. When traffic arrives on port 5000 on the outside of the NAT there are two things that can happen - On a cone, it always gets sent to the same host on the inside and there is only one mapping for this port. On a restricted there is a separate mapping for every possible location it can arrive from and depending on where it came from, it can get sent to different hosts on the inside of the NAT. The argument I was making does not work with a cone NAT - it requires that a separate mapping per destination address/port is kept in the NAT. Hope that helps clarify, Cullen On 6/13/03 6:54 PM, "Bryan Ford" wrote: > Hi Cullen, > >>> - "Cone NAT": usual definition - allocates a public NAT port number for a >>> (private IP, private port) pair when the first outgoing session is >>> established from that (private IP, private port) pair; reuses that >>> public/private mapping in future sessions that may involve different >>> external hosts and/or ports. >>> >>> - "Wasteful Symmetric NAT": the typical kind of symmetric NAT - allocates >>> a public NAT port each time a new outgoing session is initiated; each >>> public NAT port remains allocated until that session terminates or times >>> out and cannot be allocated concurrently to any other session during that >>> time. >> >> It's worth noting that when a packet arrives on the external port, the NAT >> can figure where to send it on the inside by just looking at the port it >> arrived on. The NAT still needs to keep the full session mapping to decide >> if it should forward the packet at all - so the size of the state stored in >> memory between this NAT and your frugal NAT is going to be similar. > > True. > >>> - "Frugal Symmetric NAT": assigns a new NAT port to each new outgoing >>> session initiated from within the firewall... BUT... allocation is not >>> done on a basis of "whole" port numbers at all but on "session >>> identifiers", which include all the details of the session (private >>> IP/port, nat IP/port, external IP/port). Therefore, a given public NAT >>> port can actually be reused concurrently by multiple simultaneous >>> (perhaps completely unrelated) sessions, as long as each session remains >>> uniquely distinguishable on both sides of the NAT. >> >> Yes, this is a good idea and some NATs do this today. However, the details >> are still in how they pick the NAT port. One way would be to use random >> ports as you suggest below. >> >> Another way would be to attempt to use the same external port for all >> sessions that have the same internal IP and internal port. > > That's just the same as "Cone NAT" as I described it above, right? If so... > >> Because each >> internal IP can only have 2^16 ports, the fact that the NAT has 2^16 >> external ports make for a nice mapping that the there will be enough ports >> on the NAT for it to assign a unique external port for each session that >> has a unique internal IP and internal port regardless of the number of >> internal IPs. > [and from later in your message...] >> A frugal NAT like you describe could support 2^(16+32+16) session for each >> internal IP. A port restricted NAT can also do 2^(16+32+16) sessions for >> each internal IP. > > I don't quite understand what you're saying here. You seem to be saying that > Cone NAT (or "port restricted NAT") is just as "frugal" with port space as > the "Frugal Symmetric NAT" that I suggested, but I don't believe it is. > (Though I really wish it was; then there'd be no question about what the > "best" behavior is!) > > You are correct that a [port restricted] cone NAT can do 2^(16+32+16) sessions > for a given internal IP, _but only ignoring the effects of interference with > other internal hosts_. The potential for interference is much worse with > cone NAT than with the frugal symmetric NAT that I suggested. When the first > session from a given (internal IP, internal port) first causes a cone NAT to > allocate a NAT port and establish a translation, the cone NAT _MUST_ reserve > that port exclusively for the use of that particular (internal IP, internal > port) endpoint. The NAT does not know what other external endpoints that > internal endpoint will subsequently be used to communicate with in the > future, and since the NAT has committed "a priori" to use the same NAT port > for all sessions involving that internal endpoint, it must reserve that NAT > port "up front" for all possible (external IP, external port) combinations. > > The upshot is that while a cone NAT can indeed do 2^(16+32+16) sessions for a > given internal IP - or 2^(32+16) sessions for a given internal endpoint > (IP/port pair) - the cone NAT is limited to servicing at most 2^16 distinct > internal endpoints at once (i.e., 2^16 distinct mappings from internal > IP/port to NAT port), while the "frugal symmetric NAT" I suggested has no > such limitation. > > For a simple pathological-case example (but not a terribly unrealistic one), > say there are a whole bunch of internal hosts iA, iB, iC, etc., behind the > same cone NAT, and each internal host wants to communicate with a different > external host xA, xB, xC, etc., respectively. Even if each internal host > only initiates communication through the firewall from a single (internal) > port at that host, a cone NAT (or a wasteful symmetric NAT) will run out of > ports after at most 2^16 internal hosts have initiated sessions (overlapping > in time) to their corresponding external hosts, because all the NAT's ports > will have been allocated by then. The frugal symmetric NAT, in contrast, can > re-use a single NAT port for multiple unrelated sessions from distinct > internal endpoints - in this pathological case, for example, only a _single_ > NAT port is theoretically needed for all of the sessions iA <-> xA, iB <-> > xB, iC <-> xC, and so on. > > Of course, if many internal hosts try to open simultaneous sessions to the > _same_ external endpoint (e.g., port 80 at a very popular web server), even > the frugal symmetric NAT will be limited to 2^16 simultaneous active sessions > to _that_ particular external endpoint. No getting around that as far as I > can tell. But 2^16 simultaneous sessions to a single external endpoint is > much less limiting than 2^16 simultanous internal/external translations total > (for cone NAT), or worse, 2^16 simultaneous _sessions_ total (for wasteful > symmetric NAT). > >> The terminology of "port restricted" in STUN was a little confusing because >> many of the NAT people consider this still to be a form of "symmetric" - >> the NAT folks mostly seem to define "symmetric" as you can only receive a >> packet from public IP/port if you have sent to that IP/port on the same >> protocol. Anyways, it is just a label defining a term so it's not worth >> worrying about but it is worth nothing that the STUN definition of >> "symmetric" might not line up exactly with some others. > > I'll keep that in mind. The way I understand it, the term "cone NAT" refers > specifically to the NAT port allocation/mapping establishment behavior (i.e., > re-using a single NAT port for all sessions originating at a single internal > endpoint). The terms "unrestricted", "restricted", and "port restricted", in > contrast, seem to refer to the middlebox's policy on allowing "apparently > unsolicited" incoming traffic to initiate new sessions - these terms might > theoretically be just as applicable to non-NAT firewalls as to full-fledged > NATs. Though of course any remotely decent firewall will no doubt implement > a "port restricted" policy towards incoming traffic by default. > >> This has been a good example - I hope I have convinced you that it is >> possible to build a NAT that is simultaneously "port restricted" in the >> STUN terminology, "frugal" in this terminology and, from a security point >> of view, only lets exactly the same packets pass that a "symmetric" NAT >> would have let pass. > > I'm not convinced yet, but maybe I misunderstood your argument...? > >>> (b) Do you think it's likely that corporate NAT vendors such as Cisco >>> will feel increasing pressure to build Frugal Symmetric NATs in the >>> forseeable future, as a result of the demand for larger NATs that can >>> handle more and more simultaneous connections with fewer globally >>> routable IP addresses? (I'm thinking AOL here as an example, which from >>> what I hear runs "the world's largest NAT" in front of all its >>> customers.) >> >> I think the large NATs will feel pressure to support more than 2^16 >> sessions. There are some big NATs in China for instance. > > That's exactly the kind of thing I'm wondering about. And to me it seems > likely that in the common case, most of the internal hosts behind these NATs > will be web browsers - each initiating HTTP-over-TCP sessions from many > different client-side port numbers to port 80 at many different external > servers, rendering the "NAT port frugality" benefits of cone NAT mostly > useless. Cone NAT only saves NAT ports over wasteful symmetric NAT if the > internal hosts initiate multiple sessions from the same internal IP/port pair > (which the cone NAT aggregates onto a single internal/external translation), > and that is unlikely to happen much when the internal hosts are ordinary TCP > clients initiating outgoing sessions via connect() without an explicit > bind(), and letting the OS assign a new client-side port number to each one. > Either a wasteful symmetric NAT _or_ a cone NAT will run out of steam at > around 2^16 total simultaneous internal clients at best, and probably a lot > less because each client will often be opening sessions from several > different internal ports to several different external servers in relatively > quick succession, during the course of ordinary web surfing. Only a true > "frugal symmetric NAT", which can re-use a single NAT port for multiple > simultaneous unrelated sessions from _different_ internal endpoints, will > really be able to get around this problem and handle more than 2^16 distinct > internal clients simultaneously. > > Anyway, let me know if I misunderstood your argument. Thanks again for your > response, and I look forward to hearing from you again. > > Cheers, > Bryan > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Jun 17 15:16:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05341 for ; Tue, 17 Jun 2003 15:16:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJG7A05311 for midcom-archive@odin.ietf.org; Tue, 17 Jun 2003 15:16:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SL05-0003Ua-Oo; Tue, 17 Jun 2003 14:16:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKIF-0000SE-Tz for midcom@optimus.ietf.org; Tue, 17 Jun 2003 13:30:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27528 for ; Tue, 17 Jun 2003 13:30:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKG0-00022n-00 for midcom@ietf.org; Tue, 17 Jun 2003 13:28:32 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19SKG0-00022j-00 for midcom@ietf.org; Tue, 17 Jun 2003 13:28:32 -0400 Received: by fox.iptel.org (Postfix, from userid 534) id D08F5219; Tue, 17 Jun 2003 19:30:13 +0200 (CEST) Received: from jku07.fokus.fraunhofer.de (port-212-202-40-87.reverse.qsc.de [212.202.40.87]) by fox.iptel.org (Postfix) with ESMTP id 11D5D217; Tue, 17 Jun 2003 19:30:13 +0200 (CEST) Message-Id: <5.2.0.9.0.20030617192519.029ef248@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 17 Jun 2003 19:27:51 +0200 To: Cullen Jennings , , Midcom From: Jiri Kuthan Subject: Re: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-24.6 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.51 X-Spam-Checker-Version: SpamAssassin 2.51 (1.174.2.5-2003-03-20-exp) 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: , At 04:00 AM 6/2/2003, Cullen Jennings wrote: >On 5/27/03 2:12 AM, "john Holdsworth" >wrote: > >> The big issue for STUN is that it won't work with most (95%+?) of corporate >> NATs and firewalls which translate ports on a symmetric basis. That is if >> any of the source or destination details change a new NAT mapping is >> employed. This makes STUN useless. >> Also, you may wish to learn that STUN is very useful to detect symmetric NAT. If a phone knows there is such a device in path, it can switch over to active symmetric mode (comedia) to get over it. -Jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Jun 18 07:54:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28470 for ; Wed, 18 Jun 2003 07:54:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IBs2n18628 for midcom-archive@odin.ietf.org; Wed, 18 Jun 2003 07:54:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbVo-0004pu-A9; Wed, 18 Jun 2003 07:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbVg-0004pS-Mn for midcom@optimus.ietf.org; Wed, 18 Jun 2003 07:53:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28302; Wed, 18 Jun 2003 07:53:51 -0400 (EDT) Message-Id: <200306181153.HAA28302@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Jun 2003 07:53:51 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-03.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Protocol Semantics Author(s) : M. Stiemerling Filename : draft-ietf-midcom-semantics-03.txt Pages : 61 Date : 2003-6-17 This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or - more probably - a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-semantics-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-semantics-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17144631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144631.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Jun 18 12:26:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15115 for ; Wed, 18 Jun 2003 12:26:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IGQ4106072 for midcom-archive@odin.ietf.org; Wed, 18 Jun 2003 12:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sf0b-0007pm-5o; Wed, 18 Jun 2003 11:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SebI-0006Pf-Jd for midcom@optimus.ietf.org; Wed, 18 Jun 2003 11:11:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11808 for ; Wed, 18 Jun 2003 11:11:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SeZ1-0005dy-00 for midcom@ietf.org; Wed, 18 Jun 2003 11:09:31 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19SeZ0-0005dP-00 for midcom@ietf.org; Wed, 18 Jun 2003 11:09:30 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5IFBHTa010671 for ; Wed, 18 Jun 2003 08:11:17 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIN24067; Wed, 18 Jun 2003 08:11:16 -0700 (PDT) Message-Id: <200306181511.AIN24067@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Wed, 18 Jun 2003 11:11:16 -0400 Subject: [midcom] WG LAST CALL - semantics document Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The midcom semantics document is now in WG last call. *Please* give it a careful reading and bring any issues you identify to the mailing list. WG last call closes on Thursday, July 3. Thanks, Melinda ------- Forwarded Message Date: Wed, 18 Jun 2003 07:53:51 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: midcom@ietf.org Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-03.txt - --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 I ETF. Title : MIDCOM Protocol Semantics Author(s) : M. Stiemerling Filename : draft-ietf-midcom-semantics-03.txt Pages : 61 Date : 2003-6-17 This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or - more probably - a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-semantics-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-semantics-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17144631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-03.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144631.I-D@ietf.org> - --OtherAccess-- - --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------- End of Forwarded Message _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Jun 19 16:24:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16657 for ; Thu, 19 Jun 2003 16:24:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JKO3R22323 for midcom-archive@odin.ietf.org; Thu, 19 Jun 2003 16:24:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5wv-0005nS-6m; Thu, 19 Jun 2003 16:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sb5h-0003mq-HI for midcom@optimus.ietf.org; Wed, 18 Jun 2003 07:27:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27227; Wed, 18 Jun 2003 07:27:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sb3S-0002Cx-00; Wed, 18 Jun 2003 07:24:42 -0400 Received: from pop.tuwien.ac.at ([128.130.2.60]) by ietf-mx with esmtp (Exim 4.12) id 19Sb3R-0002Cu-00; Wed, 18 Jun 2003 07:24:41 -0400 Received: from Philemon (philemon.ikn.tuwien.ac.at [128.131.88.118]) by pop.tuwien.ac.at (8.12.8/8.12.8) with ESMTP id h5IBQvjw023678; Wed, 18 Jun 2003 13:26:57 +0200 (MEST) Content-Type: text/plain; charset="iso-8859-1" From: Klaus Umschaden Date: Wed, 18 Jun 2003 13:27:15 +0200 User-Agent: KMail/1.4.3 To: midcom@ietf.org, sip@ietf.org MIME-Version: 1.0 Message-Id: <200306181326.15569.Klaus.Umschaden@tuwien.ac.at> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Subject: [midcom] Fwd: I-D ACTION:draft-umschaden-smime-midcom-sip-proxy-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: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA16657 I think that this draft may be of interest for this mailing group. Best regards, Klaus ---------- Forwarded Message ---------- Subject: I-D ACTION:draft-umschaden-smime-midcom-sip-proxy-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : End-to-end Security for Firewall/NAT Traversal within the Session Initiation Protocol (SIP) Author(s) : K. Umschaden et al. Filename : draft-umschaden-smime-midcom-sip-proxy-00.txt Pages : 37 Date : 2003-5-6 This document describes an extension for the Session Initiation Protocol (SIP), which enables end-to-end security of the Session Description Protocol (SDP) together with firewall/Network Address Translation (NAT) traversal. This solution relies on Secure Multipurpose Internet Mail Extension (S/MIME) and the middlebox communications (MIDCOM) protocol. The user authorises a proxy server to encrypt the session description on behalf of the user. The proxy determines the capabilities of the receiving party and encrypts the SDP for a SIP proxy server in the receiving domain. Using MIDCOM, each proxy can dynamically control its firewall to open pinholes or request NAT bindings for the media flows. As long as each end-user may contact its trustworthy SIP proxy via a secure connection and authorise this proxy to encrypt the signalling data, the session information is secured end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-umschaden-smime-midcom-sip-proxy-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-umschaden-smime-midcom-sip-proxy-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-umschaden-smime-midcom-sip-proxy-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. ------------------------------------------------------- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Jun 25 11:35:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15738 for ; Wed, 25 Jun 2003 11:35:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZ8e03922 for midcom-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIb-0000wf-Rv; Wed, 25 Jun 2003 11:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpy-0006YL-Lp for midcom@optimus.ietf.org; Wed, 25 Jun 2003 11:05:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10839 for ; Wed, 25 Jun 2003 10:09:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VAy3-00040z-00 for midcom@ietf.org; Wed, 25 Jun 2003 10:09:47 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19VAxt-00040W-00 for midcom@ietf.org; Wed, 25 Jun 2003 10:09:37 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2003 07:07:48 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5PE8HMO002630 for ; Wed, 25 Jun 2003 07:08:19 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIU56381; Wed, 25 Jun 2003 07:08:15 -0700 (PDT) Message-Id: <200306251408.AIU56381@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Wed, 25 Jun 2003 10:08:15 -0400 Subject: [midcom] Reminder: WG LAST CALL - semantics document Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , ------- Forwarded Message Date: Wed, 18 Jun 2003 11:11:16 -0400 From: Melinda Shore To: midcom@ietf.org Subject: [midcom] WG LAST CALL - semantics document The midcom semantics document is now in WG last call. *Please* give it a careful reading and bring any issues you identify to the mailing list. WG last call closes on Thursday, July 3. Thanks, Melinda - ------- Forwarded Message Date: Wed, 18 Jun 2003 07:53:51 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: midcom@ietf.org Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-03.txt - - --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 I ETF. Title : MIDCOM Protocol Semantics Author(s) : M. Stiemerling Filename : draft-ietf-midcom-semantics-03.txt Pages : 61 Date : 2003-6-17 This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or - more probably - a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-semantics-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-semantics-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17144631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-03.txt - - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144631.I-D@ietf.org> - - --OtherAccess-- - - --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom - ------- End of Forwarded Message _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------- End of Forwarded Message _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Jun 29 10:54:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00040 for ; Sun, 29 Jun 2003 10:54:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5TEs4406876 for midcom-archive@odin.ietf.org; Sun, 29 Jun 2003 10:54:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WdZ3-0001mS-B5; Sun, 29 Jun 2003 10:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WdYA-0001kw-UR for midcom@optimus.ietf.org; Sun, 29 Jun 2003 10:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00020 for ; Sun, 29 Jun 2003 10:53:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WdY8-0001M7-00 for midcom@ietf.org; Sun, 29 Jun 2003 10:53:04 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19WdXx-0001M3-00 for midcom@ietf.org; Sun, 29 Jun 2003 10:52:53 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5TEq2O0006255 for ; Sun, 29 Jun 2003 07:52:02 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIY76664; Sun, 29 Jun 2003 07:52:00 -0700 (PDT) Message-Id: <200306291452.AIY76664@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Sun, 29 Jun 2003 10:52:00 -0400 Subject: [midcom] Meeting in Vienna 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: , As things stand right now, the only thing on the agenda for the meeting in Vienna is the discussion of where we stand with the MIB work. If issues arise from WG last call on the semantics document they'll be discussed as well, but so far there have been no comments at all. Please let me know if there are other issues requiring meeting time. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom