Subject: RE: [midcom] requirements-01 status

From: "Fleischman, Eric W" <[email-masked]>
Date: Wed, 27 Jun 2001 13:31:31 -0700

>> I believe that we have consensus that directionality in the
>>Pinhole-descriptor is redundant.
>
>From: Bob Penfield [mailto:[email-masked]]
>I'm not sure I agree with this. I know we have gone back and forth on
>directionality and being able to associate a pinhole-descriptor with an
>interface. Could you summarize what you believe is the consensus on any
>requirements (or lack there of) for making sure that packets only flow thru
>the middlebox in the direction the MIDCOM Agents wants them to.

Picture the following possible Pinhole-Descriptor values stored in a 
middlebox:
S_Addr 		S_Port Protocol	D_Addr  		D_Port
110.14.75.100	575	 UDP		156.10.97.11	10600
156.10.97.11	10600	 UDP		110.14.75.100 	575

This is a bidirectional (duplex) flow. Delete one of these lines and it 
is a simplex connection. Please note that the Flow Direction tuple 
proposed in Section 5.2.1 is missing because that information is redundant 
(i.e., the flow direction is inherent going from the source address to 
destination address).

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

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 27 Jun 2001 17:01:17 -0400

----- Original Message -----
From: "Fleischman, Eric W" <[email-masked]>
To: "'Bob Penfield'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 27, 2001 4:31 PM
Subject: RE: [midcom] requirements-01 status

> (i.e., the flow direction is inherent going from the source address to

So it does not matter what physical interface a packet comes in on, if it
matches the pinhole-descriptor it gets through. People are really OK with
this? I don't think I could sell a firewall that allowed that to any IT
manager I know.

In the firewall that we have, you have to specify the source and destination
interfaces (LAN, WAN, DMZ, or * for any) as well as source and destination
IP addresses.

(-:bob

---

From: "Melinda Shore" <[email-masked]>
Date: Wed, 27 Jun 2001 19:37:48 -0400

> this? I don't think I could sell a firewall that allowed that to any IT

Firewalls and routers do this today (do ingress/egress filtering).
This is something that presumably will be static and integral to
the middlebox and its interfaces, handled through whatever management
tools are used for the middlebox, and not something that's going to
be changed on the fly by a midcom agent.  Requiring that agents
have knowledge of network topology to that level of detail is
unnecessary and complex and difficult and unnecessary.  We don't
need it, either.  Let's stick to the problem of providing an
interface between applications and firewalls/NATs.

Please - when advocating for something funky, 1) provide a use
case, 2) let us know what other possible solutions were considered
and rejected, and 3) why you think that your suggestion is the
preferred one.

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 28 Jun 2001 14:18:27 -0400

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
<snip>
> and rejected, and 3) why you think that your suggestion is the

OK, here goes.

Case 1:

A middlebox is doing ingress/egress filtering for SIP signalled sessions
between two domains (A and B). No address translation is required. The
middlebox is just a "bump on the wire" with 2 interfaces, no routing
capability. Any allowed packet received on the interface to domain-A will be
sent out the interface to domain-B and vice versa. A server in domain-A is
performing the SIP proxy and the MIDCOM agent functions. The destination
endpoint IP addresses and ports are extracted from the SDP in the SIP
messages. Assume this is a multi-domain SIP network, thus the endpoints are
not necessarily in either domain-A or domain-B, but could be one or more
domain-hops away. If this is the case, neither the middlebox, nor the MIDCOM
agent can determine the direction of the flows from the IP addresses without
knowing the network topology beyond domains A and B. The MIDCOM agent does
know that the RTP stream from the calling party to the called party will
flow from domain-A to domain-B through the middlebox (the SIP proxy in
domain-A has learned from a location service that the next-hop is a SIP
proxy in domain-B) and that the RTP stream from the called party to the
calling party will flow from domain-B to domain-A.

+-----------+   +-----------+    +-----------+   +-----------+
|Originating|   | Domain-A  |    |  Domain-B |   |Terminating|
|   Domain  |   |           |    |           |   |  Domain   |
|   [UAC]-->+---+->[SP/MA]->+[MB]+-->[SP]--->+---+->[UAS]    |
|           |   |           |    |           |   |           |
+-----------+   +-----------+    +-----------+   +-----------+

Without including some sort of interface/domain information in the pin-hole
descriptor, the middlebox would have to allow the packets through regardless
of which interface they come in on. If the middlebox has separate pin-hole
tables for each interface (to minimize delay in packet forwarding), it would
need to duplicate the pin-hole descriptor in both tables. Thus it opens 4
pin-holes instead of 2.

The best way I can think of to express the 2 pin-holes I want is "from
A:<any> to B:UAS" for the calling to called flow, and "from B:<any> to
A:UAC" for the called to calling flow.

Case 2:

A middlebox performing NAT and firewall between a public domain (i.e. public
IP addresses) and multiple private domains. This middlebox is a bump on 2
wires. It has 2 pairs of interfaces. One pair connects the public domain
(call it A) with one private domain (call it B) and the other pair connects
the public domain with a different private domain (call it C). Both domains
B and C both use the same set of private addresses (e.g. 10.x.x.x). Without
the domain information, the middlebox cannot distinguish between the private
domains.

+-----------+   +----+   +--------+
|           +---+----+---+Domain-B|
|           |   |    |   +--------+
| Domain-A  |   | MB |
|           |   |    |   +--------+
|           +---+----+---+Domain-C|
+-----------+   +----+   +--------+

I can provide a detailed example from SIPland of how this would work, but I
think that would be too much right now (for me and for all the readers).

I think that the domain or the realm is what needs to be expressed in the
protocol rather than specific interfaces. The middlebox can figure out the
physical interface from the domain/realm identifier. This identifier could
be a name or a number. The middlebox would own this identifier (no need for
global uniqueness).

MIDCOM Agents and Middleboxes should not be required to support this. But
the protocol should so that middleboxes and MIDCOM agents that do support it
can use it in the protocol.

OK, let the flaming begin.

cheers,

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 28 Jun 2001 15:16:48 -0400

> be changed on the fly by a midcom agent.

The whole idea of MIDCOM was to allow applications to access these functions
for dynamic flows so these devices would not need application intelligence.
Shouldn't the same parameters used for statically configured pin-holes be
used for dynamic pin-holes?

---

From: "Scott Brim" <[email-masked]>
Date: Thu, 28 Jun 2001 16:42:05 -0400

> > and rejected, and 3) why you think that your suggestion is the

It looks to me like those saying interface specification is not
necessary are assuming other functions in the middlebox which might not
be there.

These test cases are pretty interesting.  In the first case you have a
pure firewall.  It does no routing, it does not even need to be
configured to know what prefixes are reachable on what interface.  I
could pick this up at the supermarket, plug it in, and it would work.
Its only rule is "if it comes in here, check what's allowed, if it's
allowed send it out there".  Since it knows nothing except its allowed
pinholes, interface information seems necessary.  The second case is
more elaborate but again, the key is that the box can do its job with a
lot less software (money), if it has information about allowed
interfaces in the pinholes.

...Scott

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 28 Jun 2001 18:01:45 -0400

> From: Scott Brim <[email-masked]>
> To: Bob Penfield <[email-masked]>
> Cc: Melinda Shore <[email-masked]>; <[email-masked]>
> Sent: Thursday, June 28, 2001 4:42 PM
> Subject: Re: [midcom] requirements-01 status

> necessary are assuming other functions in the middlebox which might not

I think we're all assuming that there's going to be some interaction
with the routing function in the middlebox, whether it's asking it to
route pinhole requests or to make the routing table available to
the middlebox function that's talking to the agent.

I'll try to be clearer about my concerns:

1) Exporting routing tables to midcom agents scales poorly.  Picture
a default-free middlebox.

2) What happens when there are changes to the routing table on the
middlebox?  Do you really want to have agents become participants
in the routing system?

3) Routing pinhole requests is necessarily tied to routing packets.
I think we should leave the separation of routing and forwarding to
other groups.  

4) Exporting routing tables to midcom agents exposes network topology,
which is a security concern and which is deemed unacceptable by some
network administrators

5) Routing functions can be expensive to implement - longest partial
match, etc.  Why should they be implemented in two places in order to
get one packet out one interface?

I think we need to be really, really careful here.

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 29 Jun 2001 09:04:58 -0400

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Scott Brim" <[email-masked]>; "Bob Penfield"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 28, 2001 6:01 PM
Subject: Re: [midcom] requirements-01 status

> a default-free middlebox.

I agree. I am not suggesting that any routing tables be exported.

> middlebox?

The types of middleboxes I am talking about are just a bump on the wire with
no routing information. They don't care when routes change. That's the
router's job.

> Do you really want to have agents become participants
> in the routing system?

ABSOLUTELY NOT!!!

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 29 Jun 2001 09:39:51 -0400

> no routing information. They don't care when routes change. That's the

Another part of a router's job is to choose which interface a packet
goes to.  Any time there's more than one interface (and even then,
I suppose you could argue) you have to choose to send it to one interface
or another.  That's routing.  And while your middlebox may be a bump
in the wire with just two interfaces, we have to accomodate more complex
configurations, too.  What's being asked for here really is a routing
function.

Melinda