Re: Action item from yesterday's meeting

Hi Suresh,

--On Freitag, 26. November 2004 14:07 Uhr -0800 Pyda Srisuresh 
<[email protected]> wrote:

[...]
|
| I believe, what you & Martin are saying is that a) the transparent proxy
| solution exists for FTP, so vendors should use the proxy solution instead
| of the FTP ALG, and b) The FTP ALG example I gave cannot be used to
| illustrate a problem with the midcom semantics, because it is a solved
| problem (proxy solution). I disagree with this argument because what we
| are talking about in this WG is not replacing ALGs with proxies, but
| rather use Midcom to externalize ALG intelligence. For that reason, the
| FTP ALG example is a good way to illustrate the problem with the sematics
| in the MIB draft. Let me see if I can reword the problem description
| differenctly. Consider the following diagram.
|
|  +----------+                                                +----------+
|  | internal |A0<-->A1         +-----------+          A2<-->A3| external |
|  | endpoint +-----  Internal -+ middlebox +- External -------+ endpoint |
|  | (A0)     |       realm     +-----------+  realm           | (A3)     |
|  +----------+                                                +----------+
|
| An application client, or an application server or a midcom agent acting
| as ALG for a given application can know the session tuples in one realm
| or the other. Only the NAT middlebox knows the combined session tuples

I'm asking myself why a MIDCOM agent cannot know session tuples of 
different realms in general? There may be indeed cases where a MIDCOM agent 
is unable to know another address realm's address tuple in advance, but he 
can learn by using the MIDCOM protocol.  The scenario I refer herewith is 
the same you use:

  +----------+                                                +----------+
  | internal |A0<-->A1         +-----------+          A2<-->A3| external |
  | endpoint +-----  Internal -+ middlebox +- External -------+ endpoint |
  | (A0)     |       realm     +-----------+  realm           | (A3)     |
  +----------+                  MIDCOM server                 +----------+
  Runs Application              twice-NAT
  and MIDCOM agent

In this figure the internal endpoint A0 is for instance resolving the 
external IP address' IP address by means of DNS. The DNS is not modifying 
replies to match the internal address realm of A0 but is keeping the A3's 
address realm. In this case A0 does not know another address realm 
information in advance but learns it on the fly. This information can now 
be submitted to the middlebox, that configures with (A0/A3) tuple and 
returns (A1/A2).  FTP with PORT command works, since you can tell the FTP 
server A2.

When the DNS is modified in the sense that it configures the middlebox 
automatically, either by MIDCOM or any other interface, there is no point 
of having a MIDCOM agent on the internal endpoint. Of course you do not 
know about A3, since this is hidden and so no PORT command is feasible. 
While this may look annoying to you, you must confess that this a reality 
you must accept.  This is the same as with many firewalls/NATs where you 
can only use PASV.

You assume a preconfigured middlebox with a certain A1 being statically 
mapped to a certain A3 (which may be the FTP server) and DNS replying to 
your request for the FTP server's address with A1.  The client at A0 should 
be able to use FTP's PORT command.  The client is opening a connection to 
A1 which is being mapped and forwarded to A3 with a certain A2 (probaly 
chosen dynamically by the NAT on its own).

This all assumes many preconfigured things at the NAT, for instance, the 
mapping (A1,A3) and is likely to be a management issue (retrieving A2 for a 
given A1) than a dynamic configuration issue. I you have preconfigured 
(A1,A3) already why not preconfiguring A2 into the client, so that the 
client can sent it in PORT command.

That are  my 5 cents and I agree to all issues brought up by Juergen stating
- FTP PORT command usage is deprecated.
- Use FTP proxy on you middlebox or use FTP proxy appart from middlebox w/ 
MIDCOM


| (i.e., session tuples in either realm), as NAT sets up the translation
| sessions. Midcom agent can request NAT middlebox to set up NAT sessions
| and learn of the translation parameters,  but it cannot know the
| translation parameters apriori.
|
| In a traditional NAT, A1 and A3 are the same. The current semantics
| assume that midcom agent knows to provide A0 & A1 (as defined above) as
| input for all the PRR/PER queries. This is a reasnable assumption for
| traditional NAT. But, the problem is easy to see when A0 is different
| from A2 and A1 is different from A3. That is why I took the case of twice
| NAT and FTP-ALG for PORT command to illustrate the problem.

FTP with PORT command is solved by MIDCOM when FTP ALG is used and dynamic 
configuration of the box is required.  This should fit the working group 
charter's needs, framework, and requirements.

| But, the
| problem is neither specific to twice-NAT nor the FTP-ALG. You can conjure
| up several scenarios with a) applications that require an ALG and a)
| traversing bi-directional NAT or NAT-PT or a NAT with a combination of
| several types of address maps, and c) the midcom agent only knows the
| session tuples in external realm(i.e., A2 & A3). You will quickly note
| that assuming A0 & A1 alone as input will not be adequate for these apps.

Your argumentation bases implicit on preconfigured middleboxes where one 
side, either inside or outside, is always fixed and entities are only in 
aware of one realm. Coming back to your example if FTP-ALG and NAT. Aren't 
those FTP-ALGs aware of both realms?  How could they otherwise dynamically 
work on FTP connections?

| There must be an option to select the input parameter realm. This is
| exactly what I proposed. Nothing more to it.
|
| Incidentally, this also the issue that I believe, Bob Penfield raised in
| the email dated 08/05 (You can refer the midcom archives fo rthis
| e-mail). Here is an excerpt from the e-mail.
|
|    > 2) Step 3 of the PRR (section 6.4) states that the SNMP manager sets
| the    > internal endpoint address components. This is correct if the
| signaling    > (going thru the MIDCOM client) is outbound. If the
| signaling is inbound,    it
|    > contains the external endpoint addresses.
|    >
|    What I am talking about here is the case where the signaling protocol
| (e.g.    SIP) carries the endpoint media addresses for a media session
| (e.g. in SDP).    A SIP INVITE coming from the external network will hve
| SDP that contains the    address of the external endpoint. The internal
| endpoint media addresses    won't be know until the 200 OK response comes
| from the internal endpoint.

You believe wrong.  This refers to not having all information available at 
on time for SIP.   What Bob is referring to is that calls being inbound do 
not carry enough information to issue an PER even not enough to issue PRR 
(probably the internal IP address is not known at this point).

After reviewing it all again, I fairly assume that should use the NAT MIB 
for your purpose, which is what you are looking for. Since you are looking 
for management information.

Regards,

  Martin