Re: [MEXT] Issue #2: Recommendation for closure on on "Use of DHAADmechanism"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Issue #2: Recommendation for closure on on "Use of DHAADmechanism"
Hello folks,
I think on this issue #2, that we have pretty good consensus as long as
the following paragraph is not added to the text of rfc3775bis:
* Finally, it should be noted that the specification of ICMP to carry
> * DHAAD incurs a certain deployability risk related to the perceived
> * insecurity of ICMP messages. Many ISPs are blocking ICMP on all links
> * except the first hop, because ICMP is known to be a vehicle for DoS
> * attacks and other sorts of threats.
If anyone wants to champion the inclusion of this text, please do so soon.
Otherwise, I'll go ahead with the other suggested changes on this topic but
not include this ICMP-related paragraph.
Regards,
Charlie P.
Vijay Devarapalli wrote:
* Finally, it should be noted that the specification of ICMP to
carry
* DHAAD incurs a certain deployability risk related to the
pFrom mext-bounces at ietf.org Mon Jul 7 17:51:12 2008
Return-Path: <mext-bounces at ietf.org>
X-Original-To: mip6-web-archive at megatron.ietf.org
Delivered-To: ietfarch-mip6-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 45CC628C377;
Mon, 7 Jul 2008 17:51:12 -0700 (PDT)
X-Original-To: mext at core3.amsl.com
Delivered-To: mext at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id EAB0128C14D
for <mext at core3.amsl.com>; Mon, 7 Jul 2008 17:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id TDHMUbYwIL8A for <mext at core3.amsl.com>;
Mon, 7 Jul 2008 17:51:10 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net
(elasmtp-banded.atl.sa.earthlink.net [209.86.89.70])
by core3.amsl.com (Postfix) with ESMTP id 0FA3F28C377
for <mext at ietf.org>; Mon, 7 Jul 2008 17:51:10 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net;
b=YoTNJSR4hm8neuBDnGR2hDzwqOQDnG+jnMxDAmeXU3JvJZaJtVbdpSc83n0cy1Um;
h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [66.245.12.28] (helo=[192.168.1.4])
by elasmtp-banded.atl.sa.earthlink.net with esmtpsa
(TLSv1:AES256-SHA:256) (Exim 4.67)
(envelope-from <charles.perkins at earthlink.net>)
id 1KG1QD-0001TB-Vy; Mon, 07 Jul 2008 20:51:11 -0400
Message-ID: <4872B9F5.1040704 at earthlink.net>
Date: Mon, 07 Jul 2008 17:51:01 -0700
From: "Charles E. Perkins" <charles.perkins at earthlink.net>
Organization: Wichorus Inc.
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: mext at ietf.org
References: <200803271024.49601.julien.IETF at laposte.net><48654BFB.5000005 at earthlink.net>
<87ej6hzr5x.fsf at natisbad.org>
<DE33046582DF324092F2A982824D6B03038A8FF3 at mse15be2.mse15.exchange.ms>
In-Reply-To: <DE33046582DF324092F2A982824D6B03038A8FF3 at mse15be2.mse15.exchange.ms>
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5281a6710e810a06640e5251f94a5760b9350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 66.245.12.28
Subject: Re: [MEXT] Issue #2: Recommendation for closure on on "Use of
DHAADmechanism"
X-BeenThere: mext at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext at ietf.org>
List-Help: <mailto:mext-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: mext-bounces at ietf.org
Errors-To: mext-bounces at ietf.org
Hello folks,
I think on this issue #2, that we have pretty good consensus as long as
the following paragraph is not added to the text of rfc3775bis:
* Finally, it should be noted that the specification of ICMP to carry
> * DHAAD incurs a certain deployability risk related to the perceived
> * insecurity of ICMP messages. Many ISPs are blocking ICMP on all links
> * except the first hop, because ICMP is known to be a vehicle for DoS
> * attacks and other sorts of threats.
If anyone wants to champion the inclusion of this text, please do so soon.
Otherwise, I'll go ahead with the other suggested changes on this topic but
not include this ICMP-related paragraph.
Regards,
Charlie P.
Vijay Devarapalli wrote:
* Finally, it should be noted that the specification of ICMP to
carry
* DHAAD incurs a certain deployability risk related to the
erceived
* insecurity of ICMP messages. Many ISPs are blocking ICMP on all
links
* except the first hop, because ICMP is known to be a vehicle for
DoS
* attacks and other sorts of threats.
IMHO, this should go.
I agree, but for a different reason though. If ICMP is blocked, isn't it
obvious that DHAAD messages can't make it through?
Viujay
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext
perceived
* insecurity of ICMP messages. Many ISPs are blocking ICMP on all
links
* except the first hop, because ICMP is known to be a vehicle for
DoS
* attacks and other sorts of threats.
IMHO, this should go.
I agree, but for a different reason though. If ICMP is blocked, isn't it
obvious that DHAAD messages can't make it through?
Viujay
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
