Re: hop-by-hop and router alert options
Iljitsch van Beijnum <iljitsch@muada.com> Wed, 11 August 2004 13:22 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 JAA03197; Wed, 11 Aug 2004 09:22:07 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1But8C-0007TP-5M; Wed, 11 Aug 2004 09:27:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buswe-00069f-Rg; Wed, 11 Aug 2004 09:15:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BusmO-0004MK-EB for ietf@megatron.ietf.org; Wed, 11 Aug 2004 09:04:32 -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 JAA01674 for <ietf@ietf.org>; Wed, 11 Aug 2004 09:04:30 -0400 (EDT)
Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Busr9-00073M-7I for ietf@ietf.org; Wed, 11 Aug 2004 09:09:27 -0400
Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i7BD6iMW016950; Wed, 11 Aug 2004 15:06:44 +0200 (CEST) (envelope-from iljitsch@muada.com)
In-Reply-To: <Pine.LNX.4.44.0408111448190.24098-100000@netcore.fi>
References: <Pine.LNX.4.44.0408111448190.24098-100000@netcore.fi>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <F80C2B7C-EB96-11D8-A17C-000A95CD987A@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Wed, 11 Aug 2004 15:04:24 +0200
To: Pekka Savola <pekkas@netcore.fi>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: hop-by-hop and router alert options
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: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
On 11-aug-04, at 13:58, Pekka Savola wrote: > 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. Well, think of it this way: by having this option, at least you know you DON'T have to look at all the packets that don't have this option in them. So that's a big fat optimization right there. :-) Obviously there can be DoS issues here, but these can be managed with rate limiting. Just as long as failure by the router to look at the option can be survived in some fashion by the protocol, there shouldn't be any problems. Anyway, this is an operational issue. People who don't want their routers to potentially handle all packets in the slow path should have the option of disabling this feature. Removing existing specifications won't do much good here. (As it almost never does.) _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Question about use of RSVP in Production Networks Fleischman, Eric
- hop-by-hop and router alert options [Re: Question… Pekka Savola
- Re: hop-by-hop and router alert options [Re: Ques… Masataka Ohta
- Re: hop-by-hop and router alert options [Re: Ques… Martin Stiemerling
- Re: hop-by-hop and router alert options Iljitsch van Beijnum
- Re: hop-by-hop and router alert options [Re: Ques… Florian Weimer
- Re: hop-by-hop and router alert options [Re: Ques… Bob Hinden
- Re: Question about use of RSVP in Production Netw… Dean Anderson
- RE: Question about use of RSVP in Production Netw… Ping Pan
- Re: hop-by-hop and router alert options [Re: Ques… David R Oran
- Re: hop-by-hop and router alert options [Re: Ques… Pekka Savola
- Re: hop-by-hop and router alert options [Re: Ques… David R Oran
- Re: hop-by-hop and router alert options [Re: Ques… Melinda Shore
- Re: hop-by-hop and router alert options [Re: Ques… Pekka Savola
- Re: hop-by-hop and router alert options [Re: Ques… James M. Polk
- RE: Question about use of RSVP in Production Netw… Fleischman, Eric
- RE: Question about use of RSVP in Production Netw… John Loughney
- Re: Question about use of RSVP in Production Netw… Bob Natale
- Re: Question about use of RSVP in Production Netw… Dan Wing
- RE: Question about use of RSVP in Production Netw… Bob Natale
- RE: Question about use of RSVP in Production Netw… Tony Hain
- RE: Question about use of RSVP in Production Netw… Fleischman, Eric
- RE: Question about use of RSVP in Production Netw… Dean Anderson