Subject: Re: [midcom] SNMP - using as a transport layer?

From: [email-masked]
Date: Fri, 21 Jun 2002 18:02:02 -0500

On 06/21/2002, at 01:46:10 P.M., Keith Moore wrote, in part:

>   RSIP is not a general solution, ...

Agreed, RSIP (or MIDCOM), by itself is not a general or complete solution.
You always have to add something else: application modifications, agents,
or platform modifications. The question is, "Which one(s) are easiest /
best for a given situation?". Since, I believe, all three have some
validity, somewhere, we should be sure that all three are possible to
implement if needed. (BTW, adding support to MIDCOM for tunnels is, I
believe, almost a trivial protocol extension.)

>   ... and it's very cumbersome to use.

Our experience is quite the contrary: once implemented in a platform,
well written applications (in general, this means, ones that support
"multi-homed hosts".) work transparently and without modification. We
have tested quite a few: some have a few problems, many don't; those
with problems are generally easy to fix.

Also, the semantics proposed for MIDCOM in, e.g., draft-taylor-midcom-
semantics-00.txt and draft-stiemerling-midcom-semantics-00.txt, look an
*awful* lot like the semantics for RSIP. If RSIP is as cumbersome to
use as you claim, well, then MIDCOM is going to be cumbersome to use.
Sorry. :-(

>   Neither apps nor hosts can be expected to know when to use the RSIP
>   address and when to use the local realm address, especially when
>   referring one address to another host which might or might not be
>   in a different realm.  RSIP cannot solve this problem, and neither
>   can MIDCOM.

It seems to me there's two cases here:

1) server applications that listen on well-known ports for connections
from unknown clients. Server applications that support multi-homed hosts
will listen on each subnet to which the host is connected for connections.
With RSIP, since middlebox tunnels appear as another (albeit virtual)
network adapter, server applications tend to listen on them just like
they listen on real subnet adaptors.

Granted, some server applications aren't smart enough to automatically
look for all subnet appearances on the host. Instead they rely one some
kind of .ini file to configure them. In this case, ya gotta add another
line to the .ini file, just as if the host appeared on multiple physical
subnets. Once that's done, clinets can and do connect!

2) applications (either clients for initial connections to servers, or
in some cases servers for additional connections to already connected
clients) that want to connect to a known IP address. In this case, the
host platform (i.e., OS and network protocol stacks) can determine from
the IP address the correct subnet (either physical or virtual) to use.

These "tricks" work not because of RSIP the protocol, but because of
RSIP's architectural use of tunnels. What it really comes down to is
tunnels can be made to look just like physical network adapters, and
then anything that works with multiple physical adapters will work with
tunnels. And when the tunnel goes to a middlebox, connections over the
tunnel go right through the middlebox to the correct host in the "outside"
realm, just like ya'd want them to.

Ya need a protocol so the host platform can work on synchronozation with
the middlebox. That's what MIDCOM (and RSIP) are for. Maybe in conceiving
MIDCOM, folk didn't think of it that way, instead only thinking of
application modifications or adding application agents (Remember, NAT
ALGs are really just application agents resident on the middlebox.).

But if ya *do* think of it that way, host platform modifications are
better than host application modifications or adding application agents,
at least in some situations.

Another way to think about this is to consider, e.g., the Microsoft VPN
dial-up adapter for Windows. It uses a tunnel to a tunnel terminator in
the remote network. I have yet to see a Windows application that doesn't
work with the VPN adapter (I'm sure there are some out there, I just
haven't seen them yet. And you can but your bippy that those that don't
work, their vendors are working nights and week-ends to make them work!)
Replace "VPN tunnel" with "middlebox tunnel" and "tunnel terminator" with
"middlebox" and ya've got the RSIP "tunnel to middlebox" architecture! I
can't think of any good reason why MIDCOM should not take advantage of
this.

>   false.  see above.

Well, we and others have done it and it works. Thousands of Microsoft
Windows users are using the same basic architecture every day. What more
can I say?

This e-mail is being written from the recliner in my media room at home
on a laptop running the Lotus Notes client (This is not an exdorsement of
Notes!!!) connected to a Lotus Notes server back at the office over a VPN
tunnel that, BTW, traverses at least two NAT boxes (One in my home and
one in my ISPs network.) and one firewall (At the office.). If this
message reaches everybody, as I'm confident that it will, it is proof
that applications that weren't specifically designed to support tunnels
work with tunnels without modification. Yup, I had to install the VPN
adapter into Windows on my laptop. Like I said, nothing comes for free.
But having installed it, every application I want to use "automagically"
works over the tunnel, and around the tunnel, and knows whether to use
the tunnel or not, without any application modification. What more could
I ask for? Well, make it work with middleboxes, for one thing! :-)

The only real issue here for MIDCOM and RSIP is the host platform knowing
enough to set up the tunnel. That's an issue of middlebox discovery.
Stayed tuned; more on that another day.

>   ... I do think we could fairly easily provide
>   means for apps that have trouble with NATs to use IPv6 while
>   still allowing apps that work with NATs to use them.

This sounds interesting and appealing, but I can't figure out by myself
how you would do it. Can you provide a description or some hints?

>   it's a
>   lot easier to accomplish this than to get those apps to work sanely
>   with either RSIP or MIDCOM, and it's also a more general solution.

Well, then this solution would have to be *extremely* easy and
*completely* general, 'cause middlebox tunnels are easy for applications
to use (Admitted, there's some work to be done in the platform; nothing
comes for free.) and have worked (or easily been made to work) in every
situation that they've been tried.

>   so while the NATs might still exist, they wouldn't be relevant to
>   apps that couldn't deal with them.

I'm not sure I follow this. Maybe it's just late in the day and late in
the week. :-) Maybe you could help to understand this?

Sorry this response is so long. But it's just getting interesting!!! :-)

Jim

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Jun 2002 19:27:35 -0400

[cc list trimmed]

> best for a given situation?". 

well, if you treat each possible situation separately, you're going to
end up with a great deal more complexity and expense than if you
build a general solution.

> Since, I believe, all three have some
> implement if needed. 

"validity" assumes that a general solution is not feasible.

> "multi-homed hosts".) work transparently and without modification. 

I suspect you're imposing some other constraints also - such as 
what does it really mean to support "multi-homed hosts".

but I invite you to attempt to port NetSolve to a RSIP environment,
or an environment where some nodes use NAT+RSIP and some have
stable, global addresses.

> use as you claim, well, then MIDCOM is going to be cumbersome to use.

I never claimed otherwise.  To me they're both quite cumbersome, and
furthermore, I don't think it's possible to improve on this much
as long as NATs are in the picture.

> the IP address the correct subnet (either physical or virtual) to use.

no they cannot, because they do not know what in context that IP address
works.

> realm, just like ya'd want them to.

problem is, you don't in general know which realm the destination host is in.
and there can quite possibly be more than an inside and an outside realm.

> Remember, NAT
> ALGs are really just application agents resident on the middlebox.

given that ALGs often interfere with apps, that's rather a strange view.

> work with the VPN adapter 

it will work fine as long as the app *only* needs presence in the remote
realm.  as soon as the app needs presence in multiple realms, the technique
breaks.

> Windows users are using the same basic architecture every day. What more

I believe you have it working for some apps.  I don't believe you have
a general solution  that requires minimal modification of apps and doesn't
impose constraints on where components are placed relative to the network
topology.

> work with tunnels without modification. 

some applications.  making a single point-to-point connection work over a 
tunnel is not rocket science, and Lotus Notes is (as you implied) a
client-server app.

> the tunnel or not, without any application modification. 

it might work for you and for the apps that you want to use.  it does not
work in general.  in particular, there's no way for the RSIP stack to
decide whether to use the tunnel or not if the address ranges used by
the different realms overlap, as they likely will if you're running
an app that has components in multiple private networks.

> how you would do it. Can you provide a description or some hints?

the basic idea is to add v6 support to the NATs.   details will require
an I-D (I probably won't get it written by Monday).

> situation that they've been tried.

again, I invite you to try them with NetSolve, or PVM, or almost any
distributed app.  I don't think you're trying very hard.  Next think 
you'll tell me is that these apps are not well-behaved :)

Keith