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

From: "Christian Huitema" <[email-masked]>
Date: Fri, 14 Sep 2001 13:17:17 -0700

> 	http://www.aravox.com and, apparently, http://www.netscreen.com.
> Sun used to and possibly still does build a firewall that worked like
> this. I am quite certain this is an extremely partial list.

The netscreen box can be configured to act transparently, but it
definitely has the concept of inside and outside -- that is quite
important for firewalls... And a Sun computer running Solaris certainly
knows how to identify interfaces. 

> 	See also "bridge", a.k.a. "layer 2 switch."

These are not part of the MIDCOM charter, AFAIK.

> 	Sure you, of all people Christian, see the value of letting
> routers route, security devices do security, and NAT devices do
> NAT, with as little overlap in functionality as possible?

<soapbox>
Actually, I don't see the value of boxes in the middle of the network
that do anything else than routing. A NAT is fundamentally a router,
albeit a pervert one. The purpose of midcom is to obtain connectivity
despite those critters, not to encourage their proliferation.
</soapbox>

-- Christian Huitema

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

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 14 Sep 2001 16:27:23 -0500 (CDT)

> knows how to identify interfaces. 

	Anything pretending to be a security device of course
must know the difference between one interface and another. This
is quite different from having an IP address and netmask assigned
to the interface, and is quite different from knowing about IP
routing in any way shape or form. We call our interfaces "Open"
and "Secure" and perfectly well know the difference between them
even when we're running in our transparent mode.

	The Sun box I referred to didn't (doesn't?) run Solaris,
it was a multi-port bridge with some security features, implemented
on a SPARC platform. Was this their SKIP (VPN) box? Memory fails me.

> These are not part of the MIDCOM charter, AFAIK.

	Fair point!

	However, people have built and continue to build security
devices which are, viewed as network elements, bridges. People
like, say, me.

> despite those critters, not to encourage their proliferation.

	We'll have to disagree on this, it seems.

	Regardless of philosophy, if MIDCOM is built in such a way
as to prevent its use on bridge-like devices, on devices which do
not perform IP routing, it will be far less useful. If the WG elects
to ignore this class of devices and their vendors, so be it.

---

From: Scott Brim <[email-masked]>
Date: Tue, 18 Sep 2001 10:07:31 -0400

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.

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

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

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

  - For complex situations, a way for a middlebox to map realm
    identifiers to interfaces for every realm it might communicate with.

  - Coupling of agents and application signaling proxies, and new
    protocol mechanisms for exchanging realm identifiers.

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

  - Limit the use of such devices to simple cases.  This may be the case
    today.  

  - Use them in conjunction with more full-featured middleboxes.

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

---

From: Scott Brim <[email-masked]>
Date: Tue, 18 Sep 2001 11:08:30 -0400

>          +---R1---+  +---R2---+  +---R3---+

typo ... I meant M4, not M5.