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