MIDCOM Working Group C.Aoun Internet Draft Nortel Networks Category: Informational June 2002 Expires on December 2002 Middle Box discovery integration solutions within the Midcom architecture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Middle Box discovery is one of the problems that the Midcom architecture has not yet solved. This document compares two Middle box discovery solutions: The decoupled model where the Middle Box discovery is handled by a separate protocol than the MIDCOM protocol vs the combo model were the MIDCOM protocol and the discovery protocol are the same. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Introduction.....................................................2 2 Conventions used in this document................................3 3 Used Terminology.................................................3 4 The decoupled model analysis.....................................3 Aoun [Page 1] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 4.1Protocol interactions and protocol impacts in the decoupled model ...................................................................4 4.2 Triggering the MB discovery within the decoupled model.........4 4.3 Decoupled model latency estimations............................5 4.4 Decoupled model message sequence example.......................7 5 The combo model analysis........................................10 5.1 Protocol interactions and protocol impacts in the combo model.10 5.2Using the combo protocol when only NAT and Firewalls are deployed ..................................................................12 5.3 High level combo protocol requirements........................12 5.4 Triggering the MB discovery within the combo model............13 5.5 Combo model latency estimations...............................13 5.6 Combo model message sequence example..........................13 6 Comparison of the decoupled model Vs the combo model............17 7 Security considerations.........................................18 8 Conclusion......................................................18 9 References......................................................18 10 Acknowledgments................................................18 11 Author's Address...............................................18 12 Intellectual Property Statement................................19 13 Full Copyright Statement.......................................19 1 Introduction In [Caoun] a MB discovery solution is proposed, however it doesn't take into account the integration of the MB discovery within the MIDCOM architecture, but shows that it could be integrated as a "black box", i.e. it could be integrated without changing the base MIDCOM protocol. The reader is invited to read [Caoun] before reading this draft . This draft proposes two methods to integrate MB discovery, one completely separate from the MIDCOM protocol, i.e. the discovery is a complete black box, another method where the MIDCOM protocol is combined with a discovery protocol. The first method is termed the decoupled method; the second method, the combo method. This draft addresses all the scenarios referred to in [Caoun]. For simplicity reasons the draft will not discuss the edge Middle Box concept (discussed in [Caoun] )and will be focused on the simple discovery A concept (i.e. no Middle Box information policing at edge of policy domains). Aoun Informational - Expires December 2002 [Page 2] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3 Used Terminology MB: Middle Box- ref to the used terminology in [FRMWRK] MA: Midcom Agent - ref to the used terminology in [FRMWRK] MS: Midcom Server- The Midcom interface on the MB, terminology not yet defined within the Midcom WG AC: Application Client AS: Application Server- In this document the used terminology covers the application server function as well as its host. AP: Application Proxy DC: Discovery Client - Entity responsible for sending/receiving discovery messages DN: Discovery Node - Function that sits in a Middle Box, updates a discovery message. CC: Combo Client - Entity responsible for sending/receiving combo protocol messages CN: Combo Node - Function that sits in a Middle Box, updates (and replies to) combo protocol messages. AH: Application Host- Computing platform hosting an application 4 The decoupled model analysis This model proposes to use a protocol to discover MBs and a separate protocol to communicate with MBs (i.e. the MIDCOM protocol). The implications of this approach are analysed below. The current MIDCOM architecture requires that the MA is aware of which MB it needs to apply control on. In this model the architecture would remain unchanged, since the MA would be provided Aoun Informational - Expires December 2002 [Page 3] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 with the list of MBs with which it needs to communicate to allow traversal of a specific application packet flow. In [Caoun] there was an assumption that a protocol was transporting the MB information to MAs. In case this protocol is an existing application protocol, extensions to the application protocols will be required to carry the MB information. 4.1 Protocol interactions and protocol impacts in the decoupled model When integrating the discovery model A discussed in [Caoun], the following protocol interactions would occur: MA | \ Protocol transporting | \ < -- MIDCOM MB information --> | \ | \ DC -------DN ^ | MB discovery protocol Model A Figure 1 In model A it could be possible to extend the application protocol to provide in real time the MB information to the MA. Midcom protocol extensions will be required to carry the MB information else a different protocol could be used. That protocol could be based on using a simplified version of the discovery protocol could be used to handle the required messages (this was implied in [Caoun]). 4.2 Triggering the MB discovery within the decoupled model In the decoupled model the MB discovery could either be initiated for every packet stream or when the stream is unknown to the MA. The reason why in the second case the discovery is triggered from the MA and not the DC is that the DC is not aware of all the interacting MAs, and therefore the MA is better positioned to Aoun Informational - Expires December 2002 [Page 4] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 provide all the required information (DCToken, MA contact information). The main problem with the method where the MA triggers the discovery for unknown streams is that it will need to cache the information (since it needs to distinguish between known and unknown paths). In case the MA runs on the AH there is no issue, but in case the MA handles several AHs there is a scalability problem. Even if the information was cached, a link failure or network congestion will change routes and different MBs could be traversed and the cached information is no longer applicable. [Caoun] addresses this problem, but its solution will require non negligible modification to the application's behaviour as well as to inter MB communications. In addition the second method requires that the request for the MB discovery be integrated either in the existing application protocol or in another specific protocol (this is obviously required when the DC is not co-hosted with the MA). When the DC triggers the discovery it needs to know the MA deployed in the remote end DC network, it also needs authorization tokens that will allow the DC to discover the MBs. The direct conclusion is that the best entity to trigger the discovery is the entity that will provide the authorization tokens to the DCs, the MA(s) contact information and the remote DC contact information (ref to [Caoun]). As a result this entity could be the MA when the MA is not co-hosted with the DC or another entity providing this information (more likely to be an application proxy). 4.3 Decoupled model latency estimations The decoupled model will be impacted by the MB discovery protocol delays as well as the MIDCOM delays. Long delays may have some application impacts; especially ones requiring application data transfers after 1 or 2 seconds of session establishment (VoIP is a typical example). The MB discovery protocol delays are as follows: -MB discovery trigger request (in case the discovery is not done on a stream by stream basis) -MB discovery protocol round trip delay -MB discovery message treatment on every traversed MB Aoun Informational - Expires December 2002 [Page 5] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 -MB discovery result notification to the MA (when the DC is not co-hosted with the MA) The MIDCOM protocol delays until resources are reserved (i.e. policy rules are installed on the MBs): -MA resource request (one way delay between MA and MB) -MB authorization policy lookup -MB resource reservation confirmation/refusal (one way delay between MB and MA) Aoun Informational - Expires December 2002 [Page 6] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 4.4 Decoupled model message sequence example +--Foo.com-----------------+ +--Bar.com-----------+ | ++++ | DMZ | +DMZ ++++ + | +AC+-|--MB1 MB2 MA1| +MA2 MB5 +AC+ + | +DC+ | | The NET + MB8-+DC+ + | ++++ MB3 | + MB6 ++++ + | AH1 | + AH2 + | MB4 | + MB7 + +--------------------------+ +--------------------+ The example discussed in this section addresses communications between 2 networks Foo.com and Bar.com, MB1 and MB8 are mainly used for packet filtering purposes, MB2 to MB7 are used mainly for NAT purposes. All MBs are configured as DNs (ref to [Caoun]), discovery model A is used. MA1 triggers the MB discovery after receiving an incoming application session initiation request from MA2. MA1 triggers the MB discovery on packet stream by packet stream basis (i.e no caching mechanism is used). MA1 will request (or has already received) the DC2 contact information) and the authorization token to discover MBs, in the bar.com domain, from MA2. The regular application messages (session application request and replies with used resources for the session) are not shown for simplicity. The authorization token generation mechanism uses the methods discussed [Lhamer], for simplicity the authorization token generation will be handled in a separate draft where the authentication of the token generator is also discussed. Aoun Informational - Expires December 2002 [Page 7] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 DC1 DN1 DN3 MA/AP1 MA/AP2 DN7 DN8 DC2 1-Session-request(DC2,MA1,MA2,DC1Token,DC2Token) <------------------------- 2-Session Ack -------------------------> 3-Discover(DC1Token,DC2Token,DC2) ----> 4-Discover(DC1Token,DC2Token,DC2,{DN1,FW}) ---------> 5-Discover (DC1Token,DC2Token,DC2,{DN3,NAT},{DN1,FW}) ---------------------------> 6-Discover (DC1Token,DC2Token,DC2,{DN7,NAT},{DN3,NAT},{DN1,FW}{BDN3,NAT,FW}) -----> 7-Discover (DC1Token,DC2Token,DC2,{DN8,NAT},{DN7,FW},{DN3,NAT} ,{DN1,FW}) -----> 8-Discover_returnpath(DC2Token,DC1Token, Discover(DC1Token,DC2Token,DC2, {DN8,NAT},{BDN7,FW},{DN3,NAT},{DN1,FW}) < ----- 9- Discover_returnpath(DC2Token,{DN8,FW}, Discover(DC1Token,DC2Token,DC2, {DN8,NAT},{DN7,FW},{DN3,NAT},{DN1,FW}) ) <---- . . . 13- Appmessage{Discovered MBs, DC1Token,DC2Token, MA1,MA2) ------------------------------ > 14- Appmessage{Ack} < ----------------------------- 15- Appmessage{ Discovered MBs, DC1Token,DC2Token, MA1,MA2 -------- > 16- Appmessage {Ack} < ------- Aoun Informational - Expires December 2002 [Page 8] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 DC1 DN1 DN3 MA/AP1 MA/AP2 DN7 DN8 DC2 17-Policy_rule_request(openpinhole) < ------------------- 18- Policy-rule_request_ack(pinhole_opened) -------------------- > 19- Policy_rule_request(NAT bind allocation) < ---------- 20- Policy_rule_request_ack(NAT bind allocated(translated address:port)) 21 - Policy_rule_request(NAT bind_allocation) --------- > 22 - Policy-rule_request_ack(NAT bind allocated(translated address:port)) < ------- 23- Policy_rule_request(openpinhole) -------------- > 24- policy_rule_request(pinhole_openned) <---------------- When the discover_returnpath message reaches DC1, DC1 will then send the discovered MBs details to both MA1 and MA2 through the application protocol (as MA1 and MA2 are co-hosting with Application proxies and as DC1 runs on AH1). A realistic way for DC1 to provide the MB details to MA2 is by going through MA1, as MA1 is the point of contact of MA2 in the foo.com network. The tokens include the relation with the particular application session and therefore the correlation with an application session is straightforward Every DN will act as it did when the discover message traversed it, i.e. add its object to the message after checking if the discovery requestor is allowed to discover it. MA1 will check with its list of associated MBs if DN1,3,7 and 8 are part of that list. It will send Midcom policy rule requests only to MB1 and MB3. MA2 will do the same and will send MIDCOM policy rule requests to MB7 and MB8. Once the policy rule requests are replied to by the MBs, AP1 will provide AP2 the new address and port on which the application Aoun Informational - Expires December 2002 [Page 9] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 session could terminate on AH1; AP2 will do the same by providing AP1 with the same information relevant to AH2. AP1 will then relay the information to AH1, AP2 will do the same by relaying the received information to AH2. After that the application session could start and media will start flowing between AH1 and AH2. Note: DN contact information = MB contact information, currently the MIDCOM protocol doesn't take into account scenarios where an MB could be natting another MB. [Caoun] addresses the previous problem but only for the discovery protocol. The MAs will be provided with reachable MB information, because every MB applying NAT on the path looks at previous MB's object and updates the previous MB contact information. The example show that the decoupled approach will work but it implies additional delays and processing. 5 The combo model analysis One of the fundamental differences of the combo model, vs the decoupled model, is that the MA could request policy rules to be installed on the MBs, that might be on the path without knowing that these MBs will be traversed. There are 2 ways to use the combo model, one could be request policy rules installation against known functions on traversed MBs, another way could include the previous as well as request the traversed MBs to report other functions that are not yet known to the MAs (only if the MA has the right authorization). Fundamentally the MB discovery capabilities included in the combo model are slightly different from the ones discussed in [Caoun] since the MBs are discovered and are replying back to certain MB resource requests. In the combo model analysis, the author did not restrict the MA to discover MB functions related only to the requested policy rule installations but to other functions that the MA may be authorized to discover. Hence some of the concepts discussed in [Caoun] still apply. The Combo Node has almost the same responsibility as the DN except that it handles Midcom policy rule requests as well. 5.1 Protocol interactions and protocol impacts in the combo model When implementing the discovery models (A or B) concepts discussed in [Caoun], the benefits of the combo model are not easily proven Aoun Informational - Expires December 2002 [Page 10] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 when the MA is not co-hosted with the CC (i.e. the MA runs on a separate platform from the AH). MA |\ Protocol transporting | \ < ---- Combo protocol the MB information --> | \ | \ CC ------DN ^ | combo protocol Model A When the MA co-hosts the DC, the benefits of the combo approach are obvious: MA/CC ---------CN/MS ^ | combo protocol Model A In the rest of the draft, we shall only discuss the case where the MA is co-hosting the CC function. The authorization tokens discussed in [Caoun] and [Lhamer] could be provided through the application protocols or with other means. The discovery concepts discussed in [Caoun] are not completely required, since the MA could request certain resources to be reserved before knowing that MBs are traversed. The MA could request that the traversed MBs allow traversal of the packet stream and provide the translated address and port pair. The NAT and packet filtering functions are discussed here since the industry is trying to solve this issues first, other MB functions could be implicitly taken into account in the combo protocol. In parallel, the DC function embedded in the CC could request MBs to notify the CC of their presence on the bearer path. Even if NAT and packet filtering were assumed to be applied, the discovery response (that includes the information on the traversed MBs) will provide other MB functions that are possibly applied. Aoun Informational - Expires December 2002 [Page 11] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 The combo protocol could be a protocol using functional specific objects, an object type for MIDCOM and an object type for MB discovery. When the CC receives a MB discovery object, it will check if it is consistent with the information already expected by the MA (i.e. if more than NAT and packet filtering were encountered); if there are inconsistencies it will provide all the discovered MBs and their applied functions. 5.2 Using the combo protocol when only NAT and Firewalls are deployed When the MBs on the path of the packet streams are expected to apply functions that are only either NAT or packet filtering, then the discovery objects discussed in [Caoun] are not required to be sent. However the remote end Combo Client, contact information should be used within the combo protocol in order for the combo protocol to reach the remote end host. Since the discovery object may or may not be present, the authorization tokens and the remote end combo client information (allowing the MBs to route properly the combo protocol message) will be included in the header of the combo message. This will avoid inserting the information in the MIDCOM object and the discovery object. Both discovery model A or B concepts are still applicable, as discussed previously for simplicity we shall not discuss the edge MB concept in this draft and therefore model B is not discussed (but the concept still applies to it): For model A: -When a MB is traversed by the combo message containing the MIDCOM object (which includes a policy rule request), the MB adds its response in the end to end combo message -When the MA receives the end to end combo message it will know that all the traversed MBs have replied to the policy rule request. In both model A and B, the MB will need to do a policy lookup to see if the MA is authorized. The authorization models discussed in [Lhamer] are still applicable in the combo approach. 5.3 High level combo protocol requirements The combo protocol should be able to carry objects, the combo protocol messages could be: Aoun Informational - Expires December 2002 [Page 12] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 -A simple request and a reply end to end message type being sent by the remote end combo protocol client (acting similarly to the remote end DC client) (applies to Model A concept) 5.4 Triggering the MB discovery within the combo model The MA would always send Midcom objects, and potentially discovery objects when the traversed policy domains will be applying more than NAT and firewalls. Since the MIDCOM policy rules requests objects are being sent anyway the burden of discovering the MBs goes away. Obviously the caching option used in the decoupled model is not applicable. 5.5 Combo model latency estimations The combo model has much fewer delays than the decoupled model since the discovery and the MIDCOM messaging are done at the same time. The combo protocol messaging delays are as follows: -Combo protocol between the MA and the remote end combo client round trip delay -Treatment of the combo protocol message by every traversed MB 5.6 Combo model message sequence example +--Foo.com-----------------+ +--Bar.com-----------+ | +++++ | DMZ | +DMZ +++++ + | +MA1+-|--MB1 MB2 | + MB5 +MA2+ + | +AC + | PS1 | The NET +PS2 MB8-+AC + + | +CC + MB3 | + MB6 +CC + + | +++++ AP1 | +AP2 +++++ + | AH 1 MB4 | + MB7 AH2 + +--------------------------+ +--------------------+ The example discussed in this section addresses communications between 2 networks Foo.com and Bar.com, MB1 and MB8 are mainly used for packet filtering purposes, MB2 to MB7 are used mainly for NAT purposes. The authorization provided to the CCs and MAs follows the associated model discussed in [LHamer] with one policy server within each policy domain for both the application layer and the MBs. PS1 is foo.com's policy server; PS2 is bar.com's policy server. Aoun Informational - Expires December 2002 [Page 13] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 2 application proxies are deployed within each network, AP1 in foo.com and AP2 in bar.com. All MBs are configured as CNs (i.e. no policing is done) discovery model A is used. MA1 triggers the MB discovery after receiving an incoming application session initiation request from MA2. MA1 will receive the CC2 contact information and the authorization token to discover MBs, in the foo.com and bar.com domains. The message sequences do not show the application session details. The messages show the policy interactions and the combo protocol messages. The negotiation and token transport could either happen between foo.com or bar.com at either the application layer or at the policy layer. The author's opinion is that an application agnostic method should be used and therefore a protocol should be used between the policy servers of both domains. The call flows reflect that it is the domain's policy server that will provide the token to traverse the remote end policy domain. As opposed to the decoupled model, the traversed MB need only to provide information on updated stream characteristics or when negative responses as required. By default if no information is provided by a traversed MB then the CC assumes a positive acknowledgment to the policy rule request. In the case of NATs, a NAT will update the stream filter object. AC1/CC1 CN1 CN3 PS1 AP1 AP2 PS2 CN7 CN8 AC2/CC2 1-Authorization-request(AC1, AC2) <---- 2-Auth-result(CC1Token, CC2Token) ---> 3-Sessioninformation(CC1Token, CC2Token, CC2) <-------------------------- Aoun Informational - Expires December 2002 [Page 14] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 AC1/CC1 CN1 CN3 PS1 AP1 AP2 PS2 CN7 CN8 AC2/CC2 3-Combo_resrcreqst(CC1Token,CC2Token,CC2) ----> 4- Combo_resrcreqst(CC1Token,CC2Token,CC2) -------> 5- Combo_resrcreqst (CC1Token,CC2Token,CC2,{CN3,NAT, updated stream information}) ------------------------------> 6- Combo_resrcreqst (CC1Token,CC2Token,CC2, , {CN3,NAT, updated stream information}) -----> 7- Combo_resrcreqst (CC1Token,CC2Token,CC2, {CN3,NAT, updated stream information})) -----> 8-Combo_ resrcreqst_returnpath (CC1Token,CC2Token,CC2, {Combo_resrcreqst(CC1Token,CC2Token,CC2, {CN3,NAT, updated stream information}}) < ----- 9- Combo_ resrcreqst_returnpath (CC1Token,CC2Token,CC2, {Combo_resrcreqst(CC1Token,CC2Token,CC2, {CN3,NAT, updated stream information}) <---- Aoun Informational - Expires December 2002 [Page 15] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 AC1/CC1 CN1 CN3 PS1 AP1 AP2 PS2 CN7 CN8 AC2/CC2 10- Combo_ resrcreqst_returnpath (CC1Token,CC2Token,CC2, {CN7,NAT, updated stream information},{Combo_resrcreqst(CC1Token,CC2Token,CC2, {CN3,NAT, updated stream information}) < -------------------------------- 11- Combo_ resrcreqst_returnpath (CC1Token,CC2Token,CC2, {CN7,NAT, updated stream information},{Combo_resrcreqst(CC1Token,CC2Token,CC2, {CN3,NAT, updated stream information}) < ---- 12- Combo_ resrcreqst_returnpath (CC1Token,CC2Token,CC2, {CN7,NAT, updated stream information},{Combo_resrcreqst(CC1Token,CC2Token,CC2, {CN3,NAT, updated stream information}) < --- Every CN will act as it did when the combo message traversed it the first time, i.e. replies to the resource request by adding a resource reply object only if applicable based on the rule discussed previously (basically a MIDCOM object) to the message. Once CC1 receives the combo_resrcreqst_returnpath message it will send it to MA1. As this analysis uses only one MA1 to request resources, since it has received a policy token from the other remote domain to request resources, no interaction is required with MA2 as in the decoupled model (where we also needed to provide the list of discovered MBs). When NATs are encountered such as the case of CN3 and CN7, the MB information is not really necessary, it could be omitted from the message; the author believes that it is necessary to have a MB contact information in case of negative acknowledgment to policy rules requests. CN3 will provide the translated source IP address and port of streams that will be terminated on AH1, this will be the contained information in "updated stream information"; the "NAT" information could contain information such as the lifetime timer associated to the installed state on the MB. CN7 will do the same as CN3 except that it is for streams that will be terminated on AH2. In case several NATs are traversed in the same direction it is the closest one to reach the CC in the direction of the message (i.e. if there was another NAT, CN10 per eg, in policy domain foo.com between CN3 and CN7, then when the message is going from CC1 to CC2, it is Aoun Informational - Expires December 2002 [Page 16] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 the updated NAT bind on CN10 that will be kept in the combo_resrqst) that will have its information in the NAT informational structure. In the additional the timer provided will be the most stringest one, i.e. the shortest timer. 6 Comparison of the decoupled model Vs the combo model Both model achieve the same thing differently, locate and reserve resources required for a stream traversal. The decoupled model allows the decoupling of the MA and the application host whereas the combo model requires a tight coupling between the MA function and the application host. When we compare protocol interactions in both models we find that the decoupled approach requires a protocol to carry the discovered Middleboxes (that protocol could be the application protocol). The combo model when coupling the MA with the AH, will only require the combo protocol. The direct result of the protocol interaction differences between both models is that the combo model has much less latency impact on the application. Since the triggering of the MB discovery is implicit in the combo model as it is done in the same time as controlling the MB, it is much more efficient than the decoupled model; this statement is only applicable when the MA knows the type of MB function applied within the policy domain (as it is requesting for packet filter traversal and for NAT bind information). In addition from its "locate and control" nature the combo model minimizes the MB contact information, thus the need to use the complex concept of edge MB policing MB information leaving a policy domain become less required. It is realistic to say that the Discovery Client and the Combo Client functions could be ported to a MB neighbouring the Application Host and therefore no AH is required anymore. A later version of the document will discuss how this could be achieved. The discovery protocol and the Combo protocol could use the same existing protocol but with different "objects". An analysis on the usage of RSVP as a simplified version of the combo protocol has already been documented in [TIST] and [Roedig], where no discovery objects are included and no edge MB concept is used. Aoun Informational - Expires December 2002 [Page 17] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 7 Security considerations Security issues are the same as those discussed in [Caoun] 8 Conclusion The comparison analysis shows that the combo model is more efficient than the decoupled model. The author invite the IETF community to consider the MB discovery integration proposals in the draft and start discussions on the MB discovery framework as well as its impact on other IETF protocols, RSVP and its possible reincarnation within the NSIS WG and the application protocols that may need to interact with it. 9 References [Caoun] C.Aoun,L-N Hamer " Potential Solutions to the Middle Box discovery problem ", Internet draft, draft-aoun-midcom-discovery-01.txt [FRMWRK] P.Srisuresh et all," MIDCOM Architecture & Framework", Internet draft, draft-ietf-midcom-framework-07.txt [LHamer] Hamer, L-N. and Gage, B, "Framework for session setup with media authorization", Internet-Draft, draft-hamer-rap-session-auth-03.txt, February 2002 [Roedig] U. Roedig et all, "RSVP as Firewall Signalling Protocol", Proceedings of the 6th IEEE Symposium on Computers and Communications [TIST] M. Shore, "The TIST (Topology-Insensitive Service Traversal) Protocol", Internet draft, draft-shore-tist- prot-00.txt 10 Acknowledgments The author would like to thank Louis-Nicolas Hamer for his valuable contributions to the document. 11 Author's Address Cedric Aoun Nortel Networks Aoun Informational - Expires December 2002 [Page 18] Internet Draft draft-aoun-middlebox-discovery-comparison-00.txt June 02 FRANCE Email: cedric.aoun@nortelnetworks.com 12 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 13 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Aoun Informational - Expires December 2002 [Page 19]