Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt

From: "Cedric Aoun" <[email-masked]>
Date: Mon, 1 Oct 2001 16:06:00 +0100

Hi Scott,
Please see comments in line.
Hope that the comments were not raised before, if so sorry for the spam
Thanks
Cedric

-----Original Message-----
From: Scott Brim [mailto:[email-masked]]
Sent: Tuesday, September 18, 2001 4:08 PM
To: [email-masked]
Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt

This is going to be long, because I want to do a more detailed analysis
realm identifiers and informant addresses.  It's time we went beyond
shallow discussion.

As I understand the concept, realm identifiers are a local matter -- a
particular middlebox decides how it wants to identify the realms
connected to it.  Agents are expected to communicate with middleboxes
and learn what realms they are in.  When an agent communicates with
another agent, it learns if that agent is in the same realm or not.
Based on that it decides whether to send a ruleset to a middlebox.

When discussing realm identifiers I'm going to use this figure:

         +---R1---+  +---R2---+  +---R3---+
         |        |  |        |  |        |
         | A1A    -M1-  A2A   -M3-        | 
         |  A1B   |  |   A2B  |  |  A3    |
         |        -M2-        -M4-        |
         |        |  |        | ||        |
         +--------+  +--------+ |+--------+
                                |
                                |  +--R4------+  +--R5----+
                                |  |          |  |        |
                                +---   A4     -M5-   A5   |
                                   |          |  |        |
                                   +----------+  +--------+

    The Rs are realms, the As are agents, the Ms are middleboxes.  M5
    also connects three realms, at least two with overlapping address
    space (this is the theoretical situation that was discussed for
    several days).

The problems with realm identifiers are:

  - Realm identifiers are not just a local matter.  Consider ...

    (1) Coordination of realm identifiers of parallel middleboxes.
    Suppose agent A1A learns from M1 that it is in realm 42, and agent
    A1B learns from M2 that it is in realm 65535 (it's the same realm,
    but the middleboxes are naming them independently).  Then when the
    A1A and A1B exchange invitations, they will exchange addresses for
    external use because they think they are in different realms.  Their
    packets will be routed between M1 and M2, through R2 (not R1).  If
    R1 and R2 address spaces are overlapping, then packets may
    inadvertently be spilled further, beyond R2.  As a solution, M1 and
    M2 need to coordinate their realm identifiers.  This problem would
    also occur if A2A and A2B were communicating and got their realm
    identifiers from M1 and M3 -- it's not limited to the case where
    middleboxes attach the same realms.
-------------
<CA>
Realm IDs are provisioned against application customer profiles.
The application entity co-hosted with the Midcom Agent (MA) contains a
mapping
of the application customers with the MB reachability information (at least
the address), the realms to which the 
MB is connected.The MB do not provide the realms to the MAs.
In the case of standard Middleboxes (MBs), the MB is not connected to more
than 2 realms.
Let's call them inside and outside as you did in your draft.
In the case of provider provisioned Mbs, the MB is splitted to logical Mbs
either using a different address
for each logical Mb or an identifier + address to associate it with the
logical Mb. In case the logical Mb is connected to 2 realms;
every thing remains the same as in the previous cases.
Things get complicated when the Mb (logical or physical) are requested to
connect to more than 2 realms and you have address overlapping.
In this case you have  2 outside and you need to name both external realms
(relative to the protected entities) differently, and you need to do twice
NAT.
Since you have address overlapping, the Mb doesn't know to which realm the
packet will to come from or go to, you discussed this below.and have some
comments 
below within that section. For this reason we shall need to provide the
realm information.
</CA>
----------------------
    (2) Coordination of different middleboxes in a realm.  Suppose A1A
    learns from M1 that it is in realm 42 and A2A learns from M3 that it
    is in realm 65535, but M1 is calling R2 14285.  Then when A1A asks
    for an address for communicating with realmid 65535, M1 won't know
    where that is.  The first result is that middleboxes have to assume,
    by default, that any realm id they don't understand is "outside".
    Inadvertent openings will, without doubt, be created, through
    administrative merging and splitting, misconfiguration, protocol
    errors, whatever.  The second result is that M1 will need to return
    a global address, not an R2-specific one (R2 might also be private).
    As in the previous case packets may go through a different realm,
    e.g. R3 because they will have global addresses.  The solution is
    that all middleboxes associated with a realm need to be coordinated.
    A large ISP could have thousands of middleboxes, real or virtual.
---------------
<CA>
When an SP or a big enterprise deploys several MBs, external policy servers
are
used to prop uniformly policies and configuration parameters (ref to COPS-PR
work).
We could assume that the Realm IDs are part of them (networks x,y,z : Realm
42; nets a,b,c Realm 50 ...)
This will provide the consistency of the realm IDs.
In most cases we shall have an inside realm and an outside realm
</CA>
--------------
    (3) Finally, multiple overlapping address spaces attached to the
    same NAT middlebox (this is the theoretical situation we were
    discussing for the last week or so).  Suppose A2A is communicating,
    using an application layer signaling protocol, with A5.  A5 received
    realmid 42 from M5.  M4 doesn't know where that is, and unlike the
    previous situation, defaulting to "outside" isn't good enough, since
    in this (theoretical) situation M4 has interfaces to multiple realms
    where A5's local address and unknown realmid might be valid.  When
    A2A asks M4 for a pinhole/translation for realmid 42, what does M4
    do?  Either the middlebox needs a map from realmid to interface, for
    all possible realm identifiers, or the client of A5 must already
    have been assigned a globally unique address and the middlebox needs
    to know enough about routing to know how to reach that address.
    That is, either you need global knowledge of realm identifiers or
    you're no better than informant addresses even with the realm
    identifier system.
---------------
<CA>
The realm IDs are provided by the MAs.
Consistency between MBs is provided by proper centralized configuration
mechanisms
</CA>
--------------
  - Using realm identifiers requires coupling of application proxies and
    agents.  Realm identifiers need to be exchanged by agents, since
    they are the ones speaking to the middleboxes.  However, the targets
    which the realm identifiers point to are first discovered by
    application signaling.  Suppose an application signaling entity and
    the application agent were separate.  Take SIP, for example.  If a
    SIP proxy sends an invitation with a client address, the agent needs
    to intercept that invitation and somehow discover the realmid of the
    target.
-----------------
<CA>
The mapping of a customer to a specific realm is achieved through creation
of a specific
customer profile at the application level, it doesn't require any
application modification (depending on the application type, please ref on
comment below).
But I agree that this specific configuration in the customer profile is an
overhead, and could be potentially considered as a show stopper
</CA>
---------------
  The only simple way to do that is to piggyback realmid
    exchange with the application signaling.  This makes the midcom
    scheme much less flexible.  For example, in the Midcom WG we have
    often speculated about placing agents in the same device as the
    middlebox functions (where the current version of "agents" are now).
    This tight coupling makes this impossible or at least very
    difficult.  It is architecturally wrong to require all application
    proxies to be agents and speak the midcom protocol.

In summary using realm identifiers requires:

  - A system for coordinating realm identifier assignment, for both
    internal and external realms, among middleboxes throughout a realm
    (possibly configuration).  This is additional management overhead
    and some errors will be difficult to detect.  
---------
<CA>
Agreed
</CA>
-----------
  - For complex situations, a way for a middlebox to map realm
    identifiers to interfaces for every realm it might communicate with.
-------------
<CA>
Agreed, practically we shall need to configure an additional parm to the
regular one; the realm id
</CA>
---------

  - Coupling of agents and application signaling proxies, and new
    protocol mechanisms for exchanging realm identifiers.
--------------
<CA>
Application modification is not really required (for all applications), the
mechanism 
exist today by using application user ids.
The issue is encountered when the id is an address, in device control
protocols the id is optional therefore not all implementers may have
developed it
In SIP the user id (from and to) are mandatory, I think; so we shouldn't
have an issue.
I recognize that for some none VoIP application we probably need to add the
user ids, and your comment is therefore valid.
</CA>
---------------
  - Willingness to tolerate a higher possibility of security holes
    because middleboxes will not have the intelligence to know if a
    target is inside or outside and must default to believing it is
    outside, 
------------
<CA>
Unless we provide it the information
</CA>
--------------
and configuration errors are more likely to lead to
    security holes than other kinds of configuration errors.

The advantages of using the realmid scheme are:

  - It can support almost any situation.  In particular it can support
    control of a middlebox through a NAT, and it can support middleboxes
    which are not configurable even when they sit between two complex
    routed topologies (but only when there is only one of these in a
    domain).  

  - It sends queries to middleboxes less frequently, since it learns
    (well, some of the time) whether a target is in another realm from
    other devices, not the middlebox.

The advantages of the informant address approach are that it adds no new
infrastructure, no configuration or administration overhead, and no
security holes.  It depends on the middlebox for all its topological
knowledge, which is architecturally clean.  However, it does not work
through NAT, and in the case where a simple middlebox connects two
complex realms, it assumes the middlebox at least knows what address
prefixes are in the realm shared by the agent and the middlebox.  

Being able to work through a NAT may have no value at all -- we need
customer input on this.  
----------
<CA>
In the case of carrier provided VoIP services, this has a great importance
because the Telephony Service Provider
devices will be behind Mbs.
This is probably the case for other carrier provider applications
John raised concerns regarding applicability of anti-spoofing if we do not
provide the realm information, we need
a way to be able to apply anti-spoofing policies
</CA>
-------------
For the case where the middlebox connects a
realm with multiple address prefixes, but the middlebox does not know
what they are, there are alternatives to the proposed realm identifier
scheme:

  - Have some other way for agents to discover if they are in the same
    realm.
-----------
<CA>
and if not which realms they are in
</CA>
---------
  - Limit the use of such devices to simple cases.  This may be the case
    today.  

  - Use them in conjunction with more full-featured middleboxes.
---------
<CA>
We need to find a method that is less complex than the first one (realm Id)
and doesn't have
the caveat of the second one (informant)
</CA>
-----------
More general closing thoughts: The Internet has to be simple or it will
be strangled by its complexity.  It's not enough for a single system to
be simple.  There are interactions between systems such that you have to
be careful what you assume or require from the underlying Internet
behavior or the Internet will ossify.  Especially now, when we're about
to explore new possibilities in Internet architecture, we want to limit
our requirements on it.

Limiting what you expect from Internet behavior may require some
tradeoffs.  We have made such tradeoffs in the past, and Internet
services have flourished despite, or more probably because of, them.  

..Scott

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom