Subject: [midcom] Notion of Flow Direction

From: Jiri Kuthan <[email-masked]>
Date: Fri, 23 Mar 2001 01:29:35 +0100

Hi,

let me kick the issue we put off-line during the meeting:
direction of packet flows.

I think there are cases in which a middlebox is happy to know
expected direction of a flow. 

The question is whether the direction determination logic should 
reside 1) in the middlebox or 2) in midcom client and be communicated 
to middlebox via the midcom protocol.

At least in SIP scenarios, the logic seems to lend itself to live in the 
middlebox: The middlebox operates on IP layer as opposed to a midcom
client living in application space. And I would not prefer putting 
the burden of topological logic on applications.

Can someone name a scenario in which it is desirable for the logic to
live in a midcom client?

Jiri

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

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 22 Mar 2001 19:16:31 -0600 (CST)

> to middlebox via the midcom protocol.

	I don't understand the question!

> the burden of topological logic on applications.

	There are at least two things going on here:

	the midcom client may or may not have a notion of
	which way the session initiation will happen (which
	end will send or receive the FIRST packet with a
	given 5-tuple)

	the middlebox may or may not a) care what the direction
	of session initiation is and/or b) have a way to enforce
	this direction.

	Let me invent a phrase: 'transport session', to denote a
bunch of related packets with the same 5-tuple in either direction.
This is synonymous with TCP connection if the packets happen to
be TCP, and an RTP media stream also counts. If there's a better
word, let me know?

> Can someone name a scenario in which it is desirable for the logic to

	In every scenario I have thought up the following is true:

	1) the midcom client knows the direction in which every
	   transport session it cares about will initiate.
	2) NAT middleboxes care deeply about this information (NAT
	   will not in general work without this information).
	3) firewall middleboxes can enforce this
	   transport-session-initiation-direction

	In some cases:

	4) the midcom client has a firm idea of packet direction as
	   well (e.g. RTP flows are unidirectional)
	5) the middlebox can enforce this too

	I propose that directionality be a required element of the
protocol, both for session initiation and for packet-flow. My experience
is, to put it mildly, not universal, so certainly there may be
cases where 1-3 do not obtain. The protocol should probably allow
a "don't care" for direction, where applicable (not NAT). To be
precise:

	- the protocol should allow the midcom client to
	  specify the expected directions of both transport
	  session initiation and packet flow, and allow
	  values of 'don't care' and 'bidirectional' as valid
	  directions (I guess 'bidirectionsl' makes no sense
	  for transport session initiation direction?)
	- clients should send this information along to the extent
	  that they know it
	- servers should parse and understand direction information,
	  and require it where, well, required
	- middleboxes should enforce it, as far as they are capable
	  of it

	Some scenarios in which directionality appears, expressed
as operations desirable in MIDCOM protocol ("I" am a midcom client,
"you" are a midcom server):

	a) I have an address/port off interface A of you, please
	   give me an address/port good on interface B which will
	   translate to the set I gave you. E.G. A phone "inside"
	   at 192.168.1.22 is waiting for media at port 5000,
	   I need a public address and a port I can stuff in the
	   SIP invite which I send to a phone on the "outside." When
	   the outside phone sends media to interfaces B bound to
	   whatever the returned address/port is, the media packets
	   get translated and sent out A to 192.168.1.22/5000.
	   Outbound active FTP is isomorphic.

	b) I am expecting a TCP stream to come from some host
	   at address X, to address Y, and these are the ports. Let
	   it through. E.G. An H.245 stream from one entity to
	   another.

	c) I am expecting a bunch of UDP packets from somewhere,
	   I don't know where, going to this address and port. Let
	   them in. E.G. SIP media (you know the destination, but
	   not the source).

	In case a), you need to know that the session will initiate
from the outside. NAT bindings MUST be attached to an interface,
otherwise the NAT doesn't support overlapping addresses spaces. That
is, if the binding was global to the box, and we were connecting
two private networks both using 10.0.0.0, it would be easy to create
ambiguous bindings. Which 10.0.1.92 did you mean? I have two of them!
Aig! Note that it makes a lot of sense bind in both directions.
Aravox (my employer) accordingly has implemented both 'bind local
address to an "outside" address' and 'bind remote address to an
"inside" address' to allow transport sessions to initiate in
either direction and yet to still enjoy all the pleasures of dynamic
NAT binding. With >2 interfaces, "remote" versus "local" becomes
useless, but you still can speak of NAT bindings on a per interface
level.

	In case b) it makes a LOT of sense to enforce the transport 
session initiation direction, and even cisco ACLs can do it, so I
assume any device with pretensions of firewallhood can do it too.
Without this enforcement, certain nasty attacks become possible:
if you can fool something into a state in which it thinks something
at some unknown address INSIDE is about to connect TO port X
on OUTSIDE host Y (think H.245), and you don't enforce transport
session initiation direction, you have just let host Y into your network,
with total access. Ooo, but only if Y uses port X locally. Since Y
probably picked X out, this is not a problem.

	In case c) we have both transport session initiation and
actual packet flow direction (note that packet flow is either bidirection
or agrees with the transport session initiation direction). It makes
sense, if possible, to enforce this direction, just because, hey, the
tighter you can screw things down, the better.

	Things get more amusing when you start to combine NAT with
pinholing. Which of the 4 possible sets of addresses do you use
for the pinholes? Whee!

	Was that helpful, or just very damn long?

---

From: Eliot Lear <[email-masked]>
Date: Fri, 23 Mar 2001 08:24:53 -0800

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.

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

Note that it is conceivably possible that each of these would require some
sort of protocol exchange.

Regards,
--
Eliot Lear
[email-masked]

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 23 Mar 2001 16:08:21 -0600 (CST)

> looking for, I think) from the outside (where outside is some place

	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

	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.

---

From: "Melinda Shore" <[email-masked]>
Date: Sat, 24 Mar 2001 08:10:27 -0500

> the outside with valid information for that outside domain.

Or some other kind of directory server - there are
several ways to do this, and other ways that won't
work at all.  In the VoIP case we assume that 1) the
terminal or user has registered with some sort of 
call control server and therefore the server knows
where the endpoint is, 2) the call control server
*is* visible to the rest the network, and 3) a
calling party or its call control server has some
way of finding the called party's call control server
(and that may well *not* be DNS).  It all kind of
flows from there.  Clearly some other sort of
"call" establishment mechanisms need to be documented
for simpler, more end-to-endish applications.

Melinda