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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 2 Apr 2001 02:42:42 -0400

> -----Original Message-----
> From: Andrew Molitor [mailto:[email-masked]]
> Sent: Friday, March 30, 2001 5:53 PM
> To: [email-masked]
> Subject: RE: [midcom] SIP MIDCOM flow...
> 
> 
> 
> 
> On Fri, 30 Mar 2001, Christopher A. Martin wrote:
> 
> > I am actually performing two functions above. I am 
> considering intiate and
> > terminate to be the process for opening and closing 
> communications between
> > controller and middlebox (with authentication, and perhaps
> > intiating/terminating an encrypted path), and open/close 
> hole as the action
> > request and verification.
> > 
> > I probably need to tie midcom terminology into this call flow.
> 
> 	Goodness! With this definition of Initiate and Terminate, I
> cannot imagine why they're tied in to a call flow. Surely these are
> separate operations which happen entirely outside the call processing
> path? I suppose you COULD re-authenticate for every call, but why on
> earth would you want to?

To be honest, this whole discussion is entirely futile without having
definitions of what midcom operations are needed, at what points in time,
BEFORE assinging names to the messages. It would also be helpful to consider
separately the cases of NAT and firewall, and of calls from inside to
outside and outside to inside. Without that, we end up having more debates
on what INITIATE or TERMINATE mean. I think we have enough debates about
names in this group.

So, in the case of NAT only, and a call from the outside to inside:

Once the INVITE arrives at the proxy from the outside, the proxy needs to
talk to the midcom box. Lets say the SDP in the INVITE are for IP address X,
port Y. The proxy needs to request a binding, say address A, port B, such
that UDP packets that arrive from the INSIDE at the middlebox destined for
{A,B} have their destination address translated to {X,Y} and are then
forwarded OUTSIDE. We can call this "initiate" or "bind request", or
whatever. However, the requirement is that the protocol have such an
operation as a primitive. The input to the operation is X and Y, and the
output is success or fail, along with the resulting binding, A,B. We need to
invoke this operation upon receipt of the INVITE at the proxy.

Now, when the 200 OK arrives at the proxy, the proxy needs to translate the
IP address in the SDP, since its wrong. So, it needs to do another bind
request. In this case, it needs to present the middlebox with an internal
address and port {C,D}, and request a public address on the outside of the
NAT, {U,V}, so that packets that arrive on the outside destined for {U,V}
have their IP address/port rewritten to {C,D}, and are forwarded towards the
inside. The proxy updates the SDP with {U,V}, and forwards the 200 OK
upstream.

I think we need to get to this level of detail, or we are going to continue
to talk past each other.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 2 Apr 2001 08:43:50 -0400

I agree that initiation and termination of communication between the
middlebox controller (SIP Proxy in this case) and the Middlebox should not
be in a call flow. Some SIP Proxies be requesting NATs or FW holes for
hundreds of calls per second.

However, for SIP requesting a NAT, the proxy will need to obtain the NAT
binding before forwarding the INVITE because the IP address and port in the
SDP must be modified.

----- Original Message -----
From: "Andrew Molitor" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 30, 2001 5:53 PM
Subject: RE: [midcom] SIP MIDCOM flow...

> > I am actually performing two functions above. I am considering intiate
and
> > terminate to be the process for opening and closing communications
between
> > intiating/terminating an encrypted path), and open/close hole as the
action
> I think the authentication transaction, and the corresponding
> "log out" transaction should be completely decoupled from pinholes and
> stuff. Obviously a Client (or Controller) may elect to do them as
> indicated, but anything wishing to Go Fast will surely tend to
> authenticate fairly infrequently.
>
> I realize that these call flows are just intended as sort of
> typical applications, but I think it's unrealistic to indicate
> the Initiate and Terminate transactions this closely. If I were
> drawing the flows, I'd have an Initiate transaction first, and then
> an indication of 'some amount of time passes' and then the call setup
> and the call teardown and then another 'some amount of time passes'
> followed by the Terminate.
>
> Somewhat related, are there standard words for this? Surely the
> IPSEC people invented some words for this sort of thing? In the
> absence of other words, I would suggest Authenticate and Logout, or
> Connect and Disconnect, or something. These words are probably as
> meaningless to others as Initiate and Terminate are to me, though.
>
>

---

From: Tim Rang <[email-masked]>
Date: Mon, 2 Apr 2001 18:27:43 -0400

That makes sense, but I think the answer may be for the vendor to use the
abstract primitive type to couple them internally(a NAT that controls policy
as well).

Tim Rang

> From: Abdallah Rayhan [mailto:[email-masked]]
> Sent: Monday, April 02, 2001 5:02 PM
> To: Andrew Molitor
> Cc: [email-masked]
> Subject: Re: [midcom] SIP MIDCOM flow...
> 
> 
> 
> 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.
> >