Re: [addr-select-dt] ICMP based proposal ?

Arifumi Matsumoto <arifumi@nttv6.net> Mon, 25 October 2010 11:45 UTC

Return-Path: <arifumi@nttv6.net>
X-Original-To: addr-select-dt@core3.amsl.com
Delivered-To: addr-select-dt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BC23A680C for <addr-select-dt@core3.amsl.com>; Mon, 25 Oct 2010 04:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.49
X-Spam-Level:
X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 erQivsK7NA9L for <addr-select-dt@core3.amsl.com>; Mon, 25 Oct 2010 04:45:19 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 67BB63A69F6 for <addr-select-dt@ietf.org>; Mon, 25 Oct 2010 04:45:18 -0700 (PDT)
Received: from [IPv6:2001:fa8:1000::cdbc:c4aa:454a:6182] ([IPv6:2001:fa8:1000:0:cdbc:c4aa:454a:6182]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o9PBl1Wv002842; Mon, 25 Oct 2010 20:47:01 +0900 (JST) (envelope-from arifumi@nttv6.net)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Arifumi Matsumoto <arifumi@nttv6.net>
In-Reply-To: <01db01cb714e$fd61e470$f825ad50$@net>
Date: Mon, 25 Oct 2010 20:47:01 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <873CB2F7-0CF9-49C2-A015-5A19704DE0BC@nttv6.net>
References: <2EFD1BBA-E9B0-4261-BF64-0048294B579B@nttv6.net> <01db01cb714e$fd61e470$f825ad50$@net>
To: Tony Hain <alh-ietf@tndh.net>
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 25 Oct 2010 20:47:01 +0900 (JST)
Cc: addr-select-dt@ietf.org
Subject: Re: [addr-select-dt] ICMP based proposal ?
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <addr-select-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/addr-select-dt>
List-Post: <mailto:addr-select-dt@ietf.org>
List-Help: <mailto:addr-select-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Oct 2010 11:45:20 -0000

Tony,
thank you for your draft.

Before talking about this mechanism itself, let me suggest where to discuss.

IIRC, now that this DT reached conclusion, the chairs have decided that
the next step is to start discussion at 6man ML, and to compare each
solution for the address selection problems.
I think this is a good start to look at Tony's proposal for this purpose.

Can I forward this draft to the 6man ML ?


Regarding the mechanism itself, I find a lot of resemblance with the proposals
discussed before:
http://tools.ietf.org/html/draft-matsuoka-multihoming-try-and-error-00

So, some parts of the analysis of section 3.3 can be applied to this proposal, too.
http://tools.ietf.org/html/draft-ietf-6man-addr-select-sol-03#section-3.3

Other than that, several issues occurred to me.

- the destination address of the ICMP error message.
  ISP's PE perform this rpf check and it may try to send an ICMP error message.
  But, if the source address is not on the routing table, or the route to the
  source address is not the path from which the packet comes from, the PE router
  cannot/may not send an ICMP error message.

  So, it will restrict the use-case to something like a home network attached
  to multiple ISPs via one home gateway device, and the device returns this
  error message for incorrectly source-addressed packets.
 
- notification of a correct prefix.
  if a correct prefix means /64 prefix, an ISP PE router is usually not able
  to return ICMP error message that notifies a correct prefix, as far as the
  PE and a user host is not in the same subnet.

  Notification of a correct prefix is also not feasible at the ISP routers
  located upperstream of PE. This is because they usually have only aggregated
  routes, and do not have per-user prefix information.

- security impact
  Another concern is security risk. It will be possible to inject an ICMP error
  message from remote host. This may lead to a new security attack.

Regards,

On 2010/10/22, at 3:37, Tony Hain wrote:

> http://www.ietf.org/id/draft-hain-ipv6-rpf-icmp-00.txt
> 
>> -----Original Message-----
>> From: addr-select-dt-bounces@ietf.org [mailto:addr-select-dt-
>> bounces@ietf.org] On Behalf Of Arifumi Matsumoto
>> Sent: Wednesday, September 29, 2010 2:32 AM
>> To: Tony Hain
>> Cc: addr-select-dt@ietf.org
>> Subject: [addr-select-dt] ICMP based proposal ?
>> 
>> Tony,
>> Cc: DT members,
>> 
>> I remember you mentioned at the last 6man meeting, that
>> you are going to post a new proposal based on ICMP errors ?
>> 
>> Have you already posted it, or still drafting ?
>> 
>> Do you prefer that it is discussed in DT before 6man ML ?
>> 
>> --
>> Arifumi Matsumoto
>>  NGN System Architecture Project
>>  NTT Service Integration Laboratories
>>  E-mail: arifumi@nttv6.net
>>  TEL +81-422-59-3334 FAX +81-422-59-6364
>> 
>> _______________________________________________
>> addr-select-dt mailing list
>> addr-select-dt@ietf.org
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
> 


--
Arifumi Matsumoto
  NGN System Architecture Project
  NTT Service Integration Laboratories
  E-mail: arifumi@nttv6.net
  TEL +81-422-59-3334 FAX +81-422-59-6364