From exim@www1.ietf.org Tue Aug 5 10:04:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11523 for ; Tue, 5 Aug 2003 10:04:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2Q1-0008Di-Vd for midcom-archive@odin.ietf.org; Tue, 05 Aug 2003 10:04:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75E45Xd031594 for midcom-archive@odin.ietf.org; Tue, 5 Aug 2003 10:04:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2Px-0008CB-P4; Tue, 05 Aug 2003 10:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2Pg-00089j-K2 for midcom@optimus.ietf.org; Tue, 05 Aug 2003 10:03:44 -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 KAA11402 for ; Tue, 5 Aug 2003 10:03:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2Pc-0002BT-00 for midcom@ietf.org; Tue, 05 Aug 2003 10:03:40 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19k2Pa-0002Au-00 for midcom@ietf.org; Tue, 05 Aug 2003 10:03:38 -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 h75E1aVI099884 for ; Tue, 5 Aug 2003 16:01:36 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 39216BD2A2 for ; Tue, 5 Aug 2003 15:39:37 +0200 (CEST) Date: Tue, 05 Aug 2003 16:01:32 +0200 From: Martin Stiemerling To: midcom@ietf.org Message-ID: <64640000.1060092092@localhost> In-Reply-To: <200307231404.AJX58947@mira-sjc5-c.cisco.com> References: <200307231404.AJX58947@mira-sjc5-c.cisco.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Alain Durand: Re: [ietf-sirs] Review request 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 are some replies to the issues raised below, are all included inline. Martin | | Melinda, | | Here is a first set of comments. Some are minor. Issue 6 & 7 are more | important, | as they would impact a number of sections in the document. | | - Alain. | | | Issue 1: | - -------- | 2.1.1. Protocol Transactions | [...] | An analysis of the requirements showed that four kinds of | transactions are required: | | - configuration transactions allowing the agent to request state | transitions at the middlebox | | - asynchronous transactions allowing the middlebox to change state | without a request by an agent. | | - monitoring transaction allowing the agent to request state | information from the middlebox | | - convenience transactions combining a set of configuration | transactions | | Configuration transactions and notification transactions provide the | basic MIDCOM protocol functionality. They are related to middlebox | state transactions and they concern establishment and termination of | MIDCOM sessions and of policy rules. | | Monitoring transactions are not related to middlebox state | transitions. They are used by agents for exploring number, status | and properties of policy rules established at the middlebox. | | Convenience transaction simplify MIDCOM sessions by combining a set | of configuration transactions into a single one. They are not | necessary for MIDCOM protocol operation. | | ==> There seems to be a terminology issue here, "notification | transaction" | is not part of the list of the 4 kinds of transactions. Notification transactions do belong to the asynchronous transactions, but of course this should be mentioned explicitly in the text. | | | | issue 2: | - -------- | 2.1.2. Message Types | [...] | For request messages and positive reply messages there exists one | message type per request transaction. Each reply transaction defines | the parameter list of the request message and of the positive | (successful) reply message using the transaction definition template | that is defined in Section 1.2. | | In case of a failed request transaction, a negative reply message is | sent from the middlebox to the agent. This message has the same type | for all request transactions. It contains the request identifier | identifying the request on which the reply is sent and a parameter | indicating the failure reason. | | ==> it seems a bit strange to me to dissociate positive & negative | messages | this way. There may be different failure mode, and negative return | message should be tailored to specific transaction in the same way | positive messages are. I do not see exactly the point where the strange dissociation is. Is it that: "For request messages and positive reply messages there exists one message type per request transaction." together with having a separate negative reply type? | | | Issue 3: | - -------- | 2.1.5. Access Control | | Access to policy rules and policy rule groups is based on ownership. | When a policy rule is created, a middlebox unique identifier is | generated for identifying it in further transactions. Beyond the | identifier, each policy rule has an owner. The owner is the | authenticated agent that established the policy rule. The middlebox | uses the owner attribute of a policy rule for controlling access to | it: each time an authenticated agent requests to modify an existing | policy rule, the middlebox determines the owner of the policy rule | and checks if the requesting agent is authorized to perform | transactions on the owning agent's policy rules. | | All policy rules belonging to the same policy rule group must have | the same owner. Therefore, authenticated agents either have access | to all members of a policy rule group, or to none of them. | | The middlebox may be configured to allow specific authenticated | agents to access and modify policy rules with certain specific | owners. Certainly, a reasonable default configuration would be that | each agent can access its own policy rules. Also, it might be a good | idea, to have an agent identity configured to act as administrator | being allowed to modify all policy rules owned by any agent. Anyway, | the configuration of authorization is not subject of the MIDCOM | protocol semantics. | | ==> The last sentence is a bit curious. I think it would actually make | sense | to define the semantic of which agent are allowed to modify what. | For example, one could envision a hierarchy of agents, where each | agent | would be allowed to modify configuration done by agent bellow him, | or, to define agent groups, where each agent of the group has equal | privileges. We do not what any type of multiple agent hierachy. The flat hierachy within the semantics is that agents usually have only rights to access their policy rules/groups and that only a very small set (in most cases one agent) is a superuser agent. This superuser agent can access all policy rules/groups. The configuration of authorization at the middlebox is out of scope. | | Issue 4: | - -------- | 2.2.1. Session Establishment (SE) | [...] | Session establishment may be simplified by using only a single | transaction. In this case server challenge and agent challenge | are omitted by the sender or ignored by the receiver, and | authentication must be provided by other means, for example by TLS | [RFC2246] or IPSEC [RFC2402][RFC2406]. | | ==> As the rest of the document seem to imply that either TLS or IPsec | would be used, why bother using this double challenge response? | And if TLS or IPsec are not used, is this challenge/response | exchange mandatory? | Also, if TLS or IPsec are not used, why only protecting Session | Establishment using challenge/response and not all transactions? It is mandatory to use TLS/IPSEC like securtiy protocols, since otherwise the most security requirements of MIDCOM are not met. A possible scenario for this additional challenge response: A user of MIDCOM does not want to use any type of security protocol (certainly not recommended!)and run MIDCOM over a dedicated wire between agent and middlebox. In this case a challenge response handshake would make sure that the right middlebox and agent are involved. | | Issue 5: | - -------- | 2.3.2. Establishing Policy Rules | [...] | On a traditional NAT, just an external address is reserved; on a | twice-NAT, an internal and an external address is reserved. In both | cases the reservation concerns either an IP address only or a | combination of an IP address with a range of port numbers. | | ==> Not being a NAT expert, I'm not sure to really understand what | reserving an IP address means. A little explanation will help. OK, we will do so. | | Issue 6: | - -------- | 2.3.5. Address Tuples | | Request and reply messages of the PRR, PER, and PRS transactions | contain address specifications for IP and transport addresses. These | parameters include | | - IP version | - IP address | - IP address prefix length | - transport protocol | - port number | - port parity | - port range | | ==> Actually, if one wants to specify a flow, this is not enough. | In particular, in the early stages of IPv6 deployment, | we see a lot of encapsulated traffic, IPv6/IPv4 (proto 41) | or IPv6/UDP/IPv4. | This would be of importance if the middlebox is a de-capsulator, | or a NAT/forwarder of IPv4 proto 41 and you'd like to use the | MIDCOM protocol to configure it. There has been discussions about this topic on the list. Especially SCTP was mentioned. But since nobody knows by now, how and when this encapsulation is integrated into NATs, we concentrated us on protocols that are used and furthermore documented in the NAT MIB. (That are IP, TCP, and UDP). | | | Issue 7: | - -------- | 2.3.6. Address Parameter Constraints | [...] | The value of the transport protocol parameter can have one of the | following values: 'TCP', 'UDP', 'ANY'. | | ==> What about other transport protocols? Previous comment applies here | too. | The semantic here should be extended to be more general. Other protocols are not clear with respect to NAT handling. Since a MIB module will do the job of MIDCOM, and the NAT MIB module is in the race, the focus should be protocols supported by that MIB module. Any other protocol is nice to have, but supporting all possible protocols is too much and are better handled by further extensions. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Aug 5 10:59:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14928 for ; Tue, 5 Aug 2003 10:59:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3HE-0002gz-9c for midcom-archive@odin.ietf.org; Tue, 05 Aug 2003 10:59:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Ex4Hr010349 for midcom-archive@odin.ietf.org; Tue, 5 Aug 2003 10:59:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3HA-0002gP-Rs; Tue, 05 Aug 2003 10:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3Gd-0002g0-1M for midcom@optimus.ietf.org; Tue, 05 Aug 2003 10:58:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14852 for ; Tue, 5 Aug 2003 10:58:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k3Ga-0002mU-00 for midcom@ietf.org; Tue, 05 Aug 2003 10:58:24 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19k3GZ-0002kr-00 for midcom@ietf.org; Tue, 05 Aug 2003 10:58:23 -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 h75EvpVI004327; Tue, 5 Aug 2003 16:57:51 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A56AEB5EE9; Tue, 5 Aug 2003 16:35:52 +0200 (CEST) Date: Tue, 05 Aug 2003 16:57:47 +0200 From: Martin Stiemerling To: Pyda Srisuresh , midcom@ietf.org Cc: stiemerling@ccrle.nec.de, quittek@ccrle.nec.de, taylor@nortelnetworks.com Message-ID: <102840000.1060095467@localhost> In-Reply-To: <20030728055501.32716.qmail@web40411.mail.yahoo.com> References: <20030728055501.32716.qmail@web40411.mail.yahoo.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Comments on the Semantics draft (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: , Content-Transfer-Encoding: 7bit Hi Pyda, | Had a chance to briefly review the draft. Overall, the draft seems well | thought out and organized. I liked it. Below are my comments. Majority of | the comments are centered on NAT middleboxes. Thanks for reading the document and giving feedback! | | 1. I suggest, the document state upfront that the focus of the draft was | principally TCP and UDP based applications ( I think, section 2.3.6 states | this) Yes, that's must since a lot of discussions are saying "what about protocol xy". We will put this in the front of the document, perhaps with a hint to the NAT MIB module. | | 2. Terminology - I found it confusing with the terms "agent" and | "session", especially, as juxtaposed to terms like "user agent" and "data | session" in SP example. But, I believe, the authors were consitent | throughout and refered the terms to mean "Midcom agent" and "Midcom | session". It might be a good idea to state this upfront. The terminology in the SIP examples could be indeed more precise. Will fix that. | | 3. Session control transactions (including SE, ST, AST & Middlebox | capabilities transaction): I believe, these are middlebox function | **independent** and the semantics may be uniformly enforced across | varieties of middlebox devices. | | These are unlike the Policy rule transactions, which, I believe, are often | middlebox function **dependent**. As such, the Middlebox | function-independent transactions and middlebox function-dependent | transactions need not be in the same transport session, so long as the | authentcation/authorization information from one can be carried across | the other. Further, midlebox-function-specific transactions need not | confirm to an abstract/uniform transaction model. The sub-protocols that | govern the resources of NAT or firewall may use different transaction | models. The general idea of the semantics is that all session, policy rule, and policy rule groups transactions are transmitted in the same transport session (whatever the transport is). | | While I dont beleieve, the document states anywhere that transactions for | any any middlebx function should confirm to a unique model (or) that all | transactions should occur within a specific MIDCOM session, it seemed to | imply that. Perhaps, this is mainly to do with the way the draft is | structured. If so, i would suggest that this be stated upfront so the | model doesnt cloud the readers mind into thinking this as a requirement. Yes, all transactions should occur within the specific MIDCOM session. We will add a statement to clarify this. | | 4. Agent-unique-Ids vs Middlebox-unique-Ids | I like the characterization. The examples are spread across the draft. | Basically, I believe, agent-unique-Ids are transaction-IDs for the | requests generated by the Agent and all the rest are middle-box-unique. I | would suggest stating this during terms definitions. Right. | | One other note. The middlebox can engage in sessions with several MIDCOM | agents. To me, this mandate that the middlebox assign each of the agents | it engges with a unique-agent-ID. This agent-id would in turn be used by | the middlebox to track ownership of the resources and a means to contact | the agents asynchronously. I believe, this needs to be included in the | semantics draft (as part of the session control transactions). It is in the section 2.1.7 "Peer identifiers". Perhaps the heading is misleading and should be changed to "Agent identifier". The bottom line of this section is that a middlebox must use some sort of agent ID, but can use for instance the TCP socket ID. | | 5. Policy rule: The definition says, this shoudl be (condition+Action). | However, I had seen several instances where a NAT-BIND is referred as a | Policy rule. Sounds like, you were using a single policy-rule abstract to | refer to several middlebox entities. It woudl help to state the abstract | type you are refering to in the rule. ex: map, BIND, session etc. OK, I see the point. Indeed we refer in the policy rule to a construct that may consists out of NAT-BIND and firewall rules. So the policy rule is meant as an 'umbrella'. | | I believe, a NAT-BIND constitutes an action; NAT address map constitutes a | condition (along with an implicit static/dynamic BIND action); and, a NAT | session, identified by its inside and outside session tuples (alogn with | the BINDs) will constitute a rule. | | 6. Section 2.3.1 - Configuration transactions | a) You mention NAT bindings. But, there is no mention of NAT sessions. For | example, multiple NAPT sessions using beargn the same source-IP, | Source-port might use different PORT bindings or the same PORT binding. | This is essentially the difference between symmetric NAT and cone NAT. | One permits p2p NAT sessiosn and the other doesnt. In essence, NAT | binding and NAT session must be treated as independent controllable | entities. I see the point, that for a single NAT binding several NAT sessions may run at the same time. And I see the point that these two have to be differentiated. The MIDCOM protocol does only configure NAT bindings and is not aware about the actual NAT session (a binding could be configured by not used). By now I don't see the impact on the semantics. It is just a problem of mentioning that there are NAT sessions or even more? | | b) You mention lifetime of a rule. Typically, NAT devices (that include | an ALG) do not have this attribute. They have a MaxIdletime for BINDs and | sessions. Agents will want to set the MaxIdletime for a resource | (NAT-BIND or NAT-session). The lifetime attribute is new and may be a | fine thing to add to NAT maps, binds and sessions. This will ensure that | agent imposed entities disappear after the specified time. But, there is | a dependency graph here. lifetiem of a nat map must be greater than (or | equal to) the lifetime of the nat binds and nat sessions, it generates. | Further, lifetime of a nat bind must be greater than (or equal to) the | lifetime of the sessions associated with the BIND. The lifetime attribute must neither be added to the NAT engine nor to the firewall engine, but it could. This lifetime attribute can be kept in the MIDCOM stack, and the stack must take about all other timers, e.g. the nat bind time must be greater or equal to the policy rule lifetime. There are some functions of MIDCOM that must not be necessary supported by the middlebox engines, like grouping firewall rules and NAT bindings into a single policy rule. This applies to the lifetimers as well. These functions may be only implemented in the MIDCOM stack. | | 7. Ownership (NAT maps, binds): | Say, a NAT address map is scoped out by multiple agents into multiple | sub-rules. NAT middlebox will presumably assign a different group-ID for | each of the sub-maps. Once a packet belongs to an address-map of an | agent-specified group-id, NAT middlebox does not wait for the agent to | setup all the follow-on construct like NAT BIND and nat session, right? | In that case, I believe, the owning agent-id is transferred to the BINDs | and sessions that NAT creates; but not the group-id, correct? I presume, | it is safe to assume, ownership transfer is expected to occur from binds | to sessions as well. To be honestly, I do not understand the point. Could you elaborated it more? | | 8. Note, there shoudl be an ownership attribute in policy-rule request and | response (Listed in section 4.1, but not specified on 2.3.7, 2.3.8). 2.3.7 and 2.3.8 specifiy the Policy Reserve Rule and Policy Enable Rule. In section 4.1 the Status transactions are used, but not the reserve/enable transactions. The ownership attribute is not required in reserve/enable transactions since agents are only allowed to access their policy rules/groups. | | 9. Section 2.3.7(PRR): | PRR seems to be a construct meant specifically for NAT middleboxes. The | disctinction between the two is apparently to do with when the lifetime | clock starts ticking. Requring NAT middleboxes to maintain PRR seems | needlessly complex. I would suggest doign away with the PRR construct. | PER should suffice, so long as the agent can set the PER just as the | construct is required. PRR is required and requested by some vendors, since you can nail down ports and IP address before you know anything else of your communcation partner. Using only PER with wildcarding may results in some not needed security risks, but is indeed requested by some people as well. So with PRR you can request information about your external IP address and port without opening anything in the NAT. Thanks for doing this extensive review of the MIDCOM semantics Suresh. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Aug 5 11:31:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16172 for ; Tue, 5 Aug 2003 11:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3mD-0003mG-5I for midcom-archive@odin.ietf.org; Tue, 05 Aug 2003 11:31:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75FV5Zg014514 for midcom-archive@odin.ietf.org; Tue, 5 Aug 2003 11:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3m9-0003lg-Kw; Tue, 05 Aug 2003 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3m7-0003lC-Gq for midcom@optimus.ietf.org; Tue, 05 Aug 2003 11:30:59 -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 LAA16146 for ; Tue, 5 Aug 2003 11:30:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k3m6-0003Ck-00 for midcom@ietf.org; Tue, 05 Aug 2003 11:30:58 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19k3m5-0003CD-00 for midcom@ietf.org; Tue, 05 Aug 2003 11:30:57 -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 h75FU5VI007133; Tue, 5 Aug 2003 17:30:05 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B1D97AD372; Tue, 5 Aug 2003 17:08:05 +0200 (CEST) Date: Tue, 05 Aug 2003 17:30:00 +0200 From: Martin Stiemerling To: midcom@ietf.org Cc: Melinda Shore , quittek@ccrle.nec.de, taylor@nortelnetworks.com Message-ID: <119190000.1060097400@localhost> In-Reply-To: <200307281450.AKC61790@mira-sjc5-c.cisco.com> References: <200307281450.AKC61790@mira-sjc5-c.cisco.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Juergen Schoenwaelder: Re: [ietf-sirs] Review request 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, thanks to Juergen for reviewing the MIDCOM semantics. | | I have read today and below are | my comments. Note that I did not follow the midcom work nor do I | consider myself an expert of middleboxes. So excuse if some of the | comments are "beating a dead horse" or just show my ignorance. All comments are welcome :-) | | In general, I found the document rather clear (except as noted below) | and I wish folks good luck that they finally also find a protocol for | the written down semantics. ;-) | | (a) It would be nice to say in the introduction what an agent is in | the context of midcom. It becomes clear when reading the document | but it won't hurt to avoid confusion by saying upfront what the | players in the game are. We tried to avoid this and point to the MIDCOM framework and requirements. The framework should describe it in-depth. | | (b) I got confused by the terms "asynchronous transaction" and | "notification transactions". Are these terms interchangeable? If | yes, I suggest to pick just one (and in the case that every | asynchronous transactions leads to a notification message, I would | prefer the term notification transactions. But more important, the | relationship of these terms should be clarified. The terminology in terms of "asynchronous transactions" and "notification transactions" needs some shaping. We will fix this. | | (c) I also found the phrase "state transaction" in section 2.1.1 and | I guess you mean "state transition". That's right. | | (d) I fail to parse the following sentence from section 2.1.3: | | Policy rule groups can be used to indicate relationships | between policy rules and to simplify transactions on a set of | policy rules by using a single one per group instead of one per | policy rule. | | What does "one" refer to? It should refer to 'transaction'. Fixed. | | (e) Section 2.1.6 says: | | - maximum number of simultaneous MIDCOM sessions | group | | Perhaps "group" is just an editorial mistake? Thanks, that's an error in the nroff source. | | (f) Section 2.1.8 says: | | Support limitation may be different for different authenticated | agents. | | Not sure I understand this right, but perhaps a wording such as the | following is clearer: | | The set of announced supported transactions may be different | for different authenticated agents. Sounds good! | | (g) The text in section 2.3 refers in three places to PLC but I think | it actually means RLC. Yes, it is RLC. Fixed. | | (h) The text specifically talks about TCP and UDP. There are of course | more transports to consider. In fact, you may want to filter based | on the contained protocol number or something equivalent. We tried to focus on TCP, UDP, and IP only, since most of the NATs/Firewalls support only those. See the answer to Alain as well. | | (i) The last paragraph on page 26 refers to ARE notifications, which | are not defined in the document. Perhaps this should be ART (but I | am not totally sure). This should be REN (Policy Rule Event Notification). Fixed. | | (j) Last paragraph in section 2.3.9: Change "After a the ..." to | "After the ..." Fixed. | | (k) In several places, there is text like this: | | After sending a success reply with a lifetime of zero, the | middlebox will consider the policy rule to be non-existent. It | will not process any further transaction on this policy rule. | | Lets assume I send to messages, one to change the lifetime to zero | followed by a request to retrieve the status. In this case, I | still expect to get a failure response to the second request and | so the request has to be processed - just the rule is gone. Or is | it really the intention that such requests are dropped and I have | to wait for some sort of a timeout? You are right in the sense that the second request should result in a negative response like "pr not available". The last sentence out of the next above needs to be changed. Proposal: "Any further transaction on this policy rule will result in a negative reply, indicating that this policy rule does not exist anymore". | | (l) I think the decision to make the PRL/PRS and the GL/GS transaction | optional is not useful if you want a robust system. Further, for | debugging purposes, it is essential to be able to read the current | configuration. Just relying that the shared state between the | middlebox and the agent never gets out of sync won't work well in | the world I am familiar with. Any other opinion? I'm fine with leaving them optional. | | (m) Does the PRS reply indeed cover all information? What about the | parity thing or the mode? That's missing. Fixed. | | (n) Section 2.4.1 says: | | Group transactions are declared as 'optional' by their | respective compliance entry in Section 3. However, they | provide some functionality, that is not available if only | mandatory transactions are available. | | I am wondering what this functionality is. My guess is that it all | boils down to atomicity of lifetime changes. If this is the case, | please say so. If not, explain what this extra functionality is. | (Or just remove the whole paragraph since the later text explains | the GLC in a bit more detail.) We should mention what functionality. Atomicity is a point, another is convenience for the agent in sending only one request. | | (o) The following text in section 2.4.2 seems to be a bit garbled: | | failure reason: | | - request identifier: an identifier matching the identifier of the | request. | | - failure reason: | - transaction not supported | | I guess you wanted to say: | | failure reason: | | - transaction not supported That's a formatting error. Fixed. | | (p) My language parser failed on this text in secton 3.1: | | met. Also there still must exist a composed transaction consisting | of a sequence of transactions fine-grained transactions, which is | equivalent to a single transaction defined in this document, and for | which the atomicity requirement stated in Section 2.1.3 is met. | | A compliant implementation | | Note the phrase "sequence of transactions fine-grained transactions" | and the incomplete sentence. Oh, this needs some hard rephrasing. Have to think about that. | | (q) Duplicate "to" in section 3.2. Fixed. | | (r) Missing dot after the second sentence in section 5.3.1. Fixed. | | (s) Capitalize "framework" in reference [MDC-FRM] if you choose to | capitalize things. Fixed. | | (t) Would it make sense to say upfront that request identifier are | exchanged in request-response transactions so that they do not | have to be listed everywhere? Should be written in the beginning. Fixed. | | Hope this helps. Thanks a lot for reading and giving the feedback! Martin | | /js | | - -- | Juergen Schoenwaelder International University Bremen | P.O. Box 750 561, 28725 Bremen, | Germany | | ------- End of Forwarded Message | Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Aug 5 11:36:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16356 for ; Tue, 5 Aug 2003 11:36:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3qz-00047H-IZ for midcom-archive@odin.ietf.org; Tue, 05 Aug 2003 11:36:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Fa1iD015808 for midcom-archive@odin.ietf.org; Tue, 5 Aug 2003 11:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3qy-00046V-MJ; Tue, 05 Aug 2003 11:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3q6-00040C-6L for midcom@optimus.ietf.org; Tue, 05 Aug 2003 11:35: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 LAA16305 for ; Tue, 5 Aug 2003 11:35:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k3q5-0003Eq-00 for midcom@ietf.org; Tue, 05 Aug 2003 11:35:05 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19k3q3-0003EP-00 for midcom@ietf.org; Tue, 05 Aug 2003 11:35:03 -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 h75FYRVI007725; Tue, 5 Aug 2003 17:34:27 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AEC22B662B; Tue, 5 Aug 2003 17:12:27 +0200 (CEST) Date: Tue, 05 Aug 2003 17:34:22 +0200 From: Martin Stiemerling To: Tom Taylor , midcom@ietf.org Cc: srisuresh@yahoo.com, j.schoenwaelder@iu-bremen.de, Alain.Durand@Sun.COM Subject: Re: [midcom] Comments on the semantics draft: flow specification issues Message-ID: <122300000.1060097662@localhost> In-Reply-To: <3F282291.3040208@nortelnetworks.com> References: <3F282291.3040208@nortelnetworks.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, | ============================================== | Response (probably leading to more discussion) | ============================================== | | There is an issue with complete generalization here. SCTP was on the | list earlier, and concern was expressed that there is as yet no | specification for how NATs handle SCTP when it involves multihoming. | Alain's issue 6 regarding encapsulation seems to have somewhat of the | same flavour -- that is, it requires an additional description of | middlebox functionality to serve as a starting point*. The Midcom | protocol is supposed to be about controlling that functionality, not | defining it. In other words, any middlebox capability we invoke should | itself be specified in some other document, which we should include as a | reference in this one. I have to agree with Tom. Any other protocol/encapsulation and their application in firewalls and NATs should be defined in some other documents before MIDCOM is using them. In view of the NAT-MIB, which may be used as part of the MIDCOM MIB module solution, only TCP, UDP, and IP are supported. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Aug 5 11:38:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16431 for ; Tue, 5 Aug 2003 11:38:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3sv-0004Sq-Vs for midcom-archive@odin.ietf.org; Tue, 05 Aug 2003 11:38:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Fc1Ds017117 for midcom-archive@odin.ietf.org; Tue, 5 Aug 2003 11:38:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3sv-0004Re-4C; Tue, 05 Aug 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 19k3sX-0004L5-Kp for midcom@optimus.ietf.org; Tue, 05 Aug 2003 11:37:37 -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 LAA16410 for ; Tue, 5 Aug 2003 11:37:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k3sW-0003GE-00 for midcom@ietf.org; Tue, 05 Aug 2003 11:37:36 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19k3sV-0003G2-00 for midcom@ietf.org; Tue, 05 Aug 2003 11:37:35 -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 h75Fb4VI008181 for ; Tue, 5 Aug 2003 17:37:04 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 470C4B00B8 for ; Tue, 5 Aug 2003 17:15:05 +0200 (CEST) Date: Tue, 05 Aug 2003 17:37:00 +0200 From: Martin Stiemerling To: midcom@ietf.org Message-ID: <128200000.1060097820@localhost> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] Thanks again to the reviewers 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, Thanks again to all the reviewers for looking at the MIDCOM semantics! Martin Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Aug 5 13:48:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20281 for ; Tue, 5 Aug 2003 13:48:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5un-0000mF-H8 for midcom-archive@odin.ietf.org; Tue, 05 Aug 2003 13:48:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Hm5C3002968 for midcom-archive@odin.ietf.org; Tue, 5 Aug 2003 13:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5uj-0000lh-JW; Tue, 05 Aug 2003 13:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5qZ-0000gA-LT for midcom@optimus.ietf.org; Tue, 05 Aug 2003 13:43:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20146 for ; Tue, 5 Aug 2003 13:43:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5qX-0004BH-00 for midcom@ietf.org; Tue, 05 Aug 2003 13:43:41 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19k5qW-0004BD-00 for midcom@ietf.org; Tue, 05 Aug 2003 13:43:40 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h75HhdFp007647 for ; Tue, 5 Aug 2003 11:43:39 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HJ500I4AQKRW8@edgemail1.Central.Sun.COM> for midcom@ietf.org; Tue, 05 Aug 2003 11:43:39 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HJ500JBHQKPYN@mail.sun.net> for midcom@ietf.org; Tue, 05 Aug 2003 11:43:39 -0600 (MDT) Date: Tue, 05 Aug 2003 10:45:50 -0700 From: Alain Durand Subject: Re: [midcom] Comments on the semantics draft: flow specification issues In-reply-to: <122300000.1060097662@localhost> To: Martin Stiemerling Cc: Tom Taylor , midcom@ietf.org, srisuresh@yahoo.com, j.schoenwaelder@iu-bremen.de Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) 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 On Tuesday, August 5, 2003, at 08:34 AM, Martin Stiemerling wrote: > Hi, > > | ============================================== > | Response (probably leading to more discussion) > | ============================================== > | > | There is an issue with complete generalization here. SCTP was on the > | list earlier, and concern was expressed that there is as yet no > | specification for how NATs handle SCTP when it involves multihoming. > | Alain's issue 6 regarding encapsulation seems to have somewhat of the > | same flavour -- that is, it requires an additional description of > | middlebox functionality to serve as a starting point*. The Midcom > | protocol is supposed to be about controlling that functionality, not > | defining it. In other words, any middlebox capability we invoke > should > | itself be specified in some other document, which we should include > as a > | reference in this one. > > I have to agree with Tom. > > Any other protocol/encapsulation and their application in firewalls > and NATs > should be defined in some other documents before MIDCOM is using them. > In view of the NAT-MIB, which may be used as part of the MIDCOM MIB > module > solution, only TCP, UDP, and IP are supported. > > Martin IPv6 in IPv4 encapsulation is well defined in RFC2893. - Alain. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Aug 5 20:49:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04365 for ; Tue, 5 Aug 2003 20:49:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kCUB-0007L6-LB for midcom-archive@odin.ietf.org; Tue, 05 Aug 2003 20:49:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h760n3Cd028194 for midcom-archive@odin.ietf.org; Tue, 5 Aug 2003 20:49:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kCU9-0007KJ-5n; Tue, 05 Aug 2003 20:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kCTu-0007K5-QX for midcom@optimus.ietf.org; Tue, 05 Aug 2003 20:48:47 -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 UAA04340 for ; Tue, 5 Aug 2003 20:48:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kCTs-000717-00 for midcom@ietf.org; Tue, 05 Aug 2003 20:48:44 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19kCTr-000714-00 for midcom@ietf.org; Tue, 05 Aug 2003 20:48:43 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h760m0Y12466; Tue, 5 Aug 2003 20:48:00 -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 NLVY94ZG; Tue, 5 Aug 2003 20:48:01 -0400 Received: from nortelnetworks.com (acart1d8.ca.nortel.com [47.129.129.84]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QHD6KNS1; Tue, 5 Aug 2003 20:48:00 -0400 Message-ID: <3F30503B.3020805@nortelnetworks.com> Date: Tue, 05 Aug 2003 20:47:55 -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.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Martin Stiemerling CC: midcom@ietf.org Subject: Re: [midcom] Thanks again to the reviewers References: <128200000.1060097820@localhost> In-Reply-To: <128200000.1060097820@localhost> 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 Given that the classification of messages into different transaction types led to some confusion, I wonder if we should reword this to say that the semantics support two types of communication: request-response transactions, and asynchronous notifications. We could go one step further to say that all asynchronous notifications are generated by the middlebox. Martin Stiemerling wrote: > Hi, > > Thanks again to all the reviewers for looking at the MIDCOM semantics! > > Martin > > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de > IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Aug 6 03:20:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08226 for ; Wed, 6 Aug 2003 03:20:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kIaa-0002wX-4I for midcom-archive@odin.ietf.org; Wed, 06 Aug 2003 03:20:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h767K3tx011292 for midcom-archive@odin.ietf.org; Wed, 6 Aug 2003 03:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kIaX-0002vV-KV; Wed, 06 Aug 2003 03:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kIZf-0002sz-QC for midcom@optimus.ietf.org; Wed, 06 Aug 2003 03:19:08 -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 DAA08204 for ; Wed, 6 Aug 2003 03:19:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kIZd-00015t-00 for midcom@ietf.org; Wed, 06 Aug 2003 03:19:05 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19kIZc-00015S-00 for midcom@ietf.org; Wed, 06 Aug 2003 03:19:04 -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 h767IYVI024312; Wed, 6 Aug 2003 09:18:35 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 05C02BA233; Wed, 6 Aug 2003 08:56:29 +0200 (CEST) Date: Wed, 06 Aug 2003 09:18:33 +0200 From: Martin Stiemerling To: Alain Durand Cc: Tom Taylor , midcom@ietf.org, srisuresh@yahoo.com, j.schoenwaelder@iu-bremen.de Subject: Re: [midcom] Comments on the semantics draft: flow specification issues Message-ID: <686577.1060161513@[10.1.1.109]> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Alian, --On Dienstag, 5. August 2003 10:45 -0700 Alain Durand wrote: | |> I have to agree with Tom. |> |> Any other protocol/encapsulation and their application in firewalls |> and NATs |> should be defined in some other documents before MIDCOM is using them. |> In view of the NAT-MIB, which may be used as part of the MIDCOM MIB |> module |> solution, only TCP, UDP, and IP are supported. |> |> Martin | | IPv6 in IPv4 encapsulation is well defined in RFC2893. thanks for hint, but SCTP (another candidate) is defined as well in RFC 2960. The handling of these protocols in NATs remains unclear, i.e. there is no RFC describing that. Martin | | - Alain. | Martin Stiemerling NEC Network Laboratories _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Aug 7 02:55:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02694 for ; Thu, 7 Aug 2003 02:55:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kefy-0007XX-Bo for midcom-archive@odin.ietf.org; Thu, 07 Aug 2003 02:55:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h776t6O3028959 for midcom-archive@odin.ietf.org; Thu, 7 Aug 2003 02:55:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kefu-0007WS-HB; Thu, 07 Aug 2003 02:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kefX-0007Vd-Fc for midcom@optimus.ietf.org; Thu, 07 Aug 2003 02:54:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02679 for ; Thu, 7 Aug 2003 02:54:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kefT-0003V1-00 for midcom@ietf.org; Thu, 07 Aug 2003 02:54:35 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19kefS-0003UO-00 for midcom@ietf.org; Thu, 07 Aug 2003 02:54:34 -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 h776s5VI082041; Thu, 7 Aug 2003 08:54:05 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1B0C1BD6B3; Thu, 7 Aug 2003 08:31:50 +0200 (CEST) Date: Thu, 07 Aug 2003 08:54:03 +0200 From: Martin Stiemerling To: Tom Taylor Cc: midcom@ietf.org Subject: Re: [midcom] Thanks again to the reviewers Message-ID: <1024062.1060246443@[10.1.1.109]> In-Reply-To: <3F30503B.3020805@nortelnetworks.com> References: <128200000.1060097820@localhost> <3F30503B.3020805@nortelnetworks.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Tom, --On Dienstag, 5. August 2003 20:47 -0400 Tom Taylor wrote: | Given that the classification of messages into different transaction | types led to some confusion, I wonder if we should reword this to say | that the semantics support two types of communication: request-response | transactions, and asynchronous notifications. We could go one step | further to say that all asynchronous notifications are generated by the | middlebox. I'll check the text today and see how to simply that issue. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Aug 10 01:38:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16724 for ; Sun, 10 Aug 2003 01:38:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19liu4-0005XO-5U for midcom-archive@odin.ietf.org; Sun, 10 Aug 2003 01:38:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7A5c44v021282 for midcom-archive@odin.ietf.org; Sun, 10 Aug 2003 01:38:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19liu1-0005Wq-07; Sun, 10 Aug 2003 01: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 19litw-0005Wf-Fu for midcom@optimus.ietf.org; Sun, 10 Aug 2003 01:37: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 BAA16721 for ; Sun, 10 Aug 2003 01:37:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19litt-0005Du-00 for midcom@ietf.org; Sun, 10 Aug 2003 01:37:53 -0400 Received: from smtp017.mail.yahoo.com ([216.136.174.114]) by ietf-mx with smtp (Exim 4.12) id 19lits-0005Dr-00 for midcom@ietf.org; Sun, 10 Aug 2003 01:37:52 -0400 Received: from c-67-164-29-130.client.comcast.net (HELO suresh) (srisuresh@67.164.29.130 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Aug 2003 05:37:52 -0000 Reply-To: From: "Pyda Srisuresh" To: "Martin Stiemerling" , Cc: , , Date: Sat, 9 Aug 2003 22:37:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <102840000.1060095467@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [midcom] RE: Comments on the Semantics draft (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: , Content-Transfer-Encoding: 7bit Martin, Sorry for the delay. Please see my comments inline. <... stuff deleted> > | > | 3. Session control transactions (including SE, ST, AST & Middlebox > | capabilities transaction): I believe, these are middlebox function > | **independent** and the semantics may be uniformly enforced across > | varieties of middlebox devices. > | > | These are unlike the Policy rule transactions, which, I > believe, are often > | middlebox function **dependent**. As such, the Middlebox > | function-independent transactions and middlebox function-dependent > | transactions need not be in the same transport session, so long as the > | authentcation/authorization information from one can be carried across > | the other. Further, midlebox-function-specific transactions need not > | confirm to an abstract/uniform transaction model. The sub-protocols that > | govern the resources of NAT or firewall may use different transaction > | models. > > The general idea of the semantics is that all session, policy rule, and > policy rule groups transactions are transmitted in the same transport > session (whatever the transport is). OK. > > | > | While I dont beleieve, the document states anywhere that > transactions for > | any any middlebx function should confirm to a unique model (or) that all > | transactions should occur within a specific MIDCOM session, it seemed to > | imply that. Perhaps, this is mainly to do with the way the draft is > | structured. If so, i would suggest that this be stated upfront so the > | model doesnt cloud the readers mind into thinking this as a requirement. > > Yes, all transactions should occur within the specific MIDCOM session. > We will add a statement to clarify this. > OK. > | > | 4. Agent-unique-Ids vs Middlebox-unique-Ids > | I like the characterization. The examples are spread across the draft. > | Basically, I believe, agent-unique-Ids are transaction-IDs for the > | requests generated by the Agent and all the rest are > middle-box-unique. I > | would suggest stating this during terms definitions. > > Right. > > | > | One other note. The middlebox can engage in sessions with several MIDCOM > | agents. To me, this mandate that the middlebox assign each of the agents > | it engges with a unique-agent-ID. This agent-id would in turn be used by > | the middlebox to track ownership of the resources and a means to contact > | the agents asynchronously. I believe, this needs to be included in the > | semantics draft (as part of the session control transactions). > > It is in the section 2.1.7 "Peer identifiers". Perhaps the > heading is misleading and should be changed to "Agent identifier". > The bottom line of this section is that a middlebox must use > some sort of agent ID, but can use for instance the TCP socket ID. OK. I am just looking for a statement that says that agent identifiers must be middlebox unique. > > | > | 5. Policy rule: The definition says, this shoudl be (condition+Action). > | However, I had seen several instances where a NAT-BIND is referred as a > | Policy rule. Sounds like, you were using a single policy-rule > abstract to > | refer to several middlebox entities. It woudl help to state the abstract > | type you are refering to in the rule. ex: map, BIND, session etc. > > OK, I see the point. Indeed we refer in the policy rule to a construct > that may consists out of NAT-BIND and firewall rules. So the policy rule > is meant as an 'umbrella'. In that case, you might want to define a "transaction-entity", which is an abstract construct that would refer to any middlebox resource that may be dynamically controlled/monitored via the midcom protocol. > | > | I believe, a NAT-BIND constitutes an action; NAT address map > constitutes a > | condition (along with an implicit static/dynamic BIND action); > and, a NAT > | session, identified by its inside and outside session tuples (alogn with > | the BINDs) will constitute a rule. > | > | 6. Section 2.3.1 - Configuration transactions > | a) You mention NAT bindings. But, there is no mention of NAT > sessions. For > | example, multiple NAPT sessions using beargn the same source-IP, > | Source-port might use different PORT bindings or the same PORT binding. > | This is essentially the difference between symmetric NAT and cone NAT. > | One permits p2p NAT sessiosn and the other doesnt. In essence, NAT > | binding and NAT session must be treated as independent controllable > | entities. > > I see the point, that for a single NAT binding several NAT sessions may > run at the same time. And I see the point that these two have to be > differentiated. The MIDCOM protocol does only configure NAT bindings > and is not aware about the actual NAT session (a binding could be > configured by not used). Right. What I am saying is that the MIDCOM protocol ought to be aware of "NAT session" construct in addition to "NAT binding". This is because, there could be instances where setting a NAT binding is adequate (ex: basic NAT and p2p-NAT). Other times, the agent might need to setup individual NAT sessions. > By now I don't see the impact on the semantics. It is just a problem > of mentioning that there are NAT sessions or even more? > The impact is to add an additional construct for "NAT session" into the semantics. I also had a question (later on below) about setting ownership on a NAT map entry. This would, in turn, call for a new construct for "NAT map" in the semantics. > | > | b) You mention lifetime of a rule. Typically, NAT devices (that include > | an ALG) do not have this attribute. They have a MaxIdletime for > BINDs and > | sessions. Agents will want to set the MaxIdletime for a resource > | (NAT-BIND or NAT-session). The lifetime attribute is new and may be a > | fine thing to add to NAT maps, binds and sessions. This will ensure that > | agent imposed entities disappear after the specified time. But, there is > | a dependency graph here. lifetiem of a nat map must be greater than (or > | equal to) the lifetime of the nat binds and nat sessions, it generates. > | Further, lifetime of a nat bind must be greater than (or equal to) the > | lifetime of the sessions associated with the BIND. > > The lifetime attribute must neither be added to the NAT engine nor to the > firewall engine, but it could. This lifetime attribute can be kept in the > MIDCOM stack, and the stack must take about all other timers, e.g. > the nat bind time must be greater or equal to the policy rule lifetime. > The MIDCOM stack you are refering to on a middlebox is merely a MIDCOM specific extension module that manipulates the middlebox resource objects, right. Given that these objects are quite granular and an intrinsic part of NAT and firewall engines, how do you suppose the lifetime timers for these objects can be maintained in an independent module away from the NAT and firewall engines? I would think, the natural thing would be to associate the timer attribute as part of the NAT/Firewall objects, and specify the timer routines that process the timeouts as part of "MIDCOM extension module". BTW, What are your thoughts on the MaxIdletime attribute? > There are some functions of MIDCOM that must not be necessary supported > by the middlebox engines, like grouping firewall rules and NAT bindings > into a single policy rule. This applies to the lifetimers as well. These > functions may be only implemented in the MIDCOM stack. > Once again, I believe, group-ID and Owner-Id attributes will need to be associated with the individual NAT/firewall objects. Routines that do the manipulation based on group IDs and Owner-IDs can be part of "MIDCOM extension module". > | > | 7. Ownership (NAT maps, binds): > | Say, a NAT address map is scoped out by multiple agents into multiple > | sub-rules. OK. I guess, I wasnt clear. Let me take an example. Say, you have a NAPT map configured as "10.0.0.0/8 be mapped to address 142.29.48.20". Say, you have two agents - agent-1 and agent-2. Say, both these agents assign group-IDs to subsets of TCP/UDP ports as follows. Agent-1, group-1: "10.1.0.0/16 mapped to 142.29.48.20:31001-32000" Agent-1, group-2: "10.2.0.0/16 mapped to 142.29.48.20:32001-33000" Agent-2, group-3: "10.3.0.0/16 mapped to 142.29.48.20:33001-34000" Agent-2, group-4: "10.4.0.0/16 mapped to 142.29.48.20:34001-35000" > | NAT middlebox will presumably assign a different group-ID for > | each of the sub-maps. Once a packet belongs to an address-map of an > | agent-specified group-id, NAT middlebox does not wait for the agent to > | setup all the follow-on construct like NAT BIND and nat session, right? So, if a session was initiated from 10.3.0.1, NAT would (without intervention from agent-2) setup a PORT-bind and nat-session. > | In that case, I believe, the owning agent-id is transferred to the BINDs > | and sessions that NAT creates; but not the group-id, correct? I presume, In the above scenario, the PORT-BIND and session that NAT creates for the session from 10.3.0.1 would inhert agent ownership (i.e., agent-2) from the map, but not the group ID. This, I believe, is because group is map/BIND/session-specific and cannot be inherited across resource object types. > | it is safe to assume, ownership transfer is expected to occur from binds > | to sessions as well. > By the same token, when a BIND belongs to a Bind-group-id, the sessions that use the BIND will inherit agent ownership from the BIND; but will not inherit the Bind-group-id. > To be honestly, I do not understand the point. Could you > elaborated it more? > Sorry, my oiginal text was not clear. Hope the above explanation helps. > | > | 8. Note, there shoudl be an ownership attribute in policy-rule > request and > | response (Listed in section 4.1, but not specified on 2.3.7, 2.3.8). > > 2.3.7 and 2.3.8 specifiy the Policy Reserve Rule and Policy Enable Rule. > In section 4.1 the Status transactions are used, but not the > reserve/enable > transactions. The ownership attribute is not required in reserve/enable > transactions since agents are only allowed to access their ^^^^^ How will a middlebox know what is theirs if there isnt an agent ownership assigned. I believe, an agent is instantiating its ownership on a middlebox resource when the agent enables it. > policy rules/groups. > > | > | 9. Section 2.3.7(PRR): > | PRR seems to be a construct meant specifically for NAT middleboxes. The > | disctinction between the two is apparently to do with when the lifetime > | clock starts ticking. Requring NAT middleboxes to maintain PRR seems > | needlessly complex. I would suggest doign away with the PRR construct. > | PER should suffice, so long as the agent can set the PER just as the > | construct is required. > > PRR is required and requested by some vendors, since you can nail down > ports and IP address before you know anything else of your communcation > partner. Perhaps I should restate what I said. I believe, you were using the term PRR to reserve IP addresses/ports and the term PER to setup address/port BINDs. I was suggesting to use a single term PER to ascertain ownership of NAT address map entries, BIND entries and session entries. > Using only PER with wildcarding may results in some not needed > security risks, but is indeed requested by some people as well. By PER with wild-carding, did you mean multiple BINDs? If so, why do you believe, that would be a security risk? > So with PRR you can request information about your external IP address and > port without opening anything in the NAT. > Please see my above note. > Thanks for doing this extensive review of the MIDCOM semantics Suresh. > No problem. Thank you for doing an extensive write up. > Martin > regards, suresh _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Aug 11 09:13:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15043 for ; Mon, 11 Aug 2003 09:13:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCTx-0002Qk-G1 for midcom-archive@odin.ietf.org; Mon, 11 Aug 2003 09:13:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BDD58c009318 for midcom-archive@odin.ietf.org; Mon, 11 Aug 2003 09:13:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCTs-0002Pp-Sz; Mon, 11 Aug 2003 09:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCSv-0002PH-NY for midcom@optimus.ietf.org; Mon, 11 Aug 2003 09:12: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 JAA15026 for ; Mon, 11 Aug 2003 09:11:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mCSu-0005kf-00 for midcom@ietf.org; Mon, 11 Aug 2003 09:12:00 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19mCSt-0005kC-00 for midcom@ietf.org; Mon, 11 Aug 2003 09:11:59 -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 h7BDBRVI040713; Mon, 11 Aug 2003 15:11:27 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3EE84B9DCB; Mon, 11 Aug 2003 14:48:31 +0200 (CEST) Date: Mon, 11 Aug 2003 15:11:28 +0200 From: Martin Stiemerling To: Tom Taylor Cc: midcom@ietf.org Subject: Re: [midcom] Thanks again to the reviewers Message-ID: <28530000.1060607488@localhost> In-Reply-To: <1024062.1060246443@[10.1.1.109]> References: <128200000.1060097820@localhost> <3F30503B.3020805@nortelnetworks.com> <1024062.1060246443@[10.1.1.109]> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have checked the terminology and there was some mixed up text. The notification transactions printed in the text are asynchronous transactions. There are only notification messages, no notification transactions anymore. Thanks Martin --On Thursday, August 07, 2003 08:54:03 +0200 Martin Stiemerling wrote: | Hi Tom, | | --On Dienstag, 5. August 2003 20:47 -0400 Tom Taylor | wrote: | || Given that the classification of messages into different transaction || types led to some confusion, I wonder if we should reword this to say || that the semantics support two types of communication: request-response || transactions, and asynchronous notifications. We could go one step || further to say that all asynchronous notifications are generated by the || middlebox. | | | I'll check the text today and see how to simply that issue. | | Martin | | | _______________________________________________ | midcom mailing list | midcom@ietf.org | https://www1.ietf.org/mailman/listinfo/midcom Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Aug 12 09:57:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13514 for ; Tue, 12 Aug 2003 09:57:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZdj-0003df-VZ for midcom-archive@odin.ietf.org; Tue, 12 Aug 2003 09:56:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CDuh5I013986 for midcom-archive@odin.ietf.org; Tue, 12 Aug 2003 09:56:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZd2-0003Y3-UY; Tue, 12 Aug 2003 09:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZcY-0003Xm-RG for midcom@optimus.ietf.org; Tue, 12 Aug 2003 09:55: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 JAA13463 for ; Tue, 12 Aug 2003 09:55:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZcW-0000Yc-00 for midcom@ietf.org; Tue, 12 Aug 2003 09:55:28 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19mZcW-0000YX-00 for midcom@ietf.org; Tue, 12 Aug 2003 09:55:28 -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 h7CDsV006828; Tue, 12 Aug 2003 09:54:31 -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 QYKXF81M; Tue, 12 Aug 2003 09:54:32 -0400 Received: from nortelnetworks.com (acart1gn.ca.nortel.com [47.129.129.196]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYPT23R8; Tue, 12 Aug 2003 09:54:31 -0400 Message-ID: <3F38F196.5090505@nortelnetworks.com> Date: Tue, 12 Aug 2003 09:54:30 -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.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: srisuresh@yahoo.com CC: Martin Stiemerling , midcom@ietf.org, stiemerling@ccrle.nec.de, quittek@ccrle.nec.de References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: Comments on the Semantics draft (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: , Content-Transfer-Encoding: 7bit I don't think MIDCOM is about control of NAT sessions, in your terminology. MIDCOM installs BINDs and maps, and the NAT enables sessions within that framework. As for the distinction between rule lifetime and maxIdleTime, let me make this proposal: - NATs can continue to enforce maxIdleTime, if this is seen as an effective means of resource conservation - however, the policy introduced by policy rule lifetime overrides: when the lifetime expires, any session existing by virtue of that policy rule is terminated. Pyda Srisuresh wrote: > Martin, > > Sorry for the delay. Please see my comments inline. > > <... stuff deleted> ... > > >>| >>| 5. Policy rule: The definition says, this shoudl be (condition+Action). >>| However, I had seen several instances where a NAT-BIND is referred as a >>| Policy rule. Sounds like, you were using a single policy-rule >>abstract to >>| refer to several middlebox entities. It woudl help to state the abstract >>| type you are refering to in the rule. ex: map, BIND, session etc. >> >>OK, I see the point. Indeed we refer in the policy rule to a construct >>that may consists out of NAT-BIND and firewall rules. So the policy rule >>is meant as an 'umbrella'. > > > In that case, you might want to define a "transaction-entity", which is an > abstract construct that would refer to any middlebox resource that may be > dynamically controlled/monitored via the midcom protocol. > > >>| >>| I believe, a NAT-BIND constitutes an action; NAT address map >>constitutes a >>| condition (along with an implicit static/dynamic BIND action); >>and, a NAT >>| session, identified by its inside and outside session tuples (alogn with >>| the BINDs) will constitute a rule. >>| >>| 6. Section 2.3.1 - Configuration transactions >>| a) You mention NAT bindings. But, there is no mention of NAT >>sessions. For >>| example, multiple NAPT sessions using beargn the same source-IP, >>| Source-port might use different PORT bindings or the same PORT binding. >>| This is essentially the difference between symmetric NAT and cone NAT. >>| One permits p2p NAT sessiosn and the other doesnt. In essence, NAT >>| binding and NAT session must be treated as independent controllable >>| entities. >> >>I see the point, that for a single NAT binding several NAT sessions may >>run at the same time. And I see the point that these two have to be >>differentiated. The MIDCOM protocol does only configure NAT bindings >>and is not aware about the actual NAT session (a binding could be >>configured by not used). > > > Right. What I am saying is that the MIDCOM protocol ought to be aware of > "NAT session" construct in addition to "NAT binding". This is because, there > could be instances where setting a NAT binding is adequate (ex: basic NAT > and p2p-NAT). Other times, the agent might need to setup individual NAT > sessions. > > >>By now I don't see the impact on the semantics. It is just a problem >>of mentioning that there are NAT sessions or even more? >> > > The impact is to add an additional construct for "NAT session" into the > semantics. > > I also had a question (later on below) about setting ownership on a NAT map > entry. This would, in turn, call for a new construct for "NAT map" in the > semantics. > > >>| >>| b) You mention lifetime of a rule. Typically, NAT devices (that include >>| an ALG) do not have this attribute. They have a MaxIdletime for >>BINDs and >>| sessions. Agents will want to set the MaxIdletime for a resource >>| (NAT-BIND or NAT-session). The lifetime attribute is new and may be a >>| fine thing to add to NAT maps, binds and sessions. This will ensure that >>| agent imposed entities disappear after the specified time. But, there is >>| a dependency graph here. lifetiem of a nat map must be greater than (or >>| equal to) the lifetime of the nat binds and nat sessions, it generates. >>| Further, lifetime of a nat bind must be greater than (or equal to) the >>| lifetime of the sessions associated with the BIND. >> >>The lifetime attribute must neither be added to the NAT engine nor to the >>firewall engine, but it could. This lifetime attribute can be kept in the >>MIDCOM stack, and the stack must take about all other timers, e.g. >>the nat bind time must be greater or equal to the policy rule lifetime. >> > > > The MIDCOM stack you are refering to on a middlebox is merely a MIDCOM > specific extension module that manipulates the middlebox resource objects, > right. Given that these objects are quite granular and an intrinsic part of > NAT and firewall engines, how do you suppose the lifetime timers for these > objects can be maintained in an independent module away from the NAT and > firewall engines? I would think, the natural thing would be to associate the > timer attribute as part of the NAT/Firewall objects, and specify the timer > routines that process the timeouts as part of "MIDCOM extension module". > > BTW, What are your thoughts on the MaxIdletime attribute? > > >>There are some functions of MIDCOM that must not be necessary supported >>by the middlebox engines, like grouping firewall rules and NAT bindings >>into a single policy rule. This applies to the lifetimers as well. These >>functions may be only implemented in the MIDCOM stack. >> > > > Once again, I believe, group-ID and Owner-Id attributes will need to be > associated with the individual NAT/firewall objects. Routines that do the > manipulation based on group IDs and Owner-IDs can be part of "MIDCOM > extension module". > > ...> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Aug 16 19:05:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20933 for ; Sat, 16 Aug 2003 19:05:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oA6e-0008Ro-B6 for midcom-archive@odin.ietf.org; Sat, 16 Aug 2003 19:05:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7GN58A2032473 for midcom-archive@odin.ietf.org; Sat, 16 Aug 2003 19:05:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oA6X-0008RK-QO; Sat, 16 Aug 2003 19:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oA5k-0008R5-9J for midcom@optimus.ietf.org; Sat, 16 Aug 2003 19:04: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 TAA20930 for ; Sat, 16 Aug 2003 19:04:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oA5h-0005Ay-00 for midcom@ietf.org; Sat, 16 Aug 2003 19:04:09 -0400 Received: from web40410.mail.yahoo.com ([66.218.78.107]) by ietf-mx with smtp (Exim 4.12) id 19oA5g-0005AY-00 for midcom@ietf.org; Sat, 16 Aug 2003 19:04:08 -0400 Message-ID: <20030816230337.63497.qmail@web40410.mail.yahoo.com> Received: from [66.224.113.194] by web40410.mail.yahoo.com via HTTP; Sat, 16 Aug 2003 16:03:37 PDT Date: Sat, 16 Aug 2003 16:03:37 -0700 (PDT) From: Pyda Srisuresh To: Tom Taylor Cc: Martin Stiemerling , midcom@ietf.org, stiemerling@ccrle.nec.de, quittek@ccrle.nec.de In-Reply-To: <3F38F196.5090505@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [midcom] Re: Comments on the Semantics draft (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: , --- Tom Taylor wrote: > I don't think MIDCOM is about control of NAT sessions, in your terminology. > MIDCOM > installs BINDs and maps, and the NAT enables sessions within that framework. > It would be nice, if that was so. But, that is not the case. There are several deployments of symmetric NAPT devices that use different BINDings for the same (address,port) while connecting to different sessions. > As for the distinction between rule lifetime and maxIdleTime, let me make > this proposal: > - NATs can continue to enforce maxIdleTime, if this is seen as an effective > means > of resource conservation > - however, the policy introduced by policy rule lifetime overrides: when > the > lifetime expires, any session existing by virtue of that policy rule is > terminated. > OK. However, the semantics document need to recognize the MaxIdleTime as a parameter in itself and allow that to be set. cheers, suresh > Pyda Srisuresh wrote: > > > Martin, > > > > Sorry for the delay. Please see my comments inline. > > > > <... stuff deleted> > ... > > > > > > >>| > >>| 5. Policy rule: The definition says, this shoudl be (condition+Action). > >>| However, I had seen several instances where a NAT-BIND is referred as a > >>| Policy rule. Sounds like, you were using a single policy-rule > >>abstract to > >>| refer to several middlebox entities. It woudl help to state the abstract > >>| type you are refering to in the rule. ex: map, BIND, session etc. > >> > >>OK, I see the point. Indeed we refer in the policy rule to a construct > >>that may consists out of NAT-BIND and firewall rules. So the policy rule > >>is meant as an 'umbrella'. > > > > > > In that case, you might want to define a "transaction-entity", which is an > > abstract construct that would refer to any middlebox resource that may be > > dynamically controlled/monitored via the midcom protocol. > > > > > >>| > >>| I believe, a NAT-BIND constitutes an action; NAT address map > >>constitutes a > >>| condition (along with an implicit static/dynamic BIND action); > >>and, a NAT > >>| session, identified by its inside and outside session tuples (alogn with > >>| the BINDs) will constitute a rule. > >>| > >>| 6. Section 2.3.1 - Configuration transactions > >>| a) You mention NAT bindings. But, there is no mention of NAT > >>sessions. For > >>| example, multiple NAPT sessions using beargn the same source-IP, > >>| Source-port might use different PORT bindings or the same PORT binding. > >>| This is essentially the difference between symmetric NAT and cone NAT. > >>| One permits p2p NAT sessiosn and the other doesnt. In essence, NAT > >>| binding and NAT session must be treated as independent controllable > >>| entities. > >> > >>I see the point, that for a single NAT binding several NAT sessions may > >>run at the same time. And I see the point that these two have to be > >>differentiated. The MIDCOM protocol does only configure NAT bindings > >>and is not aware about the actual NAT session (a binding could be > >>configured by not used). > > > > > > Right. What I am saying is that the MIDCOM protocol ought to be aware of > > "NAT session" construct in addition to "NAT binding". This is because, > there > > could be instances where setting a NAT binding is adequate (ex: basic NAT > > and p2p-NAT). Other times, the agent might need to setup individual NAT > > sessions. > > > > > >>By now I don't see the impact on the semantics. It is just a problem > >>of mentioning that there are NAT sessions or even more? > >> > > > > The impact is to add an additional construct for "NAT session" into the > > semantics. > > > > I also had a question (later on below) about setting ownership on a NAT map > > entry. This would, in turn, call for a new construct for "NAT map" in the > > semantics. > > > > > >>| > >>| b) You mention lifetime of a rule. Typically, NAT devices (that include > >>| an ALG) do not have this attribute. They have a MaxIdletime for > >>BINDs and > >>| sessions. Agents will want to set the MaxIdletime for a resource > >>| (NAT-BIND or NAT-session). The lifetime attribute is new and may be a > >>| fine thing to add to NAT maps, binds and sessions. This will ensure that > >>| agent imposed entities disappear after the specified time. But, there is > >>| a dependency graph here. lifetiem of a nat map must be greater than (or > >>| equal to) the lifetime of the nat binds and nat sessions, it generates. > >>| Further, lifetime of a nat bind must be greater than (or equal to) the > >>| lifetime of the sessions associated with the BIND. > >> > >>The lifetime attribute must neither be added to the NAT engine nor to the > >>firewall engine, but it could. This lifetime attribute can be kept in the > >>MIDCOM stack, and the stack must take about all other timers, e.g. > >>the nat bind time must be greater or equal to the policy rule lifetime. > >> > > > > > > The MIDCOM stack you are refering to on a middlebox is merely a MIDCOM > > specific extension module that manipulates the middlebox resource objects, > > right. Given that these objects are quite granular and an intrinsic part of > > NAT and firewall engines, how do you suppose the lifetime timers for these > > objects can be maintained in an independent module away from the NAT and > > firewall engines? I would think, the natural thing would be to associate > the > > timer attribute as part of the NAT/Firewall objects, and specify the timer > > routines that process the timeouts as part of "MIDCOM extension module". > > > > BTW, What are your thoughts on the MaxIdletime attribute? > > > > > >>There are some functions of MIDCOM that must not be necessary supported > >>by the middlebox engines, like grouping firewall rules and NAT bindings > >>into a single policy rule. This applies to the lifetimers as well. These > >>functions may be only implemented in the MIDCOM stack. > >> > > > > > > Once again, I believe, group-ID and Owner-Id attributes will need to be > > associated with the individual NAT/firewall objects. Routines that do the > > manipulation based on group IDs and Owner-IDs can be part of "MIDCOM > > extension module". > > > > > ...> > ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Aug 18 08:07:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17092 for ; Mon, 18 Aug 2003 08:07:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oimv-0003H3-58 for midcom-archive@odin.ietf.org; Mon, 18 Aug 2003 08:07:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IC75ji012575 for midcom-archive@odin.ietf.org; Mon, 18 Aug 2003 08:07:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oimq-0003F6-Jp; Mon, 18 Aug 2003 08:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oimk-0003Ea-Po for midcom@optimus.ietf.org; Mon, 18 Aug 2003 08:06:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17075 for ; Mon, 18 Aug 2003 08:06:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oimi-0006mQ-00 for midcom@ietf.org; Mon, 18 Aug 2003 08:06:52 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19oimh-0006mK-00 for midcom@ietf.org; Mon, 18 Aug 2003 08:06:51 -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 h7IC6JVI000391; Mon, 18 Aug 2003 14:06:20 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 99AC4B5740; Mon, 18 Aug 2003 13:42:16 +0200 (CEST) Date: Mon, 18 Aug 2003 14:06:17 +0200 From: Martin Stiemerling To: srisuresh@yahoo.com, midcom@ietf.org Cc: stiemerling@ccrle.nec.de, quittek@ccrle.nec.de, taylor@nortelnetworks.com Message-ID: <18570000.1061208377@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] RE: Comments on the Semantics draft (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: , Content-Transfer-Encoding: 7bit Hi, --On Saturday, August 09, 2003 22:37:28 -0700 Pyda Srisuresh wrote: [...] |> It is in the section 2.1.7 "Peer identifiers". Perhaps the |> heading is misleading and should be changed to "Agent identifier". |> The bottom line of this section is that a middlebox must use |> some sort of agent ID, but can use for instance the TCP socket ID. | | OK. I am just looking for a statement that says that agent identifiers | must be middlebox unique. That statement is now in the text of section 2.1.7. |> | |> | I believe, a NAT-BIND constitutes an action; NAT address map |> constitutes a |> | condition (along with an implicit static/dynamic BIND action); |> and, a NAT |> | session, identified by its inside and outside session tuples (alogn |> | with the BINDs) will constitute a rule. |> | |> | 6. Section 2.3.1 - Configuration transactions |> | a) You mention NAT bindings. But, there is no mention of NAT |> sessions. For |> | example, multiple NAPT sessions using beargn the same source-IP, |> | Source-port might use different PORT bindings or the same PORT binding. |> | This is essentially the difference between symmetric NAT and cone NAT. |> | One permits p2p NAT sessiosn and the other doesnt. In essence, NAT |> | binding and NAT session must be treated as independent controllable |> | entities. |> |> I see the point, that for a single NAT binding several NAT sessions may |> run at the same time. And I see the point that these two have to be |> differentiated. The MIDCOM protocol does only configure NAT bindings |> and is not aware about the actual NAT session (a binding could be |> configured by not used). | | Right. What I am saying is that the MIDCOM protocol ought to be aware of | "NAT session" construct in addition to "NAT binding". This is because, | there could be instances where setting a NAT binding is adequate (ex: | basic NAT and p2p-NAT). Other times, the agent might need to setup | individual NAT sessions. The goal was and is to keep the protocol itself quite simple and to enable MIDCOM agent to get things working through middleboxes. For a management protocol it would be clear that this session and binding configuration is needed. The MIDCOM semantics focus on dynamic configuration. [...] |> The lifetime attribute must neither be added to the NAT engine nor to the |> firewall engine, but it could. This lifetime attribute can be kept in the |> MIDCOM stack, and the stack must take about all other timers, e.g. |> the nat bind time must be greater or equal to the policy rule lifetime. |> | | The MIDCOM stack you are refering to on a middlebox is merely a MIDCOM | specific extension module that manipulates the middlebox resource objects, | right. Given that these objects are quite granular and an intrinsic part | of NAT and firewall engines, how do you suppose the lifetime timers for | these objects can be maintained in an independent module away from the | NAT and firewall engines? I would think, the natural thing would be to | associate the timer attribute as part of the NAT/Firewall objects, and | specify the timer routines that process the timeouts as part of "MIDCOM | extension module". How and where the lifetimes are maintained is not part of the protocol, since MIDCOM is concered with the communication between agent and middlebox. If the lifetimes are stored within the MIDCOM stack or within the actual middlebox engine is more an operational or implementation issue. For instace with the lifetime in MIDCOM stack approach you can extend easily existing firewalls and NATs, without digging into the middlebox engine. | | BTW, What are your thoughts on the MaxIdletime attribute? The MaxIdleTime needs to be considered by the implementation, but not by the middlebox. The MIDCOM stack can watch the MaxIdleTime and include it into its operational logic. | |> There are some functions of MIDCOM that must not be necessary supported |> by the middlebox engines, like grouping firewall rules and NAT bindings |> into a single policy rule. This applies to the lifetimers as well. These |> functions may be only implemented in the MIDCOM stack. |> | | Once again, I believe, group-ID and Owner-Id attributes will need to be | associated with the individual NAT/firewall objects. Routines that do the | manipulation based on group IDs and Owner-IDs can be part of "MIDCOM | extension module". The identification can be part of the middlebox engine, but it must no be. That depends on implementation and probably vendor's believe. | |> | |> | 7. Ownership (NAT maps, binds): |> | Say, a NAT address map is scoped out by multiple agents into multiple |> | sub-rules. | | OK. I guess, I wasnt clear. Let me take an example. | Say, you have a NAPT map configured as "10.0.0.0/8 be mapped to address | 142.29.48.20". | Say, you have two agents - agent-1 and agent-2. Say, both these agents | assign group-IDs to subsets of TCP/UDP ports as follows. | | Agent-1, group-1: "10.1.0.0/16 mapped to | 142.29.48.20:31001-32000" | Agent-1, group-2: "10.2.0.0/16 mapped to | 142.29.48.20:32001-33000" | Agent-2, group-3: "10.3.0.0/16 mapped to | 142.29.48.20:33001-34000" | Agent-2, group-4: "10.4.0.0/16 mapped to | 142.29.48.20:34001-35000" Thanks, now is see the point. With the NAT MIB you can do these kind of configuration at the NAT. But in the MIDCOM semantics the target is not to configure complete sub-network mappings. The target is to enable dedicated bindings for end hosts. The semantics talk about A0, A1, A2, and A3. Whereas, A0 and A3 are the addresses' and ports of two endhosts. So the configuration of the NAT would be: Agent-1, group1, A0 mapped to A2, A0={IP Address, port(s)} A2={IP Address, port(s)} So the goal is to create exactly for the combination of A0, A1, A2, and A3 a binding and probably a session (and nail it down). Sessions should be removed upon removal of the corresponding binding. Perhaps we need to add text to the semantics to express that explicitly. [...] | | Sorry, my oiginal text was not clear. Hope the above explanation helps. Thanks, now I got it! | |> | |> | 8. Note, there shoudl be an ownership attribute in policy-rule |> request and |> | response (Listed in section 4.1, but not specified on 2.3.7, 2.3.8). |> |> 2.3.7 and 2.3.8 specifiy the Policy Reserve Rule and Policy Enable Rule. |> In section 4.1 the Status transactions are used, but not the |> reserve/enable |> transactions. The ownership attribute is not required in reserve/enable |> transactions since agents are only allowed to access their | ^^^^^ | How will a middlebox know what is theirs if there isnt an agent ownership | assigned. I believe, an agent is instantiating its ownership on a | middlebox resource when the agent enables it. An agent becomes the owner of a middlebox resource when he enables it. The agent can only manipulate policy rules with PRR and PER where he is the owner. The middlebox must of course keep track of the ownership of a particular policy rule internally. |> | |> | 9. Section 2.3.7(PRR): |> | PRR seems to be a construct meant specifically for NAT middleboxes. The |> | disctinction between the two is apparently to do with when the lifetime |> | clock starts ticking. Requring NAT middleboxes to maintain PRR seems |> | needlessly complex. I would suggest doign away with the PRR construct. |> | PER should suffice, so long as the agent can set the PER just as the |> | construct is required. |> |> PRR is required and requested by some vendors, since you can nail down |> ports and IP address before you know anything else of your communcation |> partner. | | Perhaps I should restate what I said. I believe, you were using the term | PRR to reserve IP addresses/ports and the term PER to setup address/port | BINDs. I was suggesting to use a single term PER to ascertain ownership | of NAT address map entries, BIND entries and session entries. | |> Using only PER with wildcarding may results in some not needed |> security risks, but is indeed requested by some people as well. | | By PER with wild-carding, did you mean multiple BINDs? If so, why do you | believe, that would be a security risk? PER with wildcarding would result in one bind (A0 to A2). For combined NAT and firewall this would result in: Allow everything from outside to A2 (and thus to A0). Some people see this as a security risk, since you open your firewall/NAT wide for everybody. In some scenarios, like SIP early media, this wide open case is explicitly needed, since it is not known from where the first data is coming. Cheers Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Aug 18 11:15:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22367 for ; Mon, 18 Aug 2003 11:15:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19olir-0000bl-US for midcom-archive@odin.ietf.org; Mon, 18 Aug 2003 11:15:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IFF5I2002332 for midcom-archive@odin.ietf.org; Mon, 18 Aug 2003 11:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19olin-0000aD-II; Mon, 18 Aug 2003 11:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oliZ-0000ZV-Co for midcom@optimus.ietf.org; Mon, 18 Aug 2003 11:14:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22277; Mon, 18 Aug 2003 11:14:42 -0400 (EDT) Message-Id: <200308181514.LAA22277@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, 18 Aug 2003 11:14:42 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-mib-analysis-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communications (MIDCOM) Protocol Managed Objects Analysis Author(s) : M. Barnes et al. Filename : draft-ietf-midcom-mib-analysis-00.txt Pages : 16 Date : 2003-8-18 This document provides an analysis and identification of the managed objects for dynamic configuration of middleboxes. The scope of the middleboxes to which these managed objects apply is limited to NATs and Firewalls. However, the managed objects as identified in this document are intended to provide a baseline for the dynamic configuration of other types of middleboxes. The applicability of existing Management Information Base (MIB) modules to the MIDCOM requirements, framework and semantics is described. Additional managed objects are identified to satisfy the entirety of the MIDCOM requirements, framework and semantics and to provide a complete MIDCOM MIB for NATs and Firewalls to fully realize the requirements of the MIDCOM protocol. The actual definition of any new managed objects is provided in a separate document [MDCMIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-analysis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-mib-analysis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-mib-analysis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-18112811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-mib-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-mib-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-18112811.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Aug 19 20:06:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16966 for ; Tue, 19 Aug 2003 20:06:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUZ-0002Bs-7M for midcom-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K06NKc008412 for midcom-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUI-0001ww-Kl; Tue, 19 Aug 2003 20:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pFDL-0007rn-Sj for midcom@optimus.ietf.org; Tue, 19 Aug 2003 18:44:32 -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 SAA13832 for ; Tue, 19 Aug 2003 18:44:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pFDI-0001A8-00 for midcom@ietf.org; Tue, 19 Aug 2003 18:44:28 -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 19pFDH-00019o-00 for midcom@ietf.org; Tue, 19 Aug 2003 18:44:28 -0400 Date: Tue, 19 Aug 2003 15:43:57 -0700 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg Thread-Index: AcMuixD6RTqHE5zJRbe5VZNUPq1cBg4FrcvQ content-class: urn:content-classes:message From: "Yutaka Takeda" To: "Midcom" Cc: "Cullen Jennings" , "Bryan Ford" , Content-Transfer-Encoding: quoted-printable Subject: [midcom] wierd behavior of restricted-cone nat 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: quoted-printable As I was going through a test with STUN, I have been experiencing some weired problems. I have so far noticed that some NATs which are I = thought restricted-cone NATs, sometimes act like a symmetric NAT. I thought this is a kind of exceptional behavior which we can ingnore in most = cases, however, after reading a discussion between Bryan and Cullen a while ago about "Frugal Symmetric NAT and port restricted-cone NAT", I started to=20 wonder if this is a common and significant issue in a use of STUN or = other form of NAT discovery processes (i.e. Teredo). If Cullen's information is true (well more than likely), the "port = re-use" process in a restricted-cone NAT could be a problem for an application using STUN. http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg03217.= html Here is the case I am concerned about: There are two internal hosts (I1 and I2) behind a port restricted-cone=20 NAT, and each one bound a local transport address as I1a:I1p and I2a:I2p = respectively.(XXa is an IP address, XXp is a port)=20 I1 sends a packet to an external host E1 listening at E1a:E1b. This=20 causes a binding in the NAT and it allocates a MAPPED-ADDRESS (M1a:M1p). Then, I2 sends a packet to a different external hosts (E2a:E2b). This=20 time, the NAT can re-use the same MAPPED-ADDRESS (M1a:M1p) that is=20 previoulsy allocated since packets sent from E1 or E2 will be correctly routed back to I1 or I2. However, If I2 needs to send a packet to E1=20 while the NAT binding (M1a:M1p-E1a:E1p) is still present, I presume the NAT will allocate another MAPPED-ADDRESS (M2a:M2p). Say, E2 is STUN server and E1 is a final destination transport address for I2, the acquired MAPPED-ADDRESS (M1a:M1p) with STUN will not be useful to talk to E1. I1a:I1p --->(M1a:M1p)-------->E1a:E1p | | / I2a:I2p ----- + +-----|---->E2a:E2p | | (M2a:M2p)---+ I am still not confident on a relevance between what I am experiencing=20 and the above mentioned yet, and having hard time to reproduce this=20 situation. I guess the NAT has a specific condition for starting=20 re-using ports on the NAT which makes the reproduction difficult.=20 Has anyone already identified this situation? Any comments or thoughts on this will be appreciated. Best regards, Yutaka > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, June 09, 2003 5:16 AM > To: Bryan Ford; Midcom > Subject: Re: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg >=20 >=20 >=20 > 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=20 > best I can. Just > to make the discussion easier, lets assume that that the NAT=20 > only has one > external IP address. It does not really change much if it=20 > has more. I will > also gloss over the multiple protocols but again that makes=20 > no difference - > you can treat it as completely separate virtual NATs for each=20 > protocol. My > apologies to folks who point out this is PAT not NAT. End of=20 > disclaimers :-) >=20 >=20 > On 6/7/03 5:14 AM, "Bryan Ford" wrote: >=20 > > Cullen, > >=20 > > Thank you for your informative post. > >=20 > >> The difference between "symmetric" and "port restricted"=20 > in STUN is nothing > >> to do with the security of what packets are allowed=20 > through the NAT but is > >> determined by if the NAT reuses port numbers when it can.=20 > Given "corporate > >> grade" NATs only have 65k ports per IP and don't want to=20 > run out of ports, > >> they generally choose to reuse the ports. This makes them=20 > port restricted > >> instead of symmetric. This leads to a natural tendency=20 > away from symmetric > >> on large NATs. > >=20 > > I have one question about this issue that has come up recently. I'd > > particularly like to get your view on this (as a=20 > knowledgable technical > > person from, presumably, the biggest vendor of corporate=20 > NATs :)), but also > (really I'm a VoIP guy who plans to work for a major IPv6=20 > vendor but I know > a guy who plays a ...) > > from others on this list who may have relevant information.=20 > Unfortunately > > the question involves a little bit of "setup"; I hope=20 > you'll bear with me... > >=20 > > For the purpose of this message I would like to re-classify=20 > NATs into _three_ > > categories, based on how they allocate ports for=20 > translation sessions: > >=20 > > - "Cone NAT": usual definition - allocates a public NAT=20 > 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=20 > different external > > hosts and/por ports. > >=20 > > - "Wasteful Symmetric NAT": the typical kind of symmetric=20 > NAT - allocates a > > public NAT port each time a new outgoing session is=20 > initiated; each public > > NAT port remains allocated until that session terminates or=20 > times out and > > cannot be allocated concurrently to any other session=20 > during that time. >=20 > It's worth noting that when a packet arrives on the external=20 > port, the NAT > can figure where to send it on the inside by just looking at=20 > the port it > arrived on. The NAT still needs to keep the full session=20 > mapping to decide > if it should forward the packet at all - so the size of the=20 > state stored in > memory between this NAT and your frugal NAT is going to be similar. >=20 > >=20 > > - "Frugal Symmetric NAT": assigns a new NAT port to each=20 > new outgoing session > > initiated from within the firewall... BUT... allocation is=20 > not done on a > > basis of "whole" port numbers at all but on "session=20 > identifiers", which > > include all the details of the session (private IP/port,=20 > nat IP/port, > > external IP/port). Therefore, a given public NAT port can=20 > actually be reused > > concurrently by multiple simultaneous (perhaps completely unrelated) > > sessions, as long as each session remains uniquely=20 > distinguishable on both > > sides of the NAT. > >=20 >=20 > Yes, this is a good idea and some NATs do this today.=20 > However, the details > are still in how they pick the NAT port. One way would be to=20 > use random > ports as you suggest below. >=20 > Another way would be to attempt to use the same external port for all > sessions that have the same internal IP and internal port.=20 > 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=20 > enough ports > on the NAT for it to assign a unique external port for each=20 > session that has > a unique internal IP and internal port regardless of the=20 > number of internal > IPs. >=20 > Keep in mind this port allocation scheme still fully meets=20 > your frugal NAT > definition but now consider this from the STUN terminology=20 > point of view. > Because packets from the same internal IP/port use the same=20 > NAT port, this > is a port restricted NAT. >=20 > The terminology of "port restricted" in STUN was a little=20 > confusing because > many of the NAT people consider this still to be a form of=20 > "symmetric" - the > NAT folks mostly seem to define "symmetric" as you can only=20 > receive a packet > from public IP/port if you have sent to that IP/port on the=20 > same protocol. > Anyways, it is just a label defining a term so it's not worth=20 > worrying about > but it is worth nothing that the STUN definition of=20 > "symmetric" might not > line up exactly with some others. >=20 > > Since the behavior of a "frugal symmetric NAT" may not be=20 > obvious, here is a > > specific example of how one might work. The NAT has two=20 > internal hash tables > > for looking up sessions from the information found in TCP=20 > or UDP packets. > > The first table is for packets originating on the internal=20 > network, and is > > indexed on (internal IP, internal port, external IP,=20 > external port) - i.e., > > the "session identifier" as seen by internal hosts. The=20 > second is for > > packets originating on the external network, and is indexed=20 > on (NAT IP, NAT > > port, external IP, external port). The NAT has NO port=20 > allocation table or > > bitmap of any kind, because allocations are not done at a=20 > port granularity. > > Instead, when outgoing traffic initiates a new internal=20 > session, for which no > > entry is seen in the first (internal-packet-lookup) hash=20 > table, the NAT > > simply picks a public NAT port randomly to generate a=20 > corresponding external > > session tuple (NAT IP, NAT port, external IP, external=20 > port), and checks to > > see if an entry for that tuple already exists in the=20 > external-packet-lookup > > hash table. If not, the translation is created; if so, a=20 > new random port > > number is selected and the process is repeated until it=20 > succeeds or some > > fixed retry limit is reached. > > > =20 > > The upshot is that while a Cone NAT utilizes its port space=20 > more efficiently > > than a Wasteful Symmetric NAT, a Frugal Symmetric NAT could=20 > in turn utilize > > its port space several orders of magnitude more efficiently=20 > than a Cone NAT. > > Instead of being limited to 2^16 sessions total (Wasteful=20 > Symmetric NAT) or > > 2^16 translations (Cone NAT), a Frugal Symmetric NAT can=20 > potentially support > > 2^16 active sessions _per external endpoint_ from any=20 > number of internal > > clients in any combination. The space of concurrently=20 > active outgoing > > sessions possible for a given NAT IP address is effectively=20 > expanded from a > > 16-bit space (NAT port number alone) to a 64-bit space (NAT=20 > port number, > > external IP, external port). As far as realistic=20 > applications and protocols > > are concerned, a Frugal Symmetric NAT behaves=20 > indistinguishably from a > > Wasteful Symmetric NAT - i.e., it will work just fine for=20 > client/server > > traffic but will suck in the usual way for peer-to-peer traffic. >=20 > A frugal NAT like you describe could support 2^(16+32+16)=20 > session for each > internal IP. A port restricted NAT can also do 2^(16+32+16)=20 > sessions for > each internal IP.=20 >=20 > >=20 > > So with all that setup out of the way, here are my questions: > >=20 >=20 > This has been a good example - I hope I have convinced you that it is > possible to build a NAT that is simultaneously "port=20 > restricted" in the STUN > terminology, "frugal" in this terminology and, from a=20 > security point of > view, only lets exactly the same packets pass that a=20 > "symmetric" NAT would > have let pass. >=20 > > (a) Does anyone know if such a thing as a "Frugal Symmetric=20 > NAT" actually > > exists right now? I know that most existing symmetric NATs=20 > are of the > > "Wasteful" variety, but I don't know if _all_ of them are. > >=20 >=20 > Yes they exist. (at least if you buy into my port restricted=20 > is a form a > Frugal NAT) >=20 > > (b) Do you think it's likely that corporate NAT vendors=20 > such as Cisco will > > feel increasing pressure to build Frugal Symmetric NATs in=20 > the forseeable > > future, as a result of the demand for larger NATs that can=20 > handle more and > > more simultaneous connections with fewer globally routable=20 > IP addresses? > > (I'm thinking AOL here as an example, which from what I=20 > hear runs "the > > world's largest NAT" in front of all its customers.) >=20 > I think the large NATs will feel pressure to support more than 2^16 > sessions. There are some big NATs in China for instance. >=20 > >=20 > > (c) Or, do you think the increasing=20 > economic/political/whatever pressure to > > make NATs more peer-to-peer friendly, in order to support=20 > VoIP and networked > > games and all that, is in practice going to outweigh the=20 > pressure for "port > > frugality", ensuring that almost all NATs in the future will be > > (port-restricted) cone NATs? > >=20 >=20 > Well, it's not often you get win win - particularly with a=20 > NAT involved :-) > but I think in this case you can have port-restricted for P2P=20 > support and > lots of sessions at the same time. >=20 > > (d) Finally, if there is a substantial amount of real=20 > pressure in _both_ > > directions (port frugality and P2P friendliness), do you=20 > see a possibility > > that vendors may start considering even more complex hybrid=20 > solutions, say, > > which may be able treat certain (P2P) traffic in Cone NAT=20 > fashion while > > behaving as a Frugal Symmetric NAT for other=20 > (client/server) traffic? > >=20 >=20 > I really don't know the answer to this one - NAT vendors have=20 > 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=20 > ranging from > good to silly. =20 >=20 > > I realize that there are no absolutes here - I'm looking=20 > for opinions and > > industry projections. > >=20 > > Thanks very much, > > Bryan > > >=20 > Hope that helps, Cullen=20 >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Aug 20 11:10:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13014 for ; Wed, 20 Aug 2003 11:10:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUb6-0000TS-92 for midcom-archive@odin.ietf.org; Wed, 20 Aug 2003 11:10:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KFA4R1001818 for midcom-archive@odin.ietf.org; Wed, 20 Aug 2003 11:10:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUb3-0000S1-6Z; Wed, 20 Aug 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUaD-0000QP-LZ for midcom@optimus.ietf.org; Wed, 20 Aug 2003 11:09:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12922; Wed, 20 Aug 2003 11:09:01 -0400 (EDT) Message-Id: <200308201509.LAA12922@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, 20 Aug 2003 11:09:01 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-04.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Protocol Semantics Author(s) : M. Stiemerling et al. Filename : draft-ietf-midcom-semantics-04.txt Pages : 61 Date : 2003-8-20 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-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-semantics-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-semantics-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-20112445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-20112445.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 Aug 20 14:46:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29295 for ; Wed, 20 Aug 2003 14:46:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXy6-0005D2-8t for midcom-archive@odin.ietf.org; Wed, 20 Aug 2003 14:46:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KIk2p3020020 for midcom-archive@odin.ietf.org; Wed, 20 Aug 2003 14:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXy5-0005CT-B8; Wed, 20 Aug 2003 14:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXxw-0005Bm-RE for midcom@optimus.ietf.org; Wed, 20 Aug 2003 14:45: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 OAA29249 for ; Wed, 20 Aug 2003 14:45:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pXxu-0005M3-00 for midcom@ietf.org; Wed, 20 Aug 2003 14:45:50 -0400 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 19pXxt-0005M0-00 for midcom@ietf.org; Wed, 20 Aug 2003 14:45:49 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA11283 for ; Wed, 20 Aug 2003 15:00:08 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma011217; Wed, 20 Aug 03 14:59:04 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2 with InterScan Messaging Security Suite; Wed, 20 Aug 2003 14:46:09 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 20 Aug 2003 14:46:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] Re: Comments on the Semantics draft (draft-ietf-midcom-semantics-03.txt) Date: Wed, 20 Aug 2003 14:46:09 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BAEA93FA@NHROCMBX1.ets.enterasys.com> Thread-Topic: [midcom] Re: Comments on the Semantics draft (draft-ietf-midcom-semantics-03.txt) Thread-Index: AcNkSzhXZN1vvGpZSteXJ0So6SMMMwC/8wPw From: "Harrington, David" To: "Pyda Srisuresh" , "Tom Taylor" Cc: "Martin Stiemerling" , , , X-OriginalArrivalTime: 20 Aug 2003 18:46:09.0677 (UTC) FILETIME=[5241FBD0:01C3674B] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi, I cannot locate a current copy of the NAT MIB. Did the I-D expire? Did it ever move to an RFC? dbh > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com]=20 > Sent: Saturday, August 16, 2003 7:04 PM > To: Tom Taylor > Cc: Martin Stiemerling; midcom@ietf.org;=20 > stiemerling@ccrle.nec.de; quittek@ccrle.nec.de > Subject: [midcom] Re: Comments on the Semantics draft=20 > (draft-ietf-midcom-semantics-03.txt) >=20 >=20 >=20 > --- Tom Taylor wrote: > > I don't think MIDCOM is about control of NAT sessions, in=20 > your terminology.=20 > > MIDCOM=20 > > installs BINDs and maps, and the NAT enables sessions=20 > within that framework. > >=20 > It would be nice, if that was so. But, that is not the case.=20 > There are several > deployments of symmetric NAPT devices that use different=20 > BINDings for the same > (address,port) while connecting to different sessions. >=20 > > As for the distinction between rule lifetime and=20 > maxIdleTime, let me make > > this proposal: > > - NATs can continue to enforce maxIdleTime, if this is=20 > seen as an effective > > means=20 > > of resource conservation > > - however, the policy introduced by policy rule lifetime=20 > overrides: when > > the=20 > > lifetime expires, any session existing by virtue of that=20 > policy rule is > > terminated. > >=20 >=20 > OK. However, the semantics document need to recognize the=20 > MaxIdleTime as a > parameter in itself and allow that to be set. >=20 > cheers, > suresh >=20 > > Pyda Srisuresh wrote: > >=20 > > > Martin, > > >=20 > > > Sorry for the delay. Please see my comments inline. > > >=20 > > > <... stuff deleted> > > ... > >=20 > > >=20 > > >=20 > > >>| > > >>| 5. Policy rule: The definition says, this shoudl be=20 > (condition+Action). > > >>| However, I had seen several instances where a NAT-BIND=20 > is referred as a > > >>| Policy rule. Sounds like, you were using a single policy-rule > > >>abstract to > > >>| refer to several middlebox entities. It woudl help to=20 > state the abstract > > >>| type you are refering to in the rule. ex: map, BIND,=20 > session etc. > > >> > > >>OK, I see the point. Indeed we refer in the policy rule=20 > to a construct > > >>that may consists out of NAT-BIND and firewall rules. So=20 > the policy rule > > >>is meant as an 'umbrella'. > > >=20 > > >=20 > > > In that case, you might want to define a=20 > "transaction-entity", which is an > > > abstract construct that would refer to any middlebox=20 > resource that may be > > > dynamically controlled/monitored via the midcom protocol. > > >=20 > > >=20 > > >>| > > >>| I believe, a NAT-BIND constitutes an action; NAT address map > > >>constitutes a > > >>| condition (along with an implicit static/dynamic BIND action); > > >>and, a NAT > > >>| session, identified by its inside and outside session=20 > tuples (alogn with > > >>| the BINDs) will constitute a rule. > > >>| > > >>| 6. Section 2.3.1 - Configuration transactions > > >>| a) You mention NAT bindings. But, there is no mention of NAT > > >>sessions. For > > >>| example, multiple NAPT sessions using beargn the same source-IP, > > >>| Source-port might use different PORT bindings or the=20 > same PORT binding. > > >>| This is essentially the difference between symmetric=20 > NAT and cone NAT. > > >>| One permits p2p NAT sessiosn and the other doesnt. In=20 > essence, NAT > > >>| binding and NAT session must be treated as independent=20 > controllable > > >>| entities. > > >> > > >>I see the point, that for a single NAT binding several=20 > NAT sessions may > > >>run at the same time. And I see the point that these two=20 > have to be > > >>differentiated. The MIDCOM protocol does only configure=20 > NAT bindings > > >>and is not aware about the actual NAT session (a binding could be > > >>configured by not used). > > >=20 > > >=20 > > > Right. What I am saying is that the MIDCOM protocol ought=20 > to be aware of > > > "NAT session" construct in addition to "NAT binding".=20 > This is because, > > there > > > could be instances where setting a NAT binding is=20 > adequate (ex: basic NAT > > > and p2p-NAT). Other times, the agent might need to setup=20 > individual NAT > > > sessions. > > >=20 > > >=20 > > >>By now I don't see the impact on the semantics. It is=20 > just a problem > > >>of mentioning that there are NAT sessions or even more? > > >> > > >=20 > > > The impact is to add an additional construct for "NAT=20 > session" into the > > > semantics. > > >=20 > > > I also had a question (later on below) about setting=20 > ownership on a NAT map > > > entry. This would, in turn, call for a new construct for=20 > "NAT map" in the > > > semantics. > > >=20 > > >=20 > > >>| > > >>| b) You mention lifetime of a rule. Typically, NAT=20 > devices (that include > > >>| an ALG) do not have this attribute. They have a MaxIdletime for > > >>BINDs and > > >>| sessions. Agents will want to set the MaxIdletime for a resource > > >>| (NAT-BIND or NAT-session). The lifetime attribute is=20 > new and may be a > > >>| fine thing to add to NAT maps, binds and sessions. This=20 > will ensure that > > >>| agent imposed entities disappear after the specified=20 > time. But, there is > > >>| a dependency graph here. lifetiem of a nat map must be=20 > greater than (or > > >>| equal to) the lifetime of the nat binds and nat=20 > sessions, it generates. > > >>| Further, lifetime of a nat bind must be greater than=20 > (or equal to) the > > >>| lifetime of the sessions associated with the BIND. > > >> > > >>The lifetime attribute must neither be added to the NAT=20 > engine nor to the > > >>firewall engine, but it could. This lifetime attribute=20 > can be kept in the > > >>MIDCOM stack, and the stack must take about all other timers, e.g. > > >>the nat bind time must be greater or equal to the policy=20 > rule lifetime. > > >> > > >=20 > > >=20 > > > The MIDCOM stack you are refering to on a middlebox is=20 > merely a MIDCOM > > > specific extension module that manipulates the middlebox=20 > resource objects, > > > right. Given that these objects are quite granular and an=20 > intrinsic part of > > > NAT and firewall engines, how do you suppose the lifetime=20 > timers for these > > > objects can be maintained in an independent module away=20 > from the NAT and > > > firewall engines? I would think, the natural thing would=20 > be to associate > > the > > > timer attribute as part of the NAT/Firewall objects, and=20 > specify the timer > > > routines that process the timeouts as part of "MIDCOM=20 > extension module". > > >=20 > > > BTW, What are your thoughts on the MaxIdletime attribute? > > >=20 > > >=20 > > >>There are some functions of MIDCOM that must not be=20 > necessary supported > > >>by the middlebox engines, like grouping firewall rules=20 > and NAT bindings > > >>into a single policy rule. This applies to the lifetimers=20 > as well. These > > >>functions may be only implemented in the MIDCOM stack. > > >> > > >=20 > > >=20 > > > Once again, I believe, group-ID and Owner-Id attributes=20 > will need to be > > > associated with the individual NAT/firewall objects.=20 > Routines that do the > > > manipulation based on group IDs and Owner-IDs can be part=20 > of "MIDCOM > > > extension module". > > >=20 > > >=20 > > ...> > >=20 >=20 >=20 > =3D=3D=3D=3D=3D >=20 >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Aug 20 22:51:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27374 for ; Wed, 20 Aug 2003 22:51:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pfXV-0002kt-Aa for midcom-archive@odin.ietf.org; Wed, 20 Aug 2003 22:51:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7L2p5Wg010588 for midcom-archive@odin.ietf.org; Wed, 20 Aug 2003 22:51:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pfXR-0002kG-HC; Wed, 20 Aug 2003 22:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pfXB-0002js-4s for midcom@optimus.ietf.org; Wed, 20 Aug 2003 22:50:45 -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 WAA27346 for ; Wed, 20 Aug 2003 22:50:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pfX7-00041l-00 for midcom@ietf.org; Wed, 20 Aug 2003 22:50:41 -0400 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by ietf-mx with esmtp (Exim 4.12) id 19pfX7-00041h-00 for midcom@ietf.org; Wed, 20 Aug 2003 22:50:41 -0400 Received: from mail pickup service by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC; Wed, 20 Aug 2003 22:48:25 -0400 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Aug 2003 11:37:50 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by bastion.cox.com (8.11.6+Sun/8.11.6) with SMTP id h7KFbPO01638; Wed, 20 Aug 2003 11:37:25 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19pUb1-0003NU-Ff for ietf-announce-list@asgard.ietf.org; Wed, 20 Aug 2003 11:09:59 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19pUaB-0003LR-Lu for all-ietf@asgard.ietf.org; Wed, 20 Aug 2003 11:09:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12922; Wed, 20 Aug 2003 11:09:01 -0400 (EDT) Message-Id: <200308201509.LAA12922@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, 20 Aug 2003 11:09:01 -0400 Precedence: bulk X-OriginalArrivalTime: 20 Aug 2003 15:37:56.0307 (UTC) FILETIME=[06E27A30:01C36731] Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-04.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Protocol Semantics Author(s) : M. Stiemerling et al. Filename : draft-ietf-midcom-semantics-04.txt Pages : 61 Date : 2003-8-20 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-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-semantics-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-semantics-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-20112445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-20112445.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 Aug 20 23:38:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29585 for ; Wed, 20 Aug 2003 23:38:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pgGz-0004y9-NB for midcom-archive@odin.ietf.org; Wed, 20 Aug 2003 23:38:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7L3c5Zi019098 for midcom-archive@odin.ietf.org; Wed, 20 Aug 2003 23:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pgGv-0004wm-P5; Wed, 20 Aug 2003 23: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 19pgGM-0004oT-Ik for midcom@optimus.ietf.org; Wed, 20 Aug 2003 23:37:26 -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 XAA29432 for ; Wed, 20 Aug 2003 23:37:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pgGK-0004ZH-00 for midcom@ietf.org; Wed, 20 Aug 2003 23:37:24 -0400 Received: from web40406.mail.yahoo.com ([66.218.78.103]) by ietf-mx with smtp (Exim 4.12) id 19pgGI-0004Xt-00 for midcom@ietf.org; Wed, 20 Aug 2003 23:37:22 -0400 Message-ID: <20030821033652.15173.qmail@web40406.mail.yahoo.com> Received: from [66.224.113.194] by web40406.mail.yahoo.com via HTTP; Wed, 20 Aug 2003 20:36:52 PDT Date: Wed, 20 Aug 2003 20:36:52 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] Re: Comments on the Semantics draft (draft-ietf-midcom-semantics-03.txt) To: "Harrington, David" , Tom Taylor Cc: Martin Stiemerling , midcom@ietf.org, stiemerling@ccrle.nec.de, quittek@ccrle.nec.de In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BAEA93FA@NHROCMBX1.ets.enterasys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Well, it clearly is dated (supposed to have expired in 05/03). I was able to get the draft with the followign URL, however. http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-05.txt The new draft (rev 6) should be out in a couple of days. regards, suresh --- "Harrington, David" wrote: > Hi, > > I cannot locate a current copy of the NAT MIB. Did the I-D expire? Did > it ever move to an RFC? > > dbh > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > > Sent: Saturday, August 16, 2003 7:04 PM > > To: Tom Taylor > > Cc: Martin Stiemerling; midcom@ietf.org; > > stiemerling@ccrle.nec.de; quittek@ccrle.nec.de > > Subject: [midcom] Re: Comments on the Semantics draft > > (draft-ietf-midcom-semantics-03.txt) > > > > > > > > --- Tom Taylor wrote: > > > I don't think MIDCOM is about control of NAT sessions, in > > your terminology. > > > MIDCOM > > > installs BINDs and maps, and the NAT enables sessions > > within that framework. > > > > > It would be nice, if that was so. But, that is not the case. > > There are several > > deployments of symmetric NAPT devices that use different > > BINDings for the same > > (address,port) while connecting to different sessions. > > > > > As for the distinction between rule lifetime and > > maxIdleTime, let me make > > > this proposal: > > > - NATs can continue to enforce maxIdleTime, if this is > > seen as an effective > > > means > > > of resource conservation > > > - however, the policy introduced by policy rule lifetime > > overrides: when > > > the > > > lifetime expires, any session existing by virtue of that > > policy rule is > > > terminated. > > > > > > > OK. However, the semantics document need to recognize the > > MaxIdleTime as a > > parameter in itself and allow that to be set. > > > > cheers, > > suresh > > > > > Pyda Srisuresh wrote: > > > > > > > Martin, > > > > > > > > Sorry for the delay. Please see my comments inline. > > > > > > > > <... stuff deleted> > > > ... > > > > > > > > > > > > > > >>| > > > >>| 5. Policy rule: The definition says, this shoudl be > > (condition+Action). > > > >>| However, I had seen several instances where a NAT-BIND > > is referred as a > > > >>| Policy rule. Sounds like, you were using a single policy-rule > > > >>abstract to > > > >>| refer to several middlebox entities. It woudl help to > > state the abstract > > > >>| type you are refering to in the rule. ex: map, BIND, > > session etc. > > > >> > > > >>OK, I see the point. Indeed we refer in the policy rule > > to a construct > > > >>that may consists out of NAT-BIND and firewall rules. So > > the policy rule > > > >>is meant as an 'umbrella'. > > > > > > > > > > > > In that case, you might want to define a > > "transaction-entity", which is an > > > > abstract construct that would refer to any middlebox > > resource that may be > > > > dynamically controlled/monitored via the midcom protocol. > > > > > > > > > > > >>| > > > >>| I believe, a NAT-BIND constitutes an action; NAT address map > > > >>constitutes a > > > >>| condition (along with an implicit static/dynamic BIND action); > > > >>and, a NAT > > > >>| session, identified by its inside and outside session > > tuples (alogn with > > > >>| the BINDs) will constitute a rule. > > > >>| > > > >>| 6. Section 2.3.1 - Configuration transactions > > > >>| a) You mention NAT bindings. But, there is no mention of NAT > > > >>sessions. For > > > >>| example, multiple NAPT sessions using beargn the same source-IP, > > > >>| Source-port might use different PORT bindings or the > > same PORT binding. > > > >>| This is essentially the difference between symmetric > > NAT and cone NAT. > > > >>| One permits p2p NAT sessiosn and the other doesnt. In > > essence, NAT > > > >>| binding and NAT session must be treated as independent > > controllable > > > >>| entities. > > > >> > > > >>I see the point, that for a single NAT binding several > > NAT sessions may > > > >>run at the same time. And I see the point that these two > > have to be > > > >>differentiated. The MIDCOM protocol does only configure > > NAT bindings > > > >>and is not aware about the actual NAT session (a binding could be > > > >>configured by not used). > > > > > > > > > > > > Right. What I am saying is that the MIDCOM protocol ought > > to be aware of > > > > "NAT session" construct in addition to "NAT binding". > > This is because, > > > there > > > > could be instances where setting a NAT binding is > > adequate (ex: basic NAT > > > > and p2p-NAT). Other times, the agent might need to setup > > individual NAT > > > > sessions. > > > > > > > > > > > >>By now I don't see the impact on the semantics. It is > > just a problem > > > >>of mentioning that there are NAT sessions or even more? > > > >> > > > > > > > > The impact is to add an additional construct for "NAT > > session" into the > > > > semantics. > > > > > > > > I also had a question (later on below) about setting > > ownership on a NAT map > > > > entry. This would, in turn, call for a new construct for > > "NAT map" in the > > > > semantics. > > > > > > > > > > > >>| > > > >>| b) You mention lifetime of a rule. Typically, NAT > > devices (that include > > > >>| an ALG) do not have this attribute. They have a MaxIdletime for > > > >>BINDs and > > > >>| sessions. Agents will want to set the MaxIdletime for a resource > > > >>| (NAT-BIND or NAT-session). The lifetime attribute is > > new and may be a > > > >>| fine thing to add to NAT maps, binds and sessions. This > > will ensure that > > > >>| agent imposed entities disappear after the specified > > time. But, there is > > > >>| a dependency graph here. lifetiem of a nat map must be > > greater than (or > > > >>| equal to) the lifetime of the nat binds and nat > > sessions, it generates. > > > >>| Further, lifetime of a nat bind must be greater than > > (or equal to) the > > > >>| lifetime of the sessions associated with the BIND. > > > >> > > > >>The lifetime attribute must neither be added to the NAT > > engine nor to the > > > >>firewall engine, but it could. This lifetime attribute > > can be kept in the > > > >>MIDCOM stack, and the stack must take about all other timers, e.g. > > > >>the nat bind time must be greater or equal to the policy > > rule lifetime. > > > >> > > > > > > > > > > > > The MIDCOM stack you are refering to on a middlebox is > > merely a MIDCOM > > > > specific extension module that manipulates the middlebox > > resource objects, > > > > right. Given that these objects are quite granular and an > > intrinsic part of > > > > NAT and firewall engines, how do you suppose the lifetime > > timers for these > > > > objects can be maintained in an independent module away > > from the NAT and > > > > firewall engines? I would think, the natural thing would > > be to associate > > > the > > > > timer attribute as part of the NAT/Firewall objects, and > > specify the timer > > > > routines that process the timeouts as part of "MIDCOM > > extension module". > > > > > > > > BTW, What are your thoughts on the MaxIdletime attribute? > > > > > > > > > > > >>There are some functions of MIDCOM that must not be > > necessary supported > > > >>by the middlebox engines, like grouping firewall rules > > and NAT bindings > > > >>into a single policy rule. This applies to the lifetimers > > as well. These > > > >>functions may be only implemented in the MIDCOM stack. > > > >> > > > > > > > > > > > > Once again, I believe, group-ID and Owner-Id attributes > > will need to be > > > > associated with the individual NAT/firewall objects. > > Routines that do the > > > > manipulation based on group IDs and Owner-IDs can be part > > of "MIDCOM > > > > extension module". > > > > > > > > > > > ...> > > > > > > > > > ===== > > > > > > _______________________________________________ > > 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 Sat Aug 23 02:19:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21713 for ; Sat, 23 Aug 2003 02:19:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qRju-000671-KH for midcom-archive@odin.ietf.org; Sat, 23 Aug 2003 02:19:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7N6J6W0023494 for midcom-archive@odin.ietf.org; Sat, 23 Aug 2003 02:19:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qRjq-00066Q-PE; Sat, 23 Aug 2003 02:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qRjE-00064p-L3 for midcom@optimus.ietf.org; Sat, 23 Aug 2003 02:18:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21059 for ; Sat, 23 Aug 2003 02:18:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qRim-0006eO-00 for midcom@ietf.org; Sat, 23 Aug 2003 02:17:56 -0400 Received: from web40402.mail.yahoo.com ([66.218.78.99]) by ietf-mx with smtp (Exim 4.12) id 19qRil-0006eC-00 for midcom@ietf.org; Sat, 23 Aug 2003 02:17:55 -0400 Message-ID: <20030823061726.74344.qmail@web40402.mail.yahoo.com> Received: from [67.164.29.130] by web40402.mail.yahoo.com via HTTP; Fri, 22 Aug 2003 23:17:26 PDT Date: Fri, 22 Aug 2003 23:17:26 -0700 (PDT) From: Pyda Srisuresh To: Martin Stiemerling , midcom@ietf.org Cc: stiemerling@ccrle.nec.de, quittek@ccrle.nec.de, taylor@nortelnetworks.com In-Reply-To: <18570000.1061208377@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [midcom] RE: Comments on the Semantics draft (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: , --- Martin Stiemerling wrote: > Hi, > > --On Saturday, August 09, 2003 22:37:28 -0700 Pyda Srisuresh > wrote: > [...] > |> It is in the section 2.1.7 "Peer identifiers". Perhaps the > |> heading is misleading and should be changed to "Agent identifier". > |> The bottom line of this section is that a middlebox must use > |> some sort of agent ID, but can use for instance the TCP socket ID. > | > | OK. I am just looking for a statement that says that agent identifiers > | must be middlebox unique. > > That statement is now in the text of section 2.1.7. > OK. Sounds good. > > |> | > |> | I believe, a NAT-BIND constitutes an action; NAT address map > |> constitutes a > |> | condition (along with an implicit static/dynamic BIND action); > |> and, a NAT > |> | session, identified by its inside and outside session tuples (alogn > |> | with the BINDs) will constitute a rule. > |> | > |> | 6. Section 2.3.1 - Configuration transactions > |> | a) You mention NAT bindings. But, there is no mention of NAT > |> sessions. For > |> | example, multiple NAPT sessions using beargn the same source-IP, > |> | Source-port might use different PORT bindings or the same PORT binding. > |> | This is essentially the difference between symmetric NAT and cone NAT. > |> | One permits p2p NAT sessiosn and the other doesnt. In essence, NAT > |> | binding and NAT session must be treated as independent controllable > |> | entities. > |> > |> I see the point, that for a single NAT binding several NAT sessions may > |> run at the same time. And I see the point that these two have to be > |> differentiated. The MIDCOM protocol does only configure NAT bindings > |> and is not aware about the actual NAT session (a binding could be > |> configured by not used). > | > | Right. What I am saying is that the MIDCOM protocol ought to be aware of > | "NAT session" construct in addition to "NAT binding". This is because, > | there could be instances where setting a NAT binding is adequate (ex: > | basic NAT and p2p-NAT). Other times, the agent might need to setup > | individual NAT sessions. > > The goal was and is to keep the protocol itself quite simple and to enable > MIDCOM > agent to get things working through middleboxes. For a management protocol > it would be clear that this session and binding configuration is needed. > The MIDCOM semantics focus on dynamic configuration. > OK. Sounds like, we are in synch. I.e., the agent is able to set NAT bindings as well as NAT sessions, right? > [...] > |> The lifetime attribute must neither be added to the NAT engine nor to the > |> firewall engine, but it could. This lifetime attribute can be kept in the > |> MIDCOM stack, and the stack must take about all other timers, e.g. > |> the nat bind time must be greater or equal to the policy rule lifetime. > |> > | > | The MIDCOM stack you are refering to on a middlebox is merely a MIDCOM > | specific extension module that manipulates the middlebox resource objects, > | right. Given that these objects are quite granular and an intrinsic part > | of NAT and firewall engines, how do you suppose the lifetime timers for > | these objects can be maintained in an independent module away from the > | NAT and firewall engines? I would think, the natural thing would be to > | associate the timer attribute as part of the NAT/Firewall objects, and > | specify the timer routines that process the timeouts as part of "MIDCOM > | extension module". > > How and where the lifetimes are maintained is not part of the protocol, > since > MIDCOM is concered with the communication between agent and middlebox. > If the lifetimes are stored within the MIDCOM stack or within the actual > middlebox engine is more an operational or implementation issue. > For instace with the lifetime in MIDCOM stack approach you can extend > easily existing firewalls and NATs, without digging into the middlebox > engine. > I agree, this is an implementation issue. We can move on. > | > | BTW, What are your thoughts on the MaxIdletime attribute? > > The MaxIdleTime needs to be considered by the implementation, but > not by the middlebox. Meaning? NAT middlebox uses this extensively. > The MIDCOM stack can watch the MaxIdleTime > and include it into its operational logic. > The Midcom logic Shoudl be able to both watch and set the MaxIdleTime. Several ALGs, including the DNS-ALG use this attribute. > | > |> There are some functions of MIDCOM that must not be necessary supported > |> by the middlebox engines, like grouping firewall rules and NAT bindings > |> into a single policy rule. This applies to the lifetimers as well. These > |> functions may be only implemented in the MIDCOM stack. > |> > | > | Once again, I believe, group-ID and Owner-Id attributes will need to be > | associated with the individual NAT/firewall objects. Routines that do the > | manipulation based on group IDs and Owner-IDs can be part of "MIDCOM > | extension module". > > The identification can be part of the middlebox engine, but it must no be. > That depends on implementation and probably vendor's believe. > I am not parsing what you say. I assume what you saying is that you dont care how it is implemented. > | > |> | > |> | 7. Ownership (NAT maps, binds): > |> | Say, a NAT address map is scoped out by multiple agents into multiple > |> | sub-rules. > | > | OK. I guess, I wasnt clear. Let me take an example. > | Say, you have a NAPT map configured as "10.0.0.0/8 be mapped to address > | 142.29.48.20". > | Say, you have two agents - agent-1 and agent-2. Say, both these agents > | assign group-IDs to subsets of TCP/UDP ports as follows. > | > | Agent-1, group-1: "10.1.0.0/16 mapped to > | 142.29.48.20:31001-32000" > | Agent-1, group-2: "10.2.0.0/16 mapped to > | 142.29.48.20:32001-33000" > | Agent-2, group-3: "10.3.0.0/16 mapped to > | 142.29.48.20:33001-34000" > | Agent-2, group-4: "10.4.0.0/16 mapped to > | 142.29.48.20:34001-35000" > > Thanks, now is see the point. With the NAT MIB you can do these kind of > configuration at the NAT. But in the MIDCOM semantics the target is not > to configure complete sub-network mappings. The target is to enable > dedicated bindings for end hosts. The semantics talk about A0, A1, A2, > and A3. Whereas, A0 and A3 are the addresses' and ports of two endhosts. So > the > configuration of the NAT would be: > Agent-1, group1, A0 mapped to A2, A0={IP Address, port(s)} A2={IP Address, > port(s)} > > So the goal is to create exactly for the combination of A0, A1, A2, and A3 a > binding and probably a session (and nail it down). > Sessions should be removed upon removal of the corresponding binding. > Perhaps > we need to add text to the semantics to express that explicitly. > Well, what I am trying to say here is a Midcom agent can own a map resource, NAT coudl still derive BINDs and sessions out of the address map the midcom agent owns. The BINDs and sessions generated by NAT will still retain the agent as the owner. Midcom agent is not necessarily required to create all the BINDs and sessions it owns. It could. But, not a requirement. > [...] > | > | Sorry, my oiginal text was not clear. Hope the above explanation helps. > > Thanks, now I got it! > > | > |> | > |> | 8. Note, there shoudl be an ownership attribute in policy-rule > |> request and > |> | response (Listed in section 4.1, but not specified on 2.3.7, 2.3.8). > |> > |> 2.3.7 and 2.3.8 specifiy the Policy Reserve Rule and Policy Enable Rule. > |> In section 4.1 the Status transactions are used, but not the > |> reserve/enable > |> transactions. The ownership attribute is not required in reserve/enable > |> transactions since agents are only allowed to access their > | ^^^^^ > | How will a middlebox know what is theirs if there isnt an agent ownership > | assigned. I believe, an agent is instantiating its ownership on a > | middlebox resource when the agent enables it. > > An agent becomes the owner of a middlebox resource when he enables it. > The agent can only manipulate policy rules with PRR and PER where he is the > owner. The middlebox must of course keep track of the ownership of a > particular > policy rule internally. > > > |> | > |> | 9. Section 2.3.7(PRR): > |> | PRR seems to be a construct meant specifically for NAT middleboxes. The > |> | disctinction between the two is apparently to do with when the lifetime > |> | clock starts ticking. Requring NAT middleboxes to maintain PRR seems > |> | needlessly complex. I would suggest doign away with the PRR construct. > |> | PER should suffice, so long as the agent can set the PER just as the > |> | construct is required. > |> > |> PRR is required and requested by some vendors, since you can nail down > |> ports and IP address before you know anything else of your communcation > |> partner. > | > | Perhaps I should restate what I said. I believe, you were using the term > | PRR to reserve IP addresses/ports and the term PER to setup address/port > | BINDs. I was suggesting to use a single term PER to ascertain ownership > | of NAT address map entries, BIND entries and session entries. > | > |> Using only PER with wildcarding may results in some not needed > |> security risks, but is indeed requested by some people as well. > | > | By PER with wild-carding, did you mean multiple BINDs? If so, why do you > | believe, that would be a security risk? > > PER with wildcarding would result in one bind (A0 to A2). For combined > NAT and firewall this would result in: Allow everything from outside to A2 > (and > thus to A0). Some people see this as a security risk, since you open your > firewall/NAT > wide for everybody. In some scenarios, like SIP early media, this wide open > case > is explicitly needed, since it is not known from where the first data is > coming. > OK, I understand. PERs that are not session specific (ex; BINDs) are wild-cards. While they can be security risks, that neednt be the case. Anyways, something tell me we are not seeing things eye to eye here. Do you see a problem with using a single PER term to ascertain ownership of NAT address map entries, BIND entries and session entries. Thanks. > > Cheers > Martin > cheers, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Aug 25 11:20:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23669 for ; Mon, 25 Aug 2003 11:20:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rJ8p-0003Ua-Uq for midcom-archive@odin.ietf.org; Mon, 25 Aug 2003 11:20:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PFKMN3013390 for midcom-archive@odin.ietf.org; Mon, 25 Aug 2003 11:20:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rJ8h-0003TC-QW; Mon, 25 Aug 2003 11:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rIkv-0002bL-QV for midcom@optimus.ietf.org; Mon, 25 Aug 2003 10:55:41 -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 KAA22330 for ; Mon, 25 Aug 2003 10:55:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rIkt-0002CV-00 for midcom@ietf.org; Mon, 25 Aug 2003 10:55:39 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19rIks-0002CM-00 for midcom@ietf.org; Mon, 25 Aug 2003 10:55:38 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 25 Aug 2003 07:55:08 -0700 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 h7PEt78s008915 for ; Mon, 25 Aug 2003 07:55:07 -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.6-GR) with ESMTP id ALH38745; Mon, 25 Aug 2003 07:55:06 -0700 (PDT) Message-Id: <200308251455.ALH38745@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 25 Aug 2003 10:55:05 -0400 Subject: [midcom] WG last call on 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: , We are starting WG last call on the most recent version of the semantics document (draft announcement appended). Please give it a read to make sure you agree with the changes introduced since the last version. WG last call closes on Tuesday, 9 September. Thanks, Melinda ------- Forwarded Message Date: Wed, 20 Aug 2003 11:09:01 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: midcom@ietf.org Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-04.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 et al. Filename : draft-ietf-midcom-semantics-04.txt Pages : 61 Date : 2003-8-20 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-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-semantics-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-semantics-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-20112445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-04.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-20112445.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 Wed Aug 27 02:40:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26967 for ; Wed, 27 Aug 2003 02:40:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rsqF-0006sR-UC for midcom-archive@odin.ietf.org; Wed, 27 Aug 2003 01:27:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R5RYUO026400 for midcom-archive@odin.ietf.org; Wed, 27 Aug 2003 01:27:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rn8X-0006ai-DP; Tue, 26 Aug 2003 19:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rhKg-0000LU-NV for midcom@optimus.ietf.org; Tue, 26 Aug 2003 13:10:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15569 for ; Tue, 26 Aug 2003 13:10:08 -0400 (EDT) From: Tat.Chan@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rhKe-0003ds-00 for midcom@ietf.org; Tue, 26 Aug 2003 13:10:12 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19rhKe-0003dp-00 for midcom@ietf.org; Tue, 26 Aug 2003 13:10:12 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7QHABG16696 for ; Tue, 26 Aug 2003 12:10:12 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Aug 2003 12:10:11 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 26 Aug 2003 10:08:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Aug 2003 13:08:55 -0400 Message-ID: Thread-Topic: NAT types of commercial routers Thread-Index: AcNr9EYW5lmEOSzoR5aOmWL682vS+g== To: X-OriginalArrivalTime: 26 Aug 2003 17:08:57.0169 (UTC) FILETIME=[BC4A6410:01C36BF4] Content-Transfer-Encoding: quoted-printable Subject: [midcom] NAT types of commercial routers 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: quoted-printable Hi all, The STUN RFC describes several types of NATs based on their behaviors on = UDP traffic. Does anyone have a list of what commercial routers belong = to which types? If don't, can we start a list somewhere by reporting = what we know? I have tested a couple Netgear routers and they are full = cone. We tested a Linksys NR041 during SIPit13 and it appeared to be = Symmetric. Any one know of any restricted or port restricted NAT out = there? Thanks a lot! BR Tat Chan Senior Research Engineer Nokia Research Center NOKIA INC 5 Wayside Road, Burlington, MA 01803 Phone (781) 993-5776, Fax (781) 993-1907 tat.chan@nokia.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Aug 27 22:46:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05031 for ; Wed, 27 Aug 2003 22:46:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sABq-00005P-4W for midcom-archive@odin.ietf.org; Wed, 27 Aug 2003 19:59:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RNx2EJ000312 for midcom-archive@odin.ietf.org; Wed, 27 Aug 2003 19:59:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4oE-0000DV-BP; Wed, 27 Aug 2003 14:14:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s3Lj-0002Dm-JR for midcom@optimus.ietf.org; Wed, 27 Aug 2003 12:40:47 -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 MAA14992 for ; Wed, 27 Aug 2003 12:40:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s3Lh-0002Si-00 for midcom@ietf.org; Wed, 27 Aug 2003 12:40:45 -0400 Received: from pop018pub.verizon.net ([206.46.170.212] helo=pop018.verizon.net) by ietf-mx with esmtp (Exim 4.12) id 19s3Lh-0002Rd-00 for midcom@ietf.org; Wed, 27 Aug 2003 12:40:45 -0400 Received: from [192.168.1.100] ([151.199.24.202]) by pop018.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030827164014.EMOY11703.pop018.verizon.net@[192.168.1.100]>; Wed, 27 Aug 2003 11:40:14 -0500 From: Bryan Ford Organization: Massachusetts Institute of Technology To: Tat.Chan@nokia.com, Subject: Re: [midcom] NAT types of commercial routers Date: Wed, 27 Aug 2003 12:40:13 -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: <200308271240.13457.baford@mit.edu> X-Authentication-Info: Submitted using SMTP AUTH at pop018.verizon.net from [151.199.24.202] at Wed, 27 Aug 2003 11:40:14 -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 On Tuesday 26 August 2003 01:08 pm, Tat.Chan@nokia.com wrote: > Hi all, > > The STUN RFC describes several types of NATs based on their behaviors on > UDP traffic. Does anyone have a list of what commercial routers belong to > which types? If don't, can we start a list somewhere by reporting what we > know? I have tested a couple Netgear routers and they are full cone. We > tested a Linksys NR041 during SIPit13 and it appeared to be Symmetric. Any > one know of any restricted or port restricted NAT out there? That's exactly the type of information I'm trying to gather at my "NAT Check" page: http://pdos.lcs.mit.edu/~baford/nat/ ...although the program and the results submission form/results table currently don't use the exact terms "cone NAT", "symmetric NAT", etc. Also, NAT Check as it currently is might not collect all the information you could possibly want (e.g., it currently doesn't try to distinguish between "restricted cone NATs" and "port-restricted cone NATs", though it does distinguish between full cone NATs and [port] restricted cone NATs). I'd always welcome enhancements to NAT Check to make it gather more information or whatever. Cheers, Bryan _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom