hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]

Pekka Savola <pekkas@netcore.fi> Wed, 11 August 2004 12:14 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26412; Wed, 11 Aug 2004 08:14:01 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bus4G-00056z-2k; Wed, 11 Aug 2004 08:18:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BurtR-0000pj-N4; Wed, 11 Aug 2004 08:07:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Burl2-0002uN-O4 for ietf@megatron.ietf.org; Wed, 11 Aug 2004 07:59:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24373 for <ietf@ietf.org>; Wed, 11 Aug 2004 07:59:03 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Burpl-0004iV-BP for ietf@ietf.org; Wed, 11 Aug 2004 08:03:58 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7BBwTB24339 for <ietf@ietf.org>; Wed, 11 Aug 2004 14:58:29 +0300
Date: Wed, 11 Aug 2004 14:58:29 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: ietf@ietf.org
In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDD6BB@xch-nw-09.nw.nos.boeing.com>
Message-ID: <Pine.LNX.4.44.0408111448190.24098-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Subject: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4

On Tue, 10 Aug 2004, Fleischman, Eric wrote:
> I am aware of some use of RSVP in labs but I am not aware of any use
> of RSVP in production networks (i.e., real life networks people
> connect to the Internet with). Simultaneously, I am encountering
> I-Ds and other work planning to use RSVP. This possible disconnect
> concerns me. Therefore, I would appreciate being educated by anybody
> using RSVP in production settings. Would you please let me know how
> many devices, what applications, and how successful these
> deployments (if any) are? Thank you.

I'd be interested about this as well, but also in more general.

I'd be in favor of deprecating the IP router alert option completely.  
Effectively this affects RSVP and MLD *).  I'd want to similarly do
away with the IPv6 Hop-by-Hop options.  At the very least, I'd like to
prevent further standardization of these options.

The justification is simple: any "magic" packets which all routers on
the path must somehow examine and process seems a very dubious concept
when we want to avoid DoS attacks etc. on the core equipment which
must run on hardware: effectively this means that either these are
ignored in any case (nullifying the use of such options), or put on a
"slow path" (causing a potential for DoS).  IMHO, it seems just simply
bad protocol design to require such behaviour.

I'm interested what others think about this.. :)

*) MLD should be relatively straight-forward to re-design (just send
the MLD reports to a link-local address which the router is
listening), or just keep it as is for now.  RSVP can probably thrown
away without many tears.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf