Subject: Re: [midcom] SIP MIDCOM flow...

From: "Abdallah Rayhan" <[email-masked]>
Date: Mon, 02 Apr 2001 17:01:59 -0400

Your example shows NAT/pinhole opening as two separate actions.
It does make sense in certain scenarios. However, the protocol
should be capable of coupling the two if necessary. For example
give me NAT'ed address and open the whole at same time. If one
action fails, the other fails too. To make such a thing possible,
it might be needed to define the latter in terms of the former.
That is to say, the subject of the latter is a variable referencing
the ip to be from the NAT.

regards
Abdallah

Andrew Molitor wrote:

> All Singing All Dancing Firewall+NAT Across Two Networks
> --------------------------------------------------------
> 
>      Application A     MidBox A            MidBox B      Application B
>            |              |                   |                |
> Call Initiate             |                   |                |
>  from X    |              |                   |                |
>   -------->| NAT REQ      |                   |                |
>            |------------->|                   |                |
>            | Target: X    |                   |                |
>            | Source: *    |                   |                |
>            |              |                   |                |
>            | NAT RESP     |                   |                |
>            |  Map: X->X1  |                   |                |
>            |<-------------|                   |                |
>            |              |                   |                |
>            |             Call Initiate From X1|                |
>            |-------------------------------------------------->| (locate dest
>            |              |                   |                |   at Y and fwd
>            |              |                   |                |   initiate)
>            |              |                   |                |
>            |              |                   |                |  ACK from Y
>            |              |                   |                |<-----------
>            |              |                   | NAT REQ        |
>            |              |                   | Target: Y      |
>            |              |                   | Source: *      |
>            |              |                   |<---------------|
>            |              |                   |                |
>            |              |                   | NAT RESP       |
>            |              |                   |  Map: Y->Y1    |
>            |              |                   |--------------->|
>            |              |                   |                |
>            |              |                   | Open Pinhole   |
>            |              |                   |  X1 --> Y1     |
>            |              |                   |(or * --> Y1?)  |
>            |              |                   |<---------------|
>            |              |                   |    ACK Pinhole |
>            |              |                   |--------------->|
>            |              |                   |                |
>            |              |                   | Open Pinhole   |
>            |              |                   |  X1 <-- Y1     |
>            |              |                   |(or X1 <-- * ?) |
>            |              |                   |<---------------|
>            |              |                   |   ACK Pinhole  |
>            |              |                   |--------------->|
>            |              | ACK From Y1       |                |
>            |<--------------------------------------------------|
>            |              |                   |                |
>            | Open Pinhole |                   |                |
>            |  X1 --> Y1   |                   |                |
>            |(or * --> Y1?)|                   |                |
>            |------------->|                   |                |
>            | ACK Pinhole  |                   |                |
>            |<-------------|                   |                |
>            |              |                   |                |
>            | Open Pinhole |                   |                |
>            |  X1 <-- Y1   |                   |                |
>            |(or X1 <-- *?)|                   |                |
>            |------------->|                   |                |
>            | ACK Pinhole  |                   |                |
>            |<-------------|                   |                |
>            |              |                   |                |
>            |              |                   |                |
>   ACK From |              |                   |                |
>     Y1     |              |                   |                |
>   <--------|              |                   |                |
> 
>         Note that there is an issue of whether pinholes are opened
> for pre-NAT addresses, post-NAT addresses, Internal addresses or
> External Addresses (there are indeed 4 cases). Indicated above, pinholes
> are indicated for External addresses.
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom

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

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 2 Apr 2001 17:38:09 -0500 (CDT)

> the ip to be from the NAT.

	As an architect, I say 'what a good idea!' and as an implementor
with an existing framework, it makes me turn white as a sheet and break
out in a cold sweat. I suspect that it is useful somewhat less frequently
than you might imagine.

	Since the WG is to deal with existing middlebox class devices,
would it be ok to allow this as an optional transaction which might
fail, and cause the client to fall back on the two step version?

	The alternative is to force everyone in the middlebox business
to build a more complex MIDCOM adaptation layer which can handle the two
steps internally.

	This raises a more general question:

	- do we prefer to develop the smallest possible set of
	  primitives which still manage, perhaps with some effort, to
	  express everything necessary
or:
	- do we prefer to devise more complex primitives which most easily
	  express everything needed.

	This really comes down to:

	- make MIDCOM servers easy to write atop existing middleboxes
	  at the expense of more complex client software
	- make MIDCOM servers hard to write atop existing middleboxes
	  in order to make client software easier to write

	Obviously this isn't really two choices, but a spectrum of them.
Note also the usefulness of 'MIDCOM server' as a separate element
to middlebox ;)

> Abdallah

		Andrew

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 3 Apr 2001 09:06:03 -0400

----- Original Message -----
From: "Andrew Molitor" <[email-masked]>
To: <[email-masked]>
Sent: Monday, April 02, 2001 6:38 PM
Subject: Re: [midcom] SIP MIDCOM flow...

>   express everything needed.
We obviously want to keep things as simple as possible, but there are
certain sets of operations that clients would like to do in a single
operation (like NAT+open pin-hole) to limit traffic between the controller
and the middlebox. If a middlebox is capable of this, it should be allowed.
> Note also the usefulness of 'MIDCOM server' as a separate element
I think we need to be very flexible in the protocol requirements in order to
maximize both. I don't think we can necessarily say that a small set of
primitives will make it easier to make a MIDCOM server atop an existing
middlebox. It all depends on the architecture and design of the middlebox.
> Andrew

Bob
d:-)

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