Internet DRAFT - draft-aoun-midcom-discovery
draft-aoun-midcom-discovery
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
<draft-aoun-midcom-discovery-01.txt>
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]
