Re: [OFF-PATH-BOF] SIP, naming, APIs and control

[Melinda Shore <[e-mail]>]

On 7/13/06 2:59 PM, "Teemu Koponen" <[e-mail]> wrote:
> I believe everyone agrees on this; requiring middleboxes to be on the
> path complicates deployment.

Actually, it's my impression that some people agree with this at
this time, but not yet the preponderance of people.

> However, when questioning the point of
> decoupling signaling and data paths, I all the time assumed this
> combined data and signaling path to be different from a path routers
> give you. Is this what you mean or do you opt for three different
> paths: a router given, signaling, and data path?

Ah.  Maybe somebody should write up an informational document
defining some of these terms so that we're at least all using the
same language.  "Off-path" middlebox control assumes that you know
the address of the middlebox you'd like to control and that you
can establish a relationship with it directly (client/server, if
you like).  The actual route taken is irrelevant in terms of
the protocol design, although obviously there may be some operational
considerations.  "On-path" middlebox control typically (but not
always) assumes that you do not know the addresses of any
middlebox along the path or, for that matter, which path the
data will be taking.  It works much like RSVP, where the requests
are addressed to the application peer and intercepted by middleboxes
they happen to traverse.  nsis is actually somewhere in the middle.

>> control/request/communications but not how to solve the extremely
>> difficult problems introduced by even modest topological complexity.
> Could you elaborate these difficult problems?

Probably not exhaustively - every time you think you've got something
licked another one crops up.  But basically, if you're going to
address a middlebox directly you have to know where it is, and again,
aside from operational considerations (operators/network administrators
typically are loathe to reveal the locations of their firewalls, not
to mention configuration/provisioning of firewall locations) you have
to know which firewall is the correct one.  Throw in NATs, and you
start having to know who is where in relationship to each other, so
that you can request the correct firewall pinhole addresses, or QoS
reservations, or anything else that requires installing a network
address in the middle of the network.  For example, if your network
looks like:

    Host----NAT----firewall

you'll need to request an external (to the NAT) address, while if
it's

    Host----firewall----NAT

you'll need to request  the internal (to the NAT) address.

This problem in conjunction with figuring out how to handle multihoming
and route changes is what motivated the topology-insensitive work in the
first place, but the problem is that for the on-path stuff you need a
path, which is a route between two (or more, but we won't go there)
endpoints.  If the other guy doesn't have a network presence because he's
NATted or otherwise invisible, you don't have a path.  Now, it's
possible to start sticking proxies into the network to act on behalf
of unpresent hosts, but that reintroduces the topology problems that
we find in off-path signaling and then you end up, in my opinion, with
the worst of both approaches.

There are some unbelievably hacky workarounds for these problems, but
they introduce other issues around resource consumption and security
vulnerabilities.  In fact, one of the things that I really like
about Paul's proposal is the focus on authorization for middlebox
traversal.  

Melinda

_______________________________________________
OFF-PATH-BOF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/off-path-bof