Subject: RE: [midcom] requirements-01 status

From: "Sanjoy Sen" <[email-masked]>
Date: Thu, 28 Jun 2001 14:11:59 -0500

I agree with Bob. How would the MB know about the direction the packets will
be flowing from the flow tuple (src., dest. addr,ports, protocol> if the
endpoints are multi-hop away from the MB?

Another instance from VoIP that I can think of where the interface/direction
parameter will be required is when the MA wants to open a pinhole in one
direction to allow the calling user receive Early Media (announcements,
ring-back tones etc) before the call set-up is completed.

Sanjoy

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Thursday, June 28, 2001 1:18 PM
To: Melinda Shore; midcom
Subject: Re: [midcom] requirements-01 status

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
<snip>
> 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.

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]

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

---

From: "Christopher A. Martin" <[email-masked]>
Date: Thu, 28 Jun 2001 14:28:25 -0500

RE: [midcom] requirements-01 statusI also agree with Bob, this should be
closely considered in the requirements.
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Sanjoy Sen
  Sent: Thursday, June 28, 2001 2:12 PM
  To: 'Bob Penfield'; Melinda Shore; midcom
  Subject: RE: [midcom] requirements-01 status

  I agree with Bob. How would the MB know about the direction the packets
will be flowing from the flow tuple (src., dest. addr,ports, protocol> if
the endpoints are multi-hop away from the MB?

  Another instance from VoIP that I can think of where the
interface/direction parameter will be required is when the MA wants to open
a pinhole in one direction to allow the calling user receive Early Media
(announcements, ring-back tones etc) before the call set-up is completed.

  Sanjoy

  -----Original Message-----
  From: Bob Penfield [mailto:[email-masked]]
  Sent: Thursday, June 28, 2001 1:18 PM
  To: Melinda Shore; midcom
  Subject: Re: [midcom] requirements-01 status

  ----- Original Message -----

  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.

  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.

  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.

  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.

  cheers,

  (-:bob

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

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 28 Jun 2001 15:39:26 -0400

> From: Sanjoy Sen <[email-masked]>
> To: 'Bob Penfield' <[email-masked]>; Melinda Shore <[email-masked]>; midcom <[email-masked]>
> Sent: Thursday, June 28, 2001 3:11 PM

> endpoints are multi-hop away from the MB?

A middlebox with more that's got to forward to more than one 
interface is often referred to as a "router," and there are
already mechanisms to do interface selection.  I am *extremely*
wary of 1) trying to replicate network-layer functions in the
application layer, and 2) trying to export network topology
information to applications.  I believe that the correct
approach here is to rely on routers to do their job, including
route determination/selection.

Melinda

---

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

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Sanjoy Sen" <[email-masked]>; "'Bob Penfield'"
<[email-masked]>; "midcom" <[email-masked]>
Sent: Thursday, June 28, 2001 3:39 PM
Subject: Re: [midcom] requirements-01 status

> > To: 'Bob Penfield' <[email-masked]>; Melinda Shore
<[email-masked]>; midcom <[email-masked]>
> > I agree with Bob. How would the MB know about the direction the packets
will
> already mechanisms to do interface selection.

There is no routing in either case. In case 2 there are two separate pipes:
Pipe 1 from A to B and Pipe 2 from A to C. Packets do not cross from pipe 1
to pipe 2. If it goes in to pipe 1 from domain-A, it comes out in domain-B.
If it goes into pipe 2, it comes out in domain-C. It is just more economical
to have one middlebox handle multiple pipes. The function would be the same
if each pipe had a separate middlebox on it.

> I am *extremely*
> application layer, and

What network-layer function does case 1 replicate? It is just a simplified
firewall.

> 2) trying to export network topology

It is a very simplistic form of the topology. Its a name that is useful to
the application like "inside" and "outside".