MIDCOM Working Group C.Aoun Internet Draft L-N.Hamer Category: Informational Nortel Networks Expires on November 2002 May 2002 Potential Solutions to the Middle Box discovery problem 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 This document provides a high level outline of possible solutions for Middle Box discovery which is one of the problems which has not yet been addressed in the Midcom architecture. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Introduction.....................................................2 2 Conventions used in this document................................3 Terminology and acronyms used in this document.....................3 Aoun, Hamer [Page 1] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 4 Assumptions used for the proposed discovery models..............3 Questions which MB discovery needs to address......................4 6 Proposed Discovery models........................................4 6.1 Model A discovery operations ..................................6 6.2 Model B operations............................................11 6.3 Discovery methods comparison..................................14 7 DC authorization................................................14 8 Sending the resulting discovery messages........................15 8.1 Providing the MA(s) contact information to the DC.............15 9 Proposed method to reach the remote end DC......................16 10 MB discovery interactions with network topology events.........17 11 Security considerations........................................17 12 Conclusion.....................................................17 13 References.....................................................18 14 Acknowledgments................................................19 15 Author's Address...............................................19 16 Intellectual Property Statement................................19 17 Full Copyright Statement.......................................19 1 Introduction A Middle Box (MB) discovery mechanism is required to discover in real time with which MB a Midcom agent should communicate to allow packet streams to reach their destination. Scenarios requiring MB discovery are documented in [Caoun]. A typical network topology requiring MB discovery would be: Netx---------+ The Internet + Nety MB1| | | | Host x MB2| Application server/ |MB4 Host y | | MB3| Midcom agent |MB5 ---------------+ +---------- There is no way to allow the Midcom agent to know which MBs will be traversed for flows between Host x and Host y. Middle Box discovery will provide this capability. This document outlines a number of possible solutions to the Middle Box discovery requirements set out in [Elear]. It also analyses these solutions in the context of the deployment scenarios and associated issues described in[Caoun]. Middle box discovery should take into account peer to peer applications as well as cases where application signaling (commonly called routed signaling scenarios) passes through application proxies or "application controllers" (For example in H323 architecture this would be the case of Gatekeeper routed signaling Aoun, Hamer Informational - Expires November 2002 [Page 2] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 scenarios, SIP when SIP proxies are used and the Megaco architecture). The integration of middle box discovery within the Midcom architecture is currently not considered in this document. The MB terminology is aligned with the MIDCOM workgroup definitions (set out of in [FRMWRK]), although it is still evolving. 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 Terminology and acronyms used in this document Terminology already in use [FRMWRK] MB: Middle Box MA: Midcom Agent New terminology: MS: Midcom Server- The Midcom control functionality on the MB AC: Application Client AS: Application Server- the terminology used covers the application server function as well as its host. DC: Discovery Client - Entity responsible for sending/receiving discovery messages. DN: Discovery Node - Function that sits in a MB and updates discovery messages passing through it. BDN: Border DN - function that sits in a MB neighboring other administrative networks (i.e another policy domain). Its main role is to police information leaving the network and it will operate in conjunction with a policy server. AH: Application Host- Computing platform hosting an application 4 Assumptions used for the proposed discovery models Aoun, Hamer Informational - Expires November 2002 [Page 3] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 The DC needs to be authorized to discover the Middle Boxes as well as the functions applied by the MB to certain packet flows passing through it. The authorization implies that the DC provides credentials to be used during its authentication. These credentials could be owned by the DC or provided by another entity that has a trust relation with the MB (either direct or transitive). The circumstances under which a DC needs to discover the MBs on the path are currently not discussed in this document: The discovery could be requested by a third party (the MA or an application server), or performed by the DC on a session by session basis. The results of the discovery process are sent to the MA either directly or to a function co-hosting the MA. The protocol that will need to be used for this operation is not discussed in this document. 5 Questions which MB discovery needs to address In the light of the requirements, there are a number of issues that MB discovery must resolve: 1)Determine the circumstances under which there is a need to discover MBs: a) Does it need to happen for every packet stream? -Even if the destination of the stream is already known? and even if the deployed MBs on the path are known(maybe cached from a previous discovery exercice)? b) Which entity triggers the discovery? -Is it the application client? -Is it the application server/proxy co-hosted with the MA function? 2) How are the results of the discovery process reported to the MA(s) which needs to use them? a) Do the discovered MBs report directly to the MA, that they are on the path of the packet stream? b) Does the DC provide the MB discovery result to the MA(s)? 3) How will the DCs be authorized to discover MBs and the functions on the MBs will apply to the packet streams? 4) How can the discovery process access DCs which are behinds NATs? 5) How to deal with situations where more than one MA is required? In this version of the draft, the authors deal only with questions 2), 3), 4) and 5) which concern the actual discovery process. 6 Proposed Discovery models Aoun, Hamer Informational - Expires November 2002 [Page 4] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 This draft currently outlines two models to solve the MB discovery problem. -Model A: the results of the discovery process (i.e. the discovered MBs in the path and the functions which they can apply to the packet stream) are returned initially to the DC, which then sends the result onwards to the MA, where it will be used. -Model B: the MBs on the path encountered during the discovery process notify the results directly to the MA(s) that need them.. Figure 1 shows a topology example that will benefit from the MB discovery. ++++++++++++++++++++++++++ + +++++ + + +AC + + +++++++++++++++++++++ + +---+ +++++++ + +++++++++++ +Application Service+ + +DC + +BDN-MS+-+--+ Internet+-------+ Provider + + +++++ +++++++ + + + + + + AH1 MB1 + /+++++++++++ + ++++ + + +++++ + / ª + +MA+ + + +AC + +/ ª + ++++ + + +---+ ++++++++/ ª + AS1 + + +DC + +BDN-MS++ ª + Policy domain y + + +++++ +++++++++ ª + + + AH3 MB2 + ª +++++++++++++++++++++ + + ª + + ª + Policy domain x + ª ++++++++++++++++++++++++++ ª ª ++++++++++++++++++++++++++++++++++ + + + +++++++ +++++++ +++++++ + + +DN-MS+ +DN-MS+ +MA + + + +++++++ +++++++ +++++++ + + MB3 MB4 AS2 + + + + +++++ + + +AC + + + +---+ + + +DC + + + +++++ + + AH2 + + Policy domain z + ++++++++++++++++++++++++++++++++++ Figure 1 Note that the MA could also reside within the same policy domain as the MB. As seen in figure 1, discovery of MBs is necessary because when AH1 communicates with AH2 several MBs could be traversed and the MA won't know with which MBs it will need to communicate. Aoun, Hamer Informational - Expires November 2002 [Page 5] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 6.1 Model A discovery operations The Model is based on the following: -a) The Discovery Client (DC) will send a discovery message towards the remote end Application Host (AH)'s DC*. -b) Each traversed MB will modify the discovery message by adding within the message the actions that are applied to the packet flows, as well as a MB identifier. -c) The destination AH's DC will loop back the discovery message to the original DC -d) Repeat step (b) as the discovery message returns to the originating DC, thereby discovering the (possibly different) MBs encountered on the return trip. -e) The DC will then pass on the results of the discovery message to the authorized MAs. *The remote end DC contact information will be discussed in a later section To minimize the security issues, it is essential that a DC be authenticated and authorized prior to processing (done by the traversed MB) its discovery messages. This should prevent rogue users from discovering Middle Boxe capabilities; however, they could still potentially discover the MBs with existing tools such as trace-route (note that a lot of Middle Boxes could be configured not to reply to ICMP request messages). Figure 2 below provides an example using method A. DN1 applies packet filtering and DN2 applies NAT. Aoun, Hamer Informational - Expires November 2002 [Page 6] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 +-----------------------+ ª Policy domain x ª DC1 DN1 DN2 MA DC2 1-Discover(DC1 Token,DC2) --------------> 2-Discover(DC1Token,DC2,{DN1,FW}) -----------> 3-Discover (DC1Token,DC2,{DN2,NAT},{DN1, FW}) ----------------------------> 4-Discover-returnpath (DC2Token,{Discover(DC1Token,DC2,{DN2,NAT},{DN1,FW}) < ---------------------------- 5-Discover-returnpath (DC2Token,{DN2,NAT},{Discover(DC1Token,DC2,{DN2,NAT},{DN1,FW}}) < ------------ 6-Discover-returnpath (DC2Token,{DN1,FW},{DN2,FW}, {Discover(DC1Token,DC2,{DN2,NAT},{DN1,FW}}) < ---------------- Figure 2 For simplicity, Figure 2, provides an example of message sequences, where DC2 is not deployed behind a MB, 2 MBs are deployed in the network and follows policy rules of policy domain x. The message sequence provides a high level view of the required message content and should not be seen as adequate message syntax. The authorization policy lookup is not shown in this picture for simplicity. It will consist of checking the validity of the DC's credentials provided within the DCToken. A later section in the document addresses authorization policies. Step1: DC1 sends a Discover message to DC2 including an authorization token, DC1Token, and DC2 contact information. The token in this example is assumed to be provided by the MA by some means (discussed in the policy section of the document). Step2: When DN1 is traversed by the discover message, it will check the credentials within DC1Token. DC1 is authorized to discover DN1, DN1 will then add an object within the Discover message. The object contains DN1 contact information and the applied function on the packet flows. Aoun, Hamer Informational - Expires November 2002 [Page 7] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 Step3: DN2 receives the discover message, it will check the contained credentials of the included token. Step4: DC2 receives the discovery message, encapsulates it in a discover_returnpath message and includes in it a DC2Token. DC2 sends the discover_returnpath message to DC1 (using the source address (and source port) of the discovery message datagram). Step5 and 6 are similar to steps 2 and 3, except that the message is discover_returnpath. In steps 5 and 6, the DNs check all the tokens in the message even the ones in the encapsulated Discover message. This will allow scenarios where MBs are deployed in different policy domain. 6.1.1 Model A main issues -Model A could have delay issues since the MA is notified of the existence of MBs on the stream path until all the MBs are discovered: This delay is highly dependent on the propagation delays, which result from the propagation delays between the DC and the MAs and the round trip between DCs; if we add the MA<->MB signaling and MB authorization we might incur post dial delays (in VoIP applications). -Security: since MB information is leaving the policy domain it will be known to other parties outside the policy domain. In some cases this could be seen as security holes. The reason why the MB information is inserted hop by hop by doing a chain, is to provide the sequence in which MBs are deployed in the path. In case NAT functions are applied several times this is an important information to have, since the last translated address port pair will need to be communicated to the remote application client. 6.1.2 Policing MB information to minimize security threats A way to minimize the previously stated security threats is to police MB information leaving a policy domain. We shall call a Border DN, a DN that will police MB information leaving its policy domain. The BDN will obviously be hosted on a MB bordering other policy domains. The policed MB information will be in the form of: MB applied functions and the BDN contact information. When using the BDN concept, model A operations works as follows: -a) The Discovery Client (DC) will send a discovery message towards the remote end Application Host (AH)'s DC*. Aoun, Hamer Informational - Expires November 2002 [Page 8] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 -b) Each traversed MB will modify the discovery message by adding within the message the actions that are applied to the packet flows, as well as a MB identifier. -c)In the case where the MB hosts a BDN and the message is leaving the policy domain, the BDN will police the information included in the discovery message, and include its own address (and potentially the Middlebox discovery protocol receive port number) -d) The destination AH's DC will loop back the discovery message to the original DC -e) Repeat steps (b) and (c) as the discovery message returns to the originating DC, thereby disocvering the (possibly different) MBs encountered on the return trip. -f) The DC will then pass on the results of the discovery message to the authorized MAs. Since the BDN polices the information leaving the network, the MA needs to have a way to contact the anonymized MBs (by the BDN), the Border MB could play a Midcom proxy role to transfer the MA commands, else the Border MB will need to provide the MA with the anonymized MBs contact information. The first option is more secured since the third party (the MA) and all other policy domains'(B)DNs receiving the message will only be aware of the Border MB and not the internal ones. When applying the BDN concept within model A in the example shown in figure 2, the message sequences are modified as follows: +-----------------------+ ª Policy domain x ª DC1 BDN1 BDN2 MA DC2 1-Discover(DC1 Token,DC2) --------------> 2-Discover(DC1Token,DC2,{BDN1,FW}) -----------> 3-Discover (DC1Token,DC2,{BDN2,NAT,FW}) ----------------------------> 4-Discover-returnpath (DC2Token,{Discover(DC1Token,DC2,{BDN2,NAT,FW}) < ---------------------------- 5-Discover-returnpath (DC2Token,{BDN2,NAT},{Discover(DC1Token,DC2,{BDN2,NAT,FW}) < ------------ 6-Discover-returnpath (DC2Token,{BDN1,NAT,FW},{Discover(DC1Token,DC2,{BDN2,NAT,FW}}) < ---------------- Figure 3 Aoun, Hamer Informational - Expires November 2002 [Page 9] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 For simplicity, Figure 3, provides an example of message sequences, where DC2 is not deployed behind a MB, 2 MBs are deployed in the network and follows policy rules of policy domain x. The message sequences provide a high level view of the required message content and should not be seen as adequate message syntax. The authorization policy lookup is not shown in this picture for simplicity. It will consist on checking the validity of the DC's credentials provided within the DCToken. A later section in the document addresses authorization policies. For security purposes the first MB on the path from DC1 to DC2, is configured as BDN. Therefore all MB information leaving policy domain x will be limited to BDN1 and BDN2 contact information and applied functions to the path. In step1 DC1 sends a Discover message to DC2 including an authorization token, DC1Token, and DC2 contact information. The token in this example is assumed to be provided by the MA by some means (discussed in the policy section of the document). Step2: When BDN1 is traversed by the discover message, it will check the credentials within DC1Token. DC1 is authorized to discover BDN1, BDN1 will then add an object within the Discover message. The object contains BDN1 contact information and the applied function on the packet flows. Step3: BDN2 receives the discover message, it will check the contained credentials of the included token, as the discovery message will be leaving the policy domain, BDN2 will police all the contained information in the message and add the functions that it applies to the packet flows. Step4: DC2 receives the discovery message, encapsulates it in a discover_returnpath message and includes in it a DC2Token. DC2 sends the discover_returnpath message to DC1 (using the source address (and source port) of the discovery message datagram). Step5 and 6 are similar to steps 2 and 3, except that the message is discover_returnpath. In steps 5 and 6, the BDNs check all the tokens in the message even the ones in the encapsulated Discover message. This will allow scenarios where MBs are deployed in different policy domain. Even when the BDN concept is used, the BDN provides information on the MB's applied functions and the BDN contact information, this could still be seen as potential security holes (but less than when no policing is done). Aoun, Hamer Informational - Expires November 2002 [Page 10] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 6.2 Model B operations The main difference between Model A and B concerns events when the discovery message arrives at a BDN of a policy domain, the BDN will notify the MAs about its existence as well as the functions on the MBs it anonymizes and remove this information from the end to end discovery message which is forwarded out of the policy domain. The BDN will send a copy of the existing discovery message but without its domain's MBs information, this copy will include a sequence number identifier that was also included in the discovery message sent to the MA. This method will allow the MAs to be aware of the traversal sequence of MBs whilst limiting the knowledge which leaks out of the domain regarding the functionality of the MBs. In order to maintain the sequence in which MBs are traversed, the same sequence number identifier will be inserted by BDNs but with no additional information (i.e. no details on the applied functions and MB contact information). Once all BDNs have notified the MAs, and the end to end discovery message containing the sequence of all MBs has been passed to the MAs with a similar way as done in A, the discovery would have been completed. The DC will be required to include in the discover message the MA(s) contact information. Figure 4 shows a practical message sequence using discovery model B. The example uses the same topology as in method A's example with the additional Middle box (configured as BDN) interconnecting DC2. BDN1 applies packet filtering, BDN2 NAT and BDN3 packet filtering and NAT. +--------------------+ +---------------+ ªPolicy domain x ª ªPolicy domain yª DC1 BDN1 BDN2 MA BDN3 DC2 1-Discover(DC1Token,DC2,MA) --------> 2-Discover(DC1Token,DC2,MA,{BDN1,FW}) -----------> 3-Discovered_segment({BDN2,NAT,FW},seg1) --------> 4-Ack <------ Aoun, Hamer Informational - Expires November 2002 [Page 11] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 +--------------------+ +---------------+ ªPolicy domain x ª ªPolicy domain yª DC1 BDN1 BDN2 MA BDN3 DC2 5-Discover(DC1Token,DC2,MA,seg1) ----------------------> 6-Discovered_segment ({BDN3,NAT,FW},seg2) <---------- 7-Ack --------> 8-Discover (DC1Token,DC2,MA,seg1,seg2) -------------> 9-Discover-returnpath (DC2Token,MA,{Discover(DC1Token,DC2,MA,seg1,seg2) < ---------- 10-Discovered_returnpath_segment ({BDN3,NAT,FW},seg3, {Discover(DC1Token,DC2,MA,seg1,seg2}) <---------- 11-Ack ----------> 12-Discover-returnpath (DC2Token,seg3,{Discover(DC1Token,DC2,MA,seg1,seg2} <----------------- 14-Discover-returnpath (DC2Token,seg3,{BDN2,NAT},{Discover(DC1Token,DC2,MA,seg1,seg2}) < ------------ 15-Discovered_returnpath_segment ({BDN1,NAT,FW},seg4,Discover(DC1Token,DC2,MA,seg1,seg2}) --------------------> 16-Ack <------------------- 16-Discover-returnpath (DC2Token,seg3,seg4,{Discover(DC1Token,DC2,MA,seg1,seg2}) <------- Figure 4 Step 1: DC1 sends a Discover message to DC2 including an authorization token, DC1Token, a DC2 contact information and the MA contact information. The token in this example is assumed to be Aoun, Hamer Informational - Expires November 2002 [Page 12] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 provided by the MA by some means (discussed in the policy section of the document). Step 2: When BDN1 is traversed by the discover message, it will check the credentials within DC1Token. DC1 is authorized to discover BDN1, BDN1 will then add an object within the Discover message. The object contains BDN1 contact information and the applied function on the packet flows. BDN2 receives the discover message, it will check the contained credentials of the included token, as the discovery message will be leaving the policy domain, BDN2 will: -Police all the contained information in the message, -Step 3:Send a discovered_segment message to the MA (at the address in the MA contact information) with a reference sequence number being seg1 with the functions that its anonymized MBs apply to the packet flows. -Step 5:Send the current discover message without all policy domain x MB information, added with the seg1 reference sequence number Step 4: the MA acks the discovered_segment message BDN3 receives the discover message, it will check the contained credentials of the included token, as the discovery message will be leaving the policy domain, BDN3 will: -Police all the contained information in the message, -Step 6:Send a discovered_segment message to the MA (at the address in the MA contact information) with a reference sequence number being seg2 with the functions that its anonymized MBs apply to the packet flows. -Step 8:Send the current discover message without all policy domain y MB information, added with the seg2 reference sequence number DC2 receives the discover message, encapsulates it in a discovery- returnpath message and includes in it a DC2Token as well as the MA(s) interacting in the example. DC2 sends the discovery-returnpath message to DC1 (using the source address (and source port) of the discovery message datagram. Step 7, the MA acks the discover_segment message. Step 9 to 16 are similar to steps 2 to 8, except that the messages are discovered_returnpath_segment and discover_returnpath. In steps 9, 12 and 14 the DNs check all the tokens in the message even the ones in the encapsulated Discover message. Aoun, Hamer Informational - Expires November 2002 [Page 13] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 This will allow scenarios where MBs are deployed in a different policy domain. Once DC1 receives the discover_returnpath it will send its content to the authorized MA(s). When the MA(s) will get the information they will be able to know the sequence in which MBs were traversed. 6.3 Discovery methods comparison Method A is simpler than method B and in some cases its limitations are not applicable. In particular the latency limitation, in some cases it is more efficient for the MA to wait until all MBs are known to the MA before the MA sends a Midcom message to the MB. This scenario is typically the case when several MBs apply NAT for efficiency reasons we might want to send a request to get the NAT bind to the MB that is traversed last. 7 DC authorization As discussed in the previous sections, the discovery of MBs and the functions which they can apply to packet streams, by unauthorized parties must be prevented. The credentials used for the authentication and the authorization could be in the form of a token carried within the discovery protocol. There are two ways to provide the token to the DC, either via the application protocol (which is implicitly an application specific mechanism) or via another protocol that would make the mechanism application agnostic. [Marshall] is an example where the application protocol is carrying an authorization token. The MB will need to check if the provided authorization is still valid as well as the normal MA authorization checking procedure and if the DC is authorized to discover the MB capabilities. The credentials could be local to the DC or provided by a trusted third party, in both cases the MB will need to query its policy server to see if the DC is authorized or not. In case a trusted third party is used, the MB or its policy server will need to query if the third party is trusted and if the third party has the appropriate relation with the DC (i.e. DC has subscribed to the third party service). Aoun, Hamer Informational - Expires November 2002 [Page 14] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 The policy query could either be done by communication between the MB's policy server and the MA's policy server or potentially through either the discovery protocol or the Midcom protocol. It is best that for every discovery request, a new authorization token is provided for security purposes; alternatively the token has a defined lifetime. The authorization policy mechanism could be based on the used mechanisms in [Lhamer]. [Lhamer] discusses media session authorization mechanisms that could easily be adapted to Middle Box discovery. A later version of the draft will discuss more in detail how these mechanisms could be used in the context of MB discovery. In addition [Lhamer] proposes a mechanism to combine resource reservation requests to MB discovery, this protocol combo approach will be discussed in a separate draft discussing the integration of MB discovery within the Midcom framework. 8 Sending the resulting discovery messages Once the DC is authenticated and authorized, the MB's (B)DN will process the discovery message accordingly. Once the discovery result (i.e.discover_returnpath message) reaches the DC who originated the discovery request, the DC needs to send it to the adequate MA(s) controlling the traversed MBs. As shown in Figure 1 there maybe 2 (or potentially more) MAs that will need to control the MBs in order to allow the application to be successful. Normally 2 MAs at most could be used, therefore the discovery result will be sent to the 2 MAs (provided in the discover_returnpath message). Since not all traversed MBs, are controlled by both MAs, certain Midcom messages will be useless. This is an inefficiency of method A. Having the MAs querying the list of MBs with which they are in relation could optimize this. 8.1 Providing the MA(s) contact information to the DC Since the originating DC was provided with the list of MAs, there should be some means to inform it about the MAs. The list of MAs could be carried within the authorization token. The application protocol could carry the authorization token and will provide it to the application client co-hosting the DC. Aoun, Hamer Informational - Expires November 2002 [Page 15] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 This is not the only way to solve the problem but seems to be the easiest way. When several policy domains are traversed, the token provided by the originating DCs need to be accepted by MBs in all the traversed domains. This will require that the application protocol will carry 2 authorization tokens one from the local DC's (the one generating the discover message) MA and one from the remote DC's MA. 9 Proposed method to reach the remote end DC The discovery methods discussed in the draft assume that the local DC (the one generating the discover message) knows the address (and port) on which the remote end DC is reachable. When the remote end DC is behind a MB applying NAT, it is not possible to know in advance the remote end DC's address (and port). DNS SRV records could be used to discover the remote end DC contact information, but this will require that the MBs have DNS SRV ALGs. This might not be the case for all MBs. This might not work when NAT is applied twice on the path. However the following mechanism could solve the problem: -The originating DC is provided the address and port of the application client co-hosted with the remote end DC -The remote end DC contact information will be the remote end application client co-hosted with the remote end DC -The used destination address will be the remote end DC contact address, in case the discovery protocol runs over a transport protocol the transport port number will be the remote end DC port number (provided in the remote end DC contact information) -When the MB natting (lets call it MB-NAT) the remote end application host will find the remote end DC contact information it will check its binds, if the check is positive then the MB will replace the remote DC contact with the private remote end DC contact information and replace the destination address (and destination port number). The above mechanism will work in most cases even when several NATs are deployed in chain, since the remote end application client address and port pair provided to the DC is the result of the translation of the last traversed MB-NAT in the chain (when the message is sent from the remote end AC to its application server/proxy). Aoun, Hamer Informational - Expires November 2002 [Page 16] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 This method will require that the MAs, exchange the remote end application client address and port. This information will also need to be provided to the DC. The protocol used to carry this information could be potentially the application protocol(s). 10 MB discovery interactions with network topology events Since the DC has discovered MBs on the path of the application prior to the application session start, after future network topology changes occur, different MBs could be traversed and the application session will be broken. A solution to the problem would be that MBs within the same policy domain communicate the installed Midcom policy rules. When a network modification happens due to link failures (or other reasons) the newly traversed MB by the packet flows will notify the MA, that installed the previous policy rule on the previous traversed MB. The MA may or may not require the DC to rediscover the path. The application protocols are impacted by this solution since the ACs will need to inform their application peers of the new translated address and port pair(s) (when NAT is applied). 11 Security considerations There are several security threats to the operations proposed in the draft: -In case the DC is not authenticated, the MA could be provided faked information. The direct result is a DoS attack since the application won't work and certain holes could be open in the network. -This could be fixed by having the (B)DNs encrypting their MB "objects"; this implies that there is an already established security relation between the MBs and the MAs -A fake MB in the path of the discovery messages could announce it self as a MB -Appropriate authentication mechanisms should be used to authenticate the MBs -Parties in the path of the MB discovery messages could reuse the MB information for security attacks -MB information should be encrypted, this implies that there is an existing security relation between the MBs and the MA(s) 12 Conclusion Aoun, Hamer Informational - Expires November 2002 [Page 17] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 The proposals in this draft address the MB discovery mechanisms and the possible associated authorization mechanisms. These proposals impacts application protocols because the application protocols will need to have envelopes carrying authorization tokens and remote application signaling contact information. The discovery mechanisms could reuse existing protocols such as RSVP or its replacement being currently defined within the NSIS WG. [Herzog] discusses the usage of RSVP to carry authorization tokens, this shows that not a lot of extensions are required apart the ones of defining the required tokens. The proposals set out in the draft are completely decoupled from the Midcom protocol and as such could be integrated in the Midcom architecture as a "black box" informing the MA on which MB it needs to apply control to allow an application to work successfully. An initial analysis done by the authors shows that in case the MIDCOM protocol is separate from the discovery protocol, the solution will work but will suffer from latency issues. A separate draft will discuss the pros and cons of having a separate discovery protocol vs having a combo protocol handling MIDCOM and MB discovery. The authors invite the IETF community to consider the proposals in the draft and start discussions on the MB discovery framework as well as its impact on other IETF protocols, NSIS and the application protocols that may need to interact with it. 13 References [Caoun] C.Aoun, "Network topology considerations in the MIDCOM Architectural framework", Internet draft, draft-aoun-midcom-network-00.txt [FRMWRK] P.Srisuresh et all," MIDCOM Architecture & Framework", Internet draft, draft-ietf-midcom-framework-07.txt [Elear] E. Lear, "Requirements for Discovering Middleboxes", Internet draft, draft-lear-middlebox-discovery- requirements-00.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 [Marshall]W. Marshall et al., "SIP Extensions for Media Aoun, Hamer Informational - Expires November 2002 [Page 18] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 authorization", Internet-Draft, draft-ietf-sip-call- auth-02.txt, August 2001, Work in progress. [Herzog] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. 14 Acknowledgments The authors would like to thank Reinaldo Penno and Elwyn Davies for their useful comments and suggestions related to this draft. 15 Author's Address Cedric Aoun Nortel Networks FRANCE Email: cedric.aoun@nortelnetworks.com Louis-Nicolas Hamer Nortel Networks Ottawa, ON CANADA Email: nhamer@nortelnetworks.com 16 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. 17 Full Copyright Statement Aoun, Hamer Informational - Expires November 2002 [Page 19] Internet Draft draft-aoun-midcom-discovery-01.txt May 2002 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, Hamer Informational - Expires November 2002 [Page 20]