[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            S. Brim
Internet-Draft                                                   A. Simu
Expires: January 30, 2002                            Cisco Systems, Inc.
                                                             August 2001


                       Midcom Agents and Topology
                     draft-brim-midcom-inandout-00

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.

   This Internet-Draft will expire on January 30, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   A midcom agent does not know whether to ask for a ruleset to be
   installed in a middlebox or not.  Even when it does ask, in some
   situations the middlebox does not know how to apply the ruleset.
   This document tries to solve these problems without adding an
   overwhelming amount of complexity to every agent and middlebox.









Brim & Simu             Expires January 30, 2002                [Page 1]


Internet-Draft         Midcom Agents and Topology            August 2001


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   The Problem  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.   The Simplest Scenario  . . . . . . . . . . . . . . . . . . .   4
   5.   Overlapping Address Spaces . . . . . . . . . . . . . . . . .   5
   5.1  Should a Request Be Sent?  . . . . . . . . . . . . . . . . .   5
   5.2  Inside or Outside? . . . . . . . . . . . . . . . . . . . . .   7
   5.3  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.   Agent on the Outside . . . . . . . . . . . . . . . . . . . .   8
   7.   More on Rulesets . . . . . . . . . . . . . . . . . . . . . .   8
   8.   Concatenated Addressing Realms . . . . . . . . . . . . . . .   9
   9.   Multiple Overlapping Address Spaces  . . . . . . . . . . . .  10
   10.  Middleboxes and Discovery  . . . . . . . . . . . . . . . . .  10
   10.1 Anycast  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   10.2 Probing the Target Address . . . . . . . . . . . . . . . . .  11
   10.3 Server Location Protocol . . . . . . . . . . . . . . . . . .  11
   11.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   12.  Security Considerations  . . . . . . . . . . . . . . . . . .  13
        References . . . . . . . . . . . . . . . . . . . . . . . . .  13
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  14
        Full Copyright Statement . . . . . . . . . . . . . . . . . .  15




























Brim & Simu             Expires January 30, 2002                [Page 2]


Internet-Draft         Midcom Agents and Topology            August 2001


1. Introduction

   The IETF Midcom Working Group is defining a protocol (or extensions
   to one) by which an agent with application intelligence can request
   middleboxes to install specific sets of rules for packet matching and
   treatment [1][2].  The middleboxes of particular interest are NATs
   and firewalls.  The goal is to make it possible to separate
   application intelligence from the actual handling of packets.  The
   Midcom Working Group has encountered a problem in doing this
   separation -- any topology knowledge the middlebox might have, and
   any information regarding the security of the networks attached to
   its interfaces, is not directly available to the agent.  The agent
   apparently needs this information to make decisions about when to
   make requests of middleboxes.  This information could be made
   available but a brute force approach would make both functions more
   complex than they are now.

   What is the minimum amount of information that needs to be given to
   an agent?  What approach minimizes overall system complexity?

2. Terminology

   All terminology is as in the Midcom Framework [1] with the following
   additions:

   Addressing Realm: A contiguous part of the Internet in which all used
      IP addresses are unique.

   Inside: In the same addressing realm as the entity being discussed.

   Outside: In a different addressing realm from the entity being
      discussed.

   Ruleset: A set of rules for middlebox packet processing which are
      installed and removed as a unit.  In particular a ruleset includes
      at least one "filtering" or "matching" rule (e.g.  any packet
      destined for 192.168.100.1 port 42) and at least one "action" rule
      (e.g.  "let it through", "let it through with source address
      translation to 10.0.0.25", or "discard it").

   Target Address: A source or destination IP address or address range
      in a rule.

   Informant Address: The address of the packet originator from which a
      target address was learned by the midcom agent.  The mechanism by
      which the target address is conveyed from the informant to the
      agent is not relevant.  The mechanism could be, for example,
      static configuration, a DNS reply or an application protocol



Brim & Simu             Expires January 30, 2002                [Page 3]


Internet-Draft         Midcom Agents and Topology            August 2001


      control packet.

   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].

3. The Problem

   In a network with a current NAT or firewall middlebox, the middlebox
   sits between an "inside" area and one or more "outside" areas.  The
   middlebox applies rules to packets passing between the inside and
   outside areas (including the possibility of dropping them).  The
   middlebox is configured to know whether a particular interface is
   connected to an inside or outside area.  The middlebox also knows the
   egress interface for any packet it is supposed to forward -- if it
   didn't, the network administrator would have a problem and would
   arrange for it to have that information, either through configuration
   or through having the middlebox participate in routing in some way.

   However, the midcom agent may be physically separate from the
   middlebox.  There are two problems with using the midcom framework as
   it is currently conceived.  First a midcom agent will ask a middlebox
   to install rules for packets which the agent doesn't know for sure
   will ever pass through the middlebox in the first place.  Second, it
   doesn't know how to tell the middlebox which interfaces on the
   outside of the middlebox should carry those packets.  Proposed
   solutions range from hand-configuration to drastically reducing the
   Midcom Working Group's goals.

4. The Simplest Scenario

   Consider a very simple scenario to start.  Suppose a single agent is
   controlling a single middlebox connecting two addressing realms, and
   the two address spaces do not overlap.

   The agent's client, an end system, wishes to initiate communication.
   If the packets are going to pass through the middlebox, a ruleset
   needs to be installed in the middlebox allowing them to do so.  With
   current NATs and firewall middleboxes, application intelligence would
   be yet another function co-resident with the middlebox's NAT and/or
   firewall ones.  Having all these functions, the middlebox would know
   what to do with any packet it received on any interface, and would
   not have to install any rules before the packets arrived.  With
   Midcom, and separation of application intelligence from the middlebox
   functions, decision has to be made whether to install a ruleset for a
   particular packet before the packet arrives at the middlebox.

   What if the two endpoints are both on the same side of the middlebox?



Brim & Simu             Expires January 30, 2002                [Page 4]


Internet-Draft         Midcom Agents and Topology            August 2001


   In this particular case, since the address spaces do not overlap, no
   great harm is done by installing a ruleset, even if the communication
   it allegedly supports never passes through it.  The only harm would
   be useless state information in the middlebox -- a large number of
   useless rulesets might block the installation of other, actually
   useful, rulesets.

   In this simple case, with moderate use, it is probably all right to
   use the mechanisms of the midcom protocol as currently conceived of
   in the Midcom Framework [1] -- no new capabilities are required.
   Heavy use does lead to the risk of exhausting middlebox resources
   uselessly, and a new approach is required.

5. Overlapping Address Spaces

   Consider a scenario like the one above except let the inside and
   outside realms have overlapping addresses.  In order for
   communication to happen across the middlebox, both the inside and the
   outside endpoints need to be given non-overlapping addresses by the
   middlebox -- a classic chicken-and-egg problem.

   This is a "Twice NAT" scenario [4].  One mechanism for dealing with
   this, if necessary, is for an agent (or an endpoint) to request a
   globally unique address from its local middlebox, so that when others
   try to find that endpoint they will receive a useful address in
   response.  Another mechanism is for a middlebox or an agent to
   monitor responses to DNS or other higher-layer requests, so that when
   an address for an endpoint or agent is being looked for, rulesets for
   address translation for the address being acquired can be installed
   in its local middlebox.

   If a NAT middlebox is monitoring DNS itself, it can just install its
   own ruleset.  If a Midcom agent is doing the monitoring, then after
   it receives the response containing the target address it needs to
   send a request to the middlebox to have a ruleset installed for it.
   It uses the midcom protocol to do so.  However, unlike the simple
   case in Section 4, there are problems here.  The inside and outside
   address spaces overlap.  The target address, for which a ruleset is
   being requested, might be valid in either realm.  The middlebox has
   no way of knowing which addressing realm the agent is referring to.
   Also, unlike the previous case, in this case an unnecessary ruleset
   will be a security problem.  We need to be sure that packets can only
   pass through the middlebox when appropriate.

5.1 Should a Request Be Sent?

   Several possible solutions for the problem of avoiding unnecessary
   rulesets have been proposed in the Midcom Working Group, including:



Brim & Simu             Expires January 30, 2002                [Page 5]


Internet-Draft         Midcom Agents and Topology            August 2001


   o  The agent could listen in on the domain's routing protocol and
      only make a request of the middlebox when traffic would actually
      pass through the middlebox.  Because of this the middlebox would
      assume that any address which was valid both inside and outside
      would refer to an outside address.  First, this would add much
      more complexity to an agent than was intended by the Midcom
      concept.  An agent should be able to be a small bit of software,
      perhaps resident in the same device as the middlebox function, or
      perhaps distributed with an application.  Second, the knowledge
      that could be gained this way would be limited.  The requirement
      in the general case is to learn whether a particular destination
      address is inside or outside from the point of view of a
      middlebox.  A distance vector routing protocol would not carry
      this information at all, only the next hop to reach that address
      from the agent (which could be far from the middlebox).  Even with
      a link state protocol, area boundaries abstract routing
      information.

   o  The agent could query the middlebox for topology information
      available at the middlebox.  This would require the middlebox to
      be able to dump a list of all network-layer prefixes on one side
      of it -- preferably the "inside".  The agent would then avoid
      asking for rulesets for any destination covered by one of those
      prefixes.  One problem with this approach is that routing might
      change with a network reconfiguration, but we could extend the
      protocol so that the middlebox could instruct the agent to refresh
      any topology information it might have.  However, this approach
      would not reduce the complexity of the system at all -- it
      requires enough complexity at both ends of the midcom protocol
      that midcom as a whole would probably never be accepted by users.
      Finally, it adds a security issue because it requires the
      middlebox to prefer outside addresses to inside ones at all times.

   o  The agent could use application-layer intelligence to determine if
      an endpoint is inside or outside.  For example, a SIP proxy could
      parse the identifier of the callee to determine if it is within
      its trust boundaries, or keep track of which peers were "inside"
      and "outside" the trust boundary itself.  This is a treacherous
      layer violation and is not robust.  It may require constant
      monitoring to be sure that network layer configuration is matched
      in agent configuration.  It may require a globally unique
      namespace for all administrative domains, something we don't have
      or need to have in the Internet today.  We don't know how this
      layer violation will constrain our flexibility in the future.  The
      application trust boundary need not correspond to the middlebox.
      Application entities can move around and register at IP addresses
      on different sides of the middlebox at unknown times.  Finally,
      there is the required preference of outside addresses over inside



Brim & Simu             Expires January 30, 2002                [Page 6]


Internet-Draft         Midcom Agents and Topology            August 2001


      ones.

   In reality the agent only needs to know topology information with
   reference to the middlebox for one particular ruleset, for one
   particular time.

   The simplest approach is to have the agent not care whether its
   targets are inside or outside, and to always ask for a ruleset but
   allow for the middlebox to reply with two different kinds of
   "success" messages: first that the communication can go ahead because
   the ruleset is acceptable, and second that the communication can go
   ahead because from the point of view of the middlebox such a ruleset
   is unnecessary.  This is a base for proceeding, but in itself it is
   not enough.

5.2 Inside or Outside?

   Just because the agent does not have to care if an address (or
   address range) is inside or outside, the middlebox still needs to
   know.  The agent does not need to make that decision, but does hold
   information the middlebox needs to do so.  It acquired this
   information when it acquired the target address.  It must pass that
   information to the middlebox.

   The agent acquired its target addresses somehow.  A target address
   may be statically configured in the agent, or the agent may acquire
   it through some other protocol (including DNS).  In all cases, when
   it sends a target address to the middlebox as part of a rule, the way
   to make sure the middlebox has the proper context for interpreting
   that address is for the agent to include, with both source and
   destination target addresses, the "informant" address -- the address
   of the entity from which it acquired that target address.  The
   "informant" address is locally unique in the address space shared by
   the agent and middlebox, and thus provides an absolutely sure way for
   the middlebox to know whether to interpret the target address in
   "inside" or "outside" context.

   If the target address was learned from an informant in another
   addressing realm on the other side of the middlebox, the informant's
   remote address will have been translated into a locally unique
   address.  If the target address was learned from a target or an
   informant in the same addressing realm, the informant address could
   be the same as the target address, or perhaps be that of its local
   DNS server, or agent.  If the target address is statically
   configured, the agent could list itself as the informant (note this
   would make it impossible for an "outside" address to be statically
   configured, although a statically configured locally unique
   translation of one could be).  As a default rule of last resort, to



Brim & Simu             Expires January 30, 2002                [Page 7]


Internet-Draft         Midcom Agents and Topology            August 2001


   close off security problems, the middlebox can give precedence to
   inside addresses.

   Thus, in most cases the informant address is all the middlebox needs
   to determine the addressing realm in which the target address is to
   be interpreted.

5.3 Wildcards

   Sometimes an agent will want to install a matching rule for a source
   or destination range of addresses, for example in order to allow
   calls to come in to a server.  Often any caller is acceptable and
   "inside" and "outside" do not matter.  However, there will certainly
   be cases where an agent wants a server to be able to accept calls
   from a range of addresses only as long as they are "inside".  We want
   to allow this restriction, and even default to it, but not require
   it.  To handle this case, we add one more attribute to each of the
   addresses specified in matching rules: an "outside okay" flag, which
   says that an outside address is allowable, and that if an address is
   valid both inside and outside the middlebox, the outside should be
   chosen.

6. Agent on the Outside

   Consider the case where the agent is in a public realm (for example
   an ISP) and the two endpoints are in the same private realm.  The
   same principles hold and no new mechanisms are necessary.  The agent
   will have acquired the target addresses from an informant.  The
   target addresses may only be meaningful in the informants' addressing
   realms, but the address for the informant will be unique and
   meaningful in the addressing realm shared by the agent and the
   middlebox.  When the agent sends a ruleset request to the middlebox,
   specifying the target addresses and informant addresses, the
   informant addresses will allow the middlebox to determine that both
   the addresses are "outside", and it will respond that no ruleset
   installation is necessary.

7. More on Rulesets

   Because an agent usually does not know if a target address is inside
   or outside when it first passes it to the middlebox, rules cannot
   generally be phrased in terms of inside and outside addresses -- only
   whether an outside address is acceptable.  Because directionality is
   important (for example, ports may differ), rules must be phrased in
   terms of source and destination.

   There was a proposal in the Midcom Working Group that the midcom
   protocol should include actual interfaces as attributes for addresses



Brim & Simu             Expires January 30, 2002                [Page 8]


Internet-Draft         Midcom Agents and Topology            August 2001


   in matching rules.  Besides the fact that it is extremely complex for
   the agent to able to keep track of the middlebox's interfaces and
   what they are connected to, let alone specify them in a way that is
   mutually understandable, it is not necessary.  If the agent includes
   the addresses of its informants and an "outside okay" flag, it tells
   the middlebox all it needs to know how to reach the target addresses
   and to determine if installing a ruleset is necessary.

8. Concatenated Addressing Realms

   There are several scenarios in which more than two addressing realms
   are involved.

   Suppose an agent is in one addressing realm and the two endpoints are
   reachable through two different middleboxes connected to that realm.
   The agent needs to install a ruleset in each middlebox.  In this case
   the mechanism described above works well.  Informant addresses, as
   received at the agent, are always unique and meaningful in the
   addressing realm of the agent.  The agent sends the target addresses
   and informant addresses to each middlebox.  At each middlebox one
   informant address will be "outside", and the associated target
   address will be interpreted as such, while the other will appear to
   be on the inside (the same side as the agent).  The ruleset will be
   installed.

   The "informant address" technique will not work if the target
   addresses provided by informants are not meaningful to the relevant
   middleboxes -- for example, if an endpoint is more than one
   addressing realm away from the midcom agent and the informant
   provides an address which is only meaningful in the endpoint's local
   addressing realm.  In order for an agent to establish connectivity
   between two endpoints, both of them need to be represented by IP
   addresses which are unique within the space in which they will be
   used.  Fortunately it looks like the implementations and strategies
   proposed so far do follow this rule.  A DNS server representing
   endpoints in a NATted addressing realm will respond with global
   addresses, and an agent can acquire a global (or at least non-local)
   address for its client in advance with the help of the middlebox and
   the midcom protocol as described here.

   Similarly, the "informant address" technique will not work if the
   agent is trying to control a middlebox through an intervening NAT.
   The agent and middlebox must share an addressing realm in order for
   the midcom protocol to be able to carry addresses as data
   meaningfully.  Situations where it would be appropriate to run the
   midcom protocol through a NAT might not exist at all.  Those networks
   would be less secure and more difficult to manage.  If such
   situations did exist, an explicit fix would be to require what agents



Brim & Simu             Expires January 30, 2002                [Page 9]


Internet-Draft         Midcom Agents and Topology            August 2001


   seem to be inclined to do anyway, which is to acquire a global
   address for any client before it begins communicating.  In the worst
   case, if nothing else is possible, a subsidiary controller can be
   installed in the address realm on the other side of the NAT.

   Given that these situations are unlikely, and that there are
   workarounds for both of them, elaborating the midcom protocol to
   provide general support for unlikely and probably undesirable
   situations is not worth the complexity it would require.

9. Multiple Overlapping Address Spaces

   There is a situation which is theoretically possible, but which
   current NATs don't handle.  It may become possible in the future.
   Assume there is only one middlebox NAT function, but let it interface
   between more than two overlapping address spaces.  This could be made
   possible using the "informant address" and "outside okay" mechanisms.

10. Middleboxes and Discovery

   The problem of finding the right middlebox to make requests of
   overlaps somewhat with how those requests are made, so we discuss the
   discovery problem briefly.

   Middlebox discovery is important in order to find a middlebox at all,
   to find a middlebox which is appropriate for the ruleset the agent
   wants to install, and to find a middlebox which can handle the
   expected load.  Draft-lear-middlebox-discovery-requirements-00.txt
   [5] lists some requirements.  One of those requirements was that no
   endpoint or agent should be required to participate in routing, which
   the scheme proposed here satisfies.

10.1 Anycast

   It might be possible to use anycast and avoid having any explicit
   discovery mechanism at all -- the agent would simply launch queries
   at an anycast address appropriate for middleboxes of a particular
   type.

   However, anycast literally finds any target.  The only way to
   discriminate between middleboxes using anycast would be to use
   different addresses.  It's very likely that we will want to be able
   to discriminate between middleboxes much more flexibly than just by
   IP address.  For example some middleboxes might be connected to some
   outside realms while others were connected to others.

   Also, anycast is intended for one-time or at least short duration
   interactions, since if routing changes the destination found by an



Brim & Simu             Expires January 30, 2002               [Page 10]


Internet-Draft         Midcom Agents and Topology            August 2001


   anycast packet may change.  This would be a problem for any
   association which has synchronized state.  The midcom protocol
   already has a long-lasting association --
   authentication/authorization and capability negotiation are done for
   the middlebox to start with, and it is expected that
   authentication/authorization for each request after that will depend
   on that initial exchange.

10.2 Probing the Target Address

   Tunnel Endpoint Discovery (TED) [6] is for finding IKE
   intermediaries.  Its approach could possibly be reused.  TED sends a
   special probe packet toward the target address, which is actually
   intended for any appropriate intermediary.  If an authorized
   intermediary notices the packet it intercepts it and responds.  A
   similar probe could be used to discover middleboxes.

   If there were multiple disjoint connections between the agent's
   domain and the outside world, this would ensure that the agent
   established an association with the appropriate middlebox for that
   particular needed ruleset.

   The problem with using special probes like this is the very basic
   issue that the agent should not have to know if a target address is
   inside or outside the middlebox.  If the agent launches a probe
   toward an address which is on the same side of the middlebox, it will
   get no response.  What has it learned then?  TED is a different case,
   in that discovery of a tunnel endpoint is required for the service to
   be provided at all.

10.3 Server Location Protocol

   If middlebox discovery used SLP, a request for a middlebox "service"
   could be given detailed attributes, including the entire ruleset
   needed.  A domain could create its own policies for deciding which
   middlebox a particular agent should use for a particular ruleset, and
   change them arbitrarily.  In particular this arbitrariness would
   allow complex topologies, middleboxes with differing capabilities --
   in series as well as in parallel -- and spontaneous changes in
   administrative relationships.  Different outside domains could be
   reached via different middleboxes at different times of the day and
   so on.

   SLP uses multicast, which some may think is a problem.  However in
   simple situations discovery is not necessary, as demonstrated above
   for simple scenarios, and in complex situations unicast SLP can be
   used.




Brim & Simu             Expires January 30, 2002               [Page 11]


Internet-Draft         Midcom Agents and Topology            August 2001


   Thus, SLP might be useful for middlebox discovery.  The mechanisms
   proposed in this document do not have any architectural conflict with
   using SLP.

   The mechanisms proposed in this document do lead the agent to ask an
   SLS about every ruleset request.  There are a number of possible
   means to cut back on SLP activity and to reduce the potential scaling
   problem.  For example, the ability to ask SLP about ranges, the
   ability of the SLP responses to include ranges and TTLs, and the
   possibility of information being "pushed".  If SLP is actually
   selected as a base for middlebox discovery, and the rate of SLP
   activity is seen as a problem, we could explore ways to make this
   approach scale.

11. Summary

   The problem is that an agent does not know whether to ask for a
   ruleset to be installed or not.

   To solve this problem without adding an overwhelming amount of
   complexity to every agent and middlebox:

   o  The agent queries the middlebox about every possible ruleset.  The
      agent does not have to know if packets for a particular
      association would pass through a middlebox or not.

   o  In a query the agent says what the two endpoint addresses are that
      it will need to be able to establish an association between
      (wildcards are allowed).  Each specific address or address range
      has associated with it an "outside okay" attribute and the address
      of the "informant" from which the agent learned that address.  An
      informant address could be the address of the agent itself, for
      example in the case of static configuration, the address of some
      other helper, or the address of one of the endpoints.

   o  The middlebox has a new type of reply to such queries, which is
      that the query has succeeded through no rules being necessary
      (since that association will not pass through the middlebox).

   This scheme adds no extra management burden, either locally or
   globally, nor does it add any of the concomitant security risk that
   extra configuration brings in a dynamic network environment.  It does
   not threaten Internet scalability or robustness.  It does not create
   new layer violations.  It adds three simple pieces of information to
   the coalescing midcom protocol.

   Middlebox discovery is still a poorly explored area, but this scheme
   appears to work with middlebox discovery mechanisms at least as well



Brim & Simu             Expires January 30, 2002               [Page 12]


Internet-Draft         Midcom Agents and Topology            August 2001


   as any other proposal.

   There are restrictions on the applicability of this approach, but the
   cost of creating a protocol to cover the unusual scenarios which this
   approach does not is not worth paying.

   There are several loose ends to be explored, but none that call the
   basic protocol mechanisms into question.

12. Security Considerations

   The topology knowledge which a middlebox uses to make decisions about
   whether to install a ruleset or not is no more secure than the source
   of that knowledge, which is either configuration or routing
   protocols.

   The transfer of specific knowledge between the middlebox and the
   midcom agent is only as secure as the midcom protocol.  There are
   requirements for mutual authentication of middlebox and agent.
   However, the protocol has not yet been specified or implemented and
   cannot be analyzed for security problems.

   The middlebox may be misled into opening up trust boundaries if
   "inside" versus "outside" is not explicitly indicated, or if an agent
   gets confused over the origin from which it learned a particular
   address.

References

   [1]  Srisuresh, P., Kuthan, J., Rosenberg, J. and A. Rayhan,
        "Middlebox Communication Architecture and framework", Internet
        Draft draft-ietf-midcom-framework-03.txt, July 2001.

   [2]  Swale, R., Mart, P. and P. Sijben, "Middlebox Control (MIDCOM)
        Protocol Architecture and Requirements", Internet Draft draft-
        ietf-midcom-requirements-02.txt, July 2001.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Srisuresh, P. and M. Holdredge, "IP Network Address Translator
        (NAT) Terminology and Considerations", RFC 2663, August 1999.

   [5]  Lear, E., "Requirements for Discovering Middleboxes", Internet
        Draft draft-lear-middlebox-discovery-requirements-00.txt, April
        2001.

   [6]  "Tunnel Endpoint Discovery Enhancement", February 2001,



Brim & Simu             Expires January 30, 2002               [Page 13]


Internet-Draft         Midcom Agents and Topology            August 2001


        <http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/ted.htm>
        .


Authors' Addresses

   Scott Brim
   Cisco Systems, Inc.
   146 Honness Lane
   Ithaca, NY  14850
   USA

   EMail: sbrim@cisco.com


   Adina Simu
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   EMail: asimu@cisco.com





























Brim & Simu             Expires January 30, 2002               [Page 14]


Internet-Draft         Midcom Agents and Topology            August 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Brim & Simu             Expires January 30, 2002               [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/