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

Melinda Shore <> Thu, 13 July 2006 19:38 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G171S-0003OQ-DB; Thu, 13 Jul 2006 15:38:54 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G171R-0003O6-1g for; Thu, 13 Jul 2006 15:38:53 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1G171N-0002nM-54 for; Thu, 13 Jul 2006 15:38:53 -0400
Received: from ([]) by with ESMTP; 13 Jul 2006 12:38:49 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="32152831:sNHT25700080"
Received: from ( []) by ( with ESMTP id k6DJcmp2011600; Thu, 13 Jul 2006 15:38:48 -0400
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id k6DJcm7t013916; Thu, 13 Jul 2006 15:38:48 -0400 (EDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 15:38:48 -0400
Received: from ([]) by ([]) via Exchange Front-End Server ([]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Jul 2006 19:38:47 +0000
User-Agent: Microsoft-Entourage/
Date: Thu, 13 Jul 2006 15:38:46 -0400
Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control
From: Melinda Shore <>
To: Teemu Koponen <koponen@ICSI.Berkeley.EDU>
Message-ID: <>
Thread-Topic: [OFF-PATH-BOF] SIP, naming, APIs and control
Thread-Index: Acams/SeM12RfhKnEduQ3AAKleNSdA==
In-Reply-To: <DDEC28E4-2EFE-473A-8456-0633B55AABAA@ICSI.Berkeley.EDU>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 13 Jul 2006 19:38:48.0079 (UTC) FILETIME=[F5DB61F0:01C6A6B3]
DKIM-Signature: a=rsa-sha1; q=dns; l=3603; t=1152819528; x=1153683528; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:Melinda=20Shore=20<> |Subject:Re=3A=20[OFF-PATH-BOF]=20SIP, =20naming, =20APIs=20and=20control |To:Teemu=20Koponen=20<koponen@ICSI.Berkeley.EDU>;; b=FloNAKsAtfiptSxHnJW6eFwcYG/n3H9qothz2dTDhjmKsUqUz8WvNtMhUl5B886CuVnzY3P4 I4loYkPOJevjcXFTJzSgtB0QxUwIqGW6HdLv/nKICdFrpDlvXvB9JuvO;
Authentication-Results:;; dkim=pass ( sig from verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "BOF: Path-decoupled Signaling for Data" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On 7/13/06 2:59 PM, "Teemu Koponen" <koponen@ICSI.Berkeley.EDU> 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:


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


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


OFF-PATH-BOF mailing list