Subject: [midcom] Questions on middleboxes with more than 2 interfaces

From: [email-masked]
Date: Tue, 30 Jul 2002 14:48:54 -0500

Middlebox experts,

Middleboxes with more than 2 physical interfaces were discussed briefly
in the Yokohama WG sessions and in hallway conversations. I don't think
any conclusions were reached on this, but I could be wrong.

The questions below all come from the fact that the MIDCOM framework,
while it talks about multiple streams both in the private and public
domains, does not talk about whether those data streams are caried on
one physical interface / subnet both in the private and public domains,
or are multiple physicals interfaces possible in each domain. The MIDCOM
semantics I-Ds also are relatively silent on this issue.

So, I'll pose some questions and suggest some answers to get discussion
going on this.

Q1. Can a middlebox have multiple physical interfaces on the private
side or inside?

I don't know of any NATs or firewalls that have this capability, but
I can readily imagine the usefulness and existence of such things. Does
anybody know of any such middleboxes, perhaps other types of middleboxe
than NATter or firewall? I think VPN tunnel switches would have this
capability if they were considered middleboxes.

Q2. Can a middlebox have multiple physical interfaces on the public
side or outside?

Again, I don't know of any, but can imagine this, although not as
readily as multiple interfaces on the private side. VPN tunnel switches
might fit better here.

Q3. If a middlebox has multiple physical interfaces on the private side,
can it have multiple private address realms?

If a NAT had multiple private side interfaces, I could readily imagine
that it could support multiple private address realms.

Q4. If a middle has both multiple private side interfaces and multiple
private address realms, what is the relationship between them?

While I can't see more than one private address realm per private side
interface, I can imagine multiple private side interfaces per private
address realm.

Q5. How would the MIDCOM framework, semantics, protocol, etc., view a
middlebox with multiple private side interfaces or private address realms
or both?

If the middle box had one public side interface and one private address
realm per private side interface, one could define a "virtual" middlebox
per private side interface / private address realm. This may not scale
well, but it might work. The only real problem I see here is that to
"trombone" or "hairpin" from one private address realm to another would
require using addresses in the public realm, which could have problems
with resource consumption, performance, signaling complexity, etc. (This
is (roughly?) equivalent to double NATting.)

If the middlebox had multiple public side interfaces or multiple private
side interfaces per private address realm, then I don't think the multiple
virtual middlebox approach would work well at all. MIDCOM semantics and
protocols would have to be extended to explicitly support this.

Q6. What middlebox semantics and protocol extensions would be required to
support middleboxes such as these?

I can think of several things:
- a rule would have to include up to four sockets (address / port
combinations): source socket; mapped source socket; destination
socket; and mapped destination socket. "source" and "destination"
obviously refer to packet flow in one direction and would be reversed
for packet flow in the opposite direction. For firewall pinholes only
two sockets would be used, three would be used for one-way NAT mappings,
and four for two-way NAT mappings.

- Each unmapped and mapped socket pair, "source" and "destination", would
have to include either an interface identifier or an address realm
identifier. Interface identifiers would allow finer grained rules to be
specified; address realm identifiers might match semantics better. Whether
an interface or address realm was public or private would have to be
derivable from the identifier. Or there would have to be separate private
and public identifer spaces, and then an additional type-of-identifier
parameter (public or private) would have to be included in each socket
pair specification.

- It might be useful to include query capabilities that would enumerate
either all interfaces and address realms, or only those for which a
particular agent is authorized. The interface enumeration should include
the identification of the address realm accessed through that interface.

Q7. Is any of this at all useful? Should we even bother discussing it?

I don't know, that's why I'm asking the questions. :-)

Comments and cogent thoughts welcome and appreciated.

Jim Renkel
Director, Advanced Technology & System Engineering
The CommWorks Corp., a 3Com company

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 30 Jul 2002 15:59:56 -0400

We talked about this quite a bit last year.  The number of
interfaces on a firewall or NAT is clearly outside the scope
of the working group.  The implications of doing much more
than simply providing a blob to pass interface identifiers
around with addresses are mind-bogglingly awful, and the
decision was, basically, to punt.  Let's avoid revisiting
that mess - discussion of what data need to be carried by
the protocol is fine, but discussion about the behavior of
middleboxes in the face of more than two interfaces should
serve only to elucidate the data question and should not be
concerned with specifying behaviors.

Melinda