Subject: RE: [midcom] Notion of Flow Direction

From: Randy Turner <[email-masked]>
Date: Sat, 24 Mar 2001 01:46:38 -0800

Regarding the missing line from internal host to name server, the internal
host could automatically update the name server using dynamic DNS (DDNS),
with security (DNSSEC). Within this same zone update, the internal host
could include SRV records indicating port number info as well. But the SRV
stuff would not strictly be necessary for the external host to "find" it on
the network.

Randy

-----Original Message-----
From: Andrew Molitor [mailto:[email-masked]]
Sent: Friday, March 23, 2001 2:08 PM
To: [email-masked]
Subject: Re: [midcom] Notion of Flow Direction

On Fri, 23 Mar 2001, Eliot Lear wrote:

> Andrew,
> 
> Here is the case I mentioned during the meeting.
> 
> An internal server wants to receive flows (that is the word you were
> looking for, I think) from the outside (where outside is some place
> outside a domain).
> 
>    __________                           _________
>   |          |-----[DNS Query]-------->|         |         ___________
>   | external |<---[DNS Response]------<|   N.S.  |        |           |
>   |   host   |                         |_________|        | Internal  |
>   |__________|                                            |   Host    |
>              v                                            |___________|
>              v                          __________                v  ^
>              v                         |          |<--midcom -----/  ^
>              v                         | firewall |                  ^
>              \>>>Connection Attempt>>>>|  / NAT   |>>>>>>>>>>>>>>>>>>^
>                                        |__________|
> 
> 
> You'll note that I have not drawn arrows to the name server.  That's
> because they can be drawn to and from the Internal Host or to and from the
> firewall/NAT.  This boils down to whether you believe that communication
> is a midcom function or a NAT function.  While the Internal Host initiates
> the midcom protocol in this case, someone else could do it on its behalf
> (like a MEGACO controller or some such).
> 
> I've made the assumption that the midcom protocol would initiate from the
> Internal Host.  This doesn't mean that it shouldn't be prepared to receive
> unsolicited midcom protocol messages thereafter (although I'm dubious of
> that).
> 
> In this case, it is clear that two things MUST happen and two things may
> need to happen (the framework must support them):
> 
> 1.  The server or something acting on its behalf must alert the middle box
> that it is interested in such flows.
>
> 2.  Somehow or another a DNS server must be told to return responses to
> the outside with valid information for that outside domain.
> 
> 3.  NAT forwarding bindings may need to be made.
> 
> 4.  Firewall pinholes may need to be opened.

	I think this is all absolutely correct. The variations on the
theme differ mostly in how frequently and how quickly these things happen.
In the normal case, today, all these steps happen more or less once, and
are done manually. For the "site web server" case, for example, we at
Aravox use a proto-midcom protocol implemented over audio channels with
commands like "John, I stuck this web server up at this address, can you
stick something in the NAT and firewall so people can get it, and fix DNS
too? Thanks, man."

	Obviously, it would simplify things if a web server could be
simply configured with credentials and the address of a MIDCOM box, and
it could self-configure the firewall every time it came up, or got a
new address from DHCP. There are apparently some amazing DNS things that
could make the DNS registrations happen at the same time, I know nothing
of these things except that my guys say 'Oh yeah, something-something
does that already, no problem!' so I know it's true.

	Of course, DNS is just one of many ways to publish a globally
useful identifier people can use in well-formed requests of the form
"Connect me to <identity>." SIP and H.323 registrations are, from the
right angle, isomorphic to DNS entries (obviously for the purposes of
other discussions they are totally different -- here, I think they are
basically the same).

	In the SIP version, things get even more complicated. Parts of 2
occur both before and after 1. In this case we replace DNS server with
the SIP proxy's registrar function, and the server with a phone and the
proxy part of the SIP proxy:

2a: The SIP proxy is told that a "potential" server exists inside at
    a phone (note that it IS NOT YET a server, since it's not currently
    listening for media). This potential server has a well defined
    identity like '651-256-2675' or [email-masked]' and some
    way of contacting it.

1. Upon instantiation of a phone call, in either direction, the proxy
   server alerts the middle box that the (now actual, not potential)
   server is interested in such flows (the actual media traffic).

2b. The SIP proxy server (registrar function, more or less?) returns
  information to the outside world about the server, per the results of
  step 1 (the NAT binding)

3. The NAT bindings are made (in practical terms, they're probably
  made in step 1, but they COULD be computed for use in step 1, and
  then activated here)

4. Firewall pinholes are opened.

	I think the issue of advertising higher level names (URLs,
phone numbers, etc etc) is well outside the scope of MIDCOM. The
essential common theme is, I think:

	- infrastructure always has a binding of some externally
	  useful "high level" name (URLs, E.164 address etc) to
	  a private IP address/port.
	- MIDCOM must provide a way to bind, dynamically, an externally
	  useful IP address/port to internal IP address/port
	- thereby producing, by transitivity, a binding of the
	  high level name to the externally useful IP address/port

> At *EACH* of these points the entities acting may need to query a policy
> server of some form.

	I agree, at least with the 'may' caveat. It might be fair
to say that 3 doesn't really need further policy decision, on the grounds
that this decision has been made in steps 1 and 2. That's just in aid
of simplifying the model without, in practical terms, losing
functionality.

	From where I sit, there are two big policy decisions:

	1) does that entity have the right to advertise/publish this
	   high level name?
	2) does that entity have the right to these NAT bindings and
	   firewall pinholes?

	The first is out of scope. The second is at least related to the
scope of MIDCOM. We don't have to solve it, simply ensure that
reasonable solutions are not precluded by some accidental stupid thing
in MIDCOM.

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

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