Re: [v6ops] Fwd: 82nd IETF DRAFT Agenda

Ray Hunter <v6ops@globis.net> Wed, 26 October 2011 20:04 UTC

Return-Path: <v6ops@globis.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C1A11E80A3 for <v6ops@ietfa.amsl.com>; Wed, 26 Oct 2011 13:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Level:
X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jguxdI5YSjaL for <v6ops@ietfa.amsl.com>; Wed, 26 Oct 2011 13:04:32 -0700 (PDT)
Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 399A021F84B9 for <v6ops@ietf.org>; Wed, 26 Oct 2011 13:04:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4403A870083; Wed, 26 Oct 2011 22:04:30 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrY-fa6-NCsu; Wed, 26 Oct 2011 22:04:23 +0200 (CEST)
Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 757F787007E; Wed, 26 Oct 2011 22:04:23 +0200 (CEST)
Message-ID: <4EA867C7.3050705@globis.net>
Date: Wed, 26 Oct 2011 22:04:23 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Warren Kumari <warren@kumari.net>, Xing Li <xing@cernet.edu.cn>
Content-Type: multipart/alternative; boundary="------------020305000803000805070407"
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: 82nd IETF DRAFT Agenda
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Oct 2011 20:04:35 -0000

I raised concerns about draft-xli-v6ops-ivi-icmp-address-00.txt when it 
was originally discussed on this list last July.

The draft has not been updated since, so my concerns remain.

There now seems to be a number of people on the list who see its 
benefit, and are supporting the draft.

IMHO Due consideration should be made to weigh up the likely operational 
cost incurred because (many?) operators will have to change a lot of 
operational filters (to avoid the very likely abuse of this special 
range as a DDOS source) against the likely operational benefit for the 
(few?) operators who have applied this technology.

There are alternatives available for address ranges to use as a source 
address of translations within the AS without assigning a new global 
special purpose range (either RFC1918, or a privately assigned block of 
public IPv4 addresses from existing space, which can be shared between 
operators).

Admittedly the alternatives are not very attractive. But neither is the 
translation of ICMP messages into a packet that carries very little 
value or information when observed outside of its own AS, which is not 
traceable, and which could in fact become a danger thus triggering a 
need for mass packet filter updates.

I asked at the time: can anyone think of any other example of a 
"one-way" special purpose packet that is allowed to leave the link, 
never mind the AS?  RFC1918 addresses are not allowed to cross 
inter-enterprise links (for good reasons).

Regards,
RayH

> Subject:
> Re: [v6ops] Fwd: 82nd IETF DRAFT Agenda
> From:
> Warren Kumari <warren@kumari.net>
> Date:
> Wed, 26 Oct 2011 07:32:35 -0400
>
> To:
> Xing Li <xing@cernet.edu.cn>
> CC:
> "v6ops@ietf.org WG" <v6ops@ietf.org>, V6ops Chairs 
> <v6ops-chairs@tools.ietf.org>
>
> Content-Transfer-Encoding:
> quoted-printable
> Precedence:
> list
> MIME-Version:
> 1.0 (Apple Message framework v1084)
> References:
> <20111013211312.B6C7421F8AFF@ietfa.amsl.com> 
> <619C3B81-1CDC-4341-8180-EC8472864CC0@cisco.com> 
> <4EA53FB7.6090603@cernet.edu.cn>
> In-Reply-To:
> <4EA53FB7.6090603@cernet.edu.cn>
> Message-ID:
> <C8B7882E-F8F0-4E65-AC5C-D8CDA24DC0EC@kumari.net>
> Content-Type:
> text/plain; charset=utf-8
> Message:
> 1
>
>
> On Oct 24, 2011, at 6:36 AM, Xing Li wrote:
>
>    
>> >  Hi, Fred and All,
>> >  
>> >  ? 2011/10/14 5:52, Fred Baker ??:
>>      
>>> >>  The initial version of the agenda has been posted. It places v6ops on Wednesday and Friday mornings, a total of 4.5 hours. I personally am satisfied with it, but if folks have issues I can pass them along.
>>> >>  
>>> >>  I'll note that the deadline for -00 drafts is 24 October, and the deadline for updated drafts is a week later. For discussion in the working group meetings, I'm looking for a draft posted after 25 July, with supporting email discussion on the list.
>>> >>  
>>> >>  I'm looking for (and in some cases have seen) commentary on each of:
>>> >>  
>>> >>  -rw-rw-r--  1 fred  fred  13796 Jul 25 23:59 draft-xli-v6ops-ivi-icmp-address-00.txt
>>>        
>> >  
>> >  I would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption.
>> >  
>> >  The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation (192.70.192.0/24) to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
>> >  
>>      
>
> Summary:
> I support adoption.
>
> More words:
> I must admit to being somewhat uncomfortable with the potential for using this space to hide that actual course of a DoS -- yes, this is somewhat addressed in the Security Considerations, but that doesn't actually remove the problem.
> That said, the sad fact is that with so many networks not doing BCP38 you already have no faith in the source address of a packet IMO the benefits outweigh the risks.
>
> W
>
>