Re: [OFF-PATH-BOF] SIP, naming, APIs and control
Melinda Shore <mshore@cisco.com> Thu, 13 July 2006 19:38 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G171S-0003OQ-DB; Thu, 13 Jul 2006 15:38:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G171R-0003O6-1g for off-path-bof@ietf.org; Thu, 13 Jul 2006 15:38:53 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G171N-0002nM-54 for off-path-bof@ietf.org; Thu, 13 Jul 2006 15:38:53 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com 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 rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DJcmp2011600; Thu, 13 Jul 2006 15:38:48 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DJcm7t013916; Thu, 13 Jul 2006 15:38:48 -0400 (EDT)
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 15:38:48 -0400
Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Jul 2006 19:38:47 +0000
User-Agent: Microsoft-Entourage/11.2.3.060209
Date: Thu, 13 Jul 2006 15:38:46 -0400
Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control
From: Melinda Shore <mshore@cisco.com>
To: Teemu Koponen <koponen@ICSI.Berkeley.EDU>
Message-ID: <C0DC1986.10CBB%mshore@cisco.com>
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; d=cisco.com; i=mshore@cisco.com; z=From:Melinda=20Shore=20<mshore@cisco.com> |Subject:Re=3A=20[OFF-PATH-BOF]=20SIP, =20naming, =20APIs=20and=20control |To:Teemu=20Koponen=20<koponen@ICSI.Berkeley.EDU>; X=v=3Dcisco.com=3B=20h=3DX1X521665gjuB0ybUPJheZZiEaE=3D; b=FloNAKsAtfiptSxHnJW6eFwcYG/n3H9qothz2dTDhjmKsUqUz8WvNtMhUl5B886CuVnzY3P4 I4loYkPOJevjcXFTJzSgtB0QxUwIqGW6HdLv/nKICdFrpDlvXvB9JuvO;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: off-path-bof@ietf.org
X-BeenThere: off-path-bof@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "BOF: Path-decoupled Signaling for Data" <off-path-bof.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/off-path-bof>, <mailto:off-path-bof-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/off-path-bof>
List-Post: <mailto:off-path-bof@ietf.org>
List-Help: <mailto:off-path-bof-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/off-path-bof>, <mailto:off-path-bof-request@ietf.org?subject=subscribe>
Errors-To: off-path-bof-bounces@ietf.org
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: 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 OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof
- [OFF-PATH-BOF] SIP, naming, APIs and control Teemu Koponen
- Re: [OFF-PATH-BOF] SIP, naming, APIs and control Melinda Shore
- Re: [OFF-PATH-BOF] SIP, naming, APIs and control Teemu Koponen
- Re: [OFF-PATH-BOF] SIP, naming, APIs and control Melinda Shore
- Re: [OFF-PATH-BOF] SIP, naming, APIs and control Saikat Guha
- Re: [OFF-PATH-BOF] SIP, naming, APIs and control Teemu Koponen
- Re: [OFF-PATH-BOF] SIP, naming, APIs and control Saikat Guha
- Re: [OFF-PATH-BOF] SIP, naming, APIs and control Saikat Guha
- [OFF-PATH-BOF] Proposed IRTF agenda Paul Francis
- Re: [OFF-PATH-BOF] SIP, naming, APIs and control Scott W Brim
- Re: [OFF-PATH-BOF] SIP, naming, APIs and control Saikat Guha
- [OFF-PATH-BOF] Proposed IRTF agenda Paul Francis