Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt
Maoke <fibrib@gmail.com> Wed, 11 April 2012 15:54 UTC
Return-Path: <fibrib@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8C211E809F for <softwires@ietfa.amsl.com>; Wed, 11 Apr 2012 08:54:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.183
X-Spam-Level:
X-Spam-Status: No, score=-3.183 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 MT5-leen-sM2 for <softwires@ietfa.amsl.com>; Wed, 11 Apr 2012 08:54:46 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91D2611E8085 for <softwires@ietf.org>; Wed, 11 Apr 2012 08:54:46 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so779758qcs.31 for <softwires@ietf.org>; Wed, 11 Apr 2012 08:54:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AnGooqx/unvQe6mzHnWgpuJMYwq/CIAhFjGMJ6RgMzk=; b=aD1wDdY9Soivk/GF2RPyy/8HmzxM8M+fTf88l6X3OIGAnHrcd9YKGYpuxNMXOR6dLL yb1N1N88thE60BkDmj91XpGU5MQLqoW5fBCNZseIYcQqOTfWBaKkgLptnWEZ3NeyqnUA TYvu2szVQd1QgI8a752P0/hdNQzVdyb2lIBHtgDqrIPAjXhK3Sn8J8tSbxrdpCr3MS5U H7sJRvhJM56BQhsNHBngHL/0lsaKRysYgxJtEAmNJstI0vyC97h73Gm3L1iSaPa8X4x+ Wr03JNurow6uzwK7qp7ehe9vKje0x7dZGKRvBrDBfqm4/ZG7g2xs16w34hdwD5Q2QcIJ OO0Q==
MIME-Version: 1.0
Received: by 10.224.106.131 with SMTP id x3mr20371245qao.23.1334159686078; Wed, 11 Apr 2012 08:54:46 -0700 (PDT)
Received: by 10.229.123.197 with HTTP; Wed, 11 Apr 2012 08:54:46 -0700 (PDT)
In-Reply-To: <D3CEC27A-D02D-43AF-9285-542BD3FA4855@laposte.net>
References: <20120410094728.8936.48011.idtracker@ietfa.amsl.com> <CAFUBMqXjnUK+-9eA4WwY27x_kkdNWO7vAJCYDpJk5jfd2K81xQ@mail.gmail.com> <69317BAA-F913-4484-898A-0EBC0238121F@laposte.net> <CAFUBMqVxjZkGos7j2RsCnJCwvO5DmPVooB=O7PTuBYbJAbzXfw@mail.gmail.com> <D3CEC27A-D02D-43AF-9285-542BD3FA4855@laposte.net>
Date: Thu, 12 Apr 2012 00:54:46 +0900
Message-ID: <CAFUBMqWEWhSheR9GvB+RXHxG0xOmkCG5ZD1APoHRbtcTmqhjvw@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: multipart/alternative; boundary="20cf3074b41a29937b04bd6942e8"
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 15:54:47 -0000
2012/4/12 Rémi Després <despres.remi@laposte.net> > > Le 2012-04-11 à 15:44, Maoke a écrit : > > > postpone other parts, but focus on the checksum issue. > 2012/4/11 Rémi Després despres.remi@laposte.net > >> >> 5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4 >> message, the ICMPv4 checksum doesn't ensure IPv6 address integrity. But >> this integrity can be ensured at tunnel exit by checking that CNPs do >> preserve checksum neutrality. This can be clarified by a complement in the >> 4rd-u security section. >> >> > > 1. this introduces another new semantics/logic of protocol stack > processing at exit CE. it is really hard to call it either IPv4 or IPv6. > > > How it is called is IMHO secondary, what is a fact is that it ensures > address security. > > > 2. even though this CNP works for the address integrity, > > > (which was the listed point) > > unfortunately, however, the checksum still provides integrity protection > for packet length and payload protocol type in both IPv4/ICMPv4 pair and > IPv6/ICMPv6 pair. they are involved either in IPv4 header checksum or in > ICMPv6 checksum, which covers the pseudo-header of IPv6. > > > > how could CNP protect these? > > > No way, of course. > (Are we now in the technical discussion, or still in deliberate > controversy?). > > technical discussion results in problem understanding instead of certainly a support for or an objection to a work politically. so i don't understand what is the so-called "deliberate controversy" here. i suppose my draft is written very neutral. as you raised a new solution regarding a concern while i found it not complete, i surely need to confirm if you would design a more comprehensive solution for that issue, and if the already-designed mechanism has had the functionality but i was not aware of that. > thanks for mentioning CNP here. > > > i need to modify the concern for "address integrity" to the concern for > "integrity of addresses, packet length and payload protocol type". > > > - Addresses have been covered AFAIAC. > - No test scenario I can imagine can reveal an ICMPv4 security problem > concerning protocol type or packet length. (A simulated hardware failure > would AFAIK be needed, and with that, many other security problems can be > considered to exist.) > > => Unless you come up with new facts, end of this subject for me. > > i don't think it is needed to provide new facts here, at this stage. the test scenario is the next step. the draft is purposed on clarifying these semantics and their direct impact. judgment on the severity of the impacts is remained to the readers. i don't think 4rd-u is scoped within networks with reliable L2 links, isn't it? then, in a generic physical environment, one may think only address checksum is enough, one may think it is not enough, one may think checksum is anyway too weak to provide so-called protection, etc. --- all of these sort of asserts of severity judgment are out of the scope the draft (sec 5 para 1). fine to close this subject for me too because you have clarified "no way". that's enough. a refined statement on this issue will appear in the revision. tomorrow let me clarify another. thanks, maoke > > > RD > > >
- [Softwires] Fwd: New Version Notification for dra… Maoke
- Re: [Softwires] Fwd: New Version Notification for… Rémi Després
- Re: [Softwires] Fwd: New Version Notification for… Behcet Sarikaya
- Re: [Softwires] Fwd: New Version Notification for… Tina TSOU
- Re: [Softwires] Fwd: New Version Notification for… Maoke
- Re: [Softwires] New Version Notification for draf… Satoru Matsushima
- Re: [Softwires] Fwd: New Version Notification for… Rémi Després
- Re: [Softwires] Fwd: New Version Notification for… Maoke
- Re: [Softwires] Fwd: New Version Notification for… Rémi Després
- Re: [Softwires] Fwd: New Version Notification for… Maoke
- Re: [Softwires] Fwd: New Version Notification for… Behcet Sarikaya
- Re: [Softwires] Fwd: New Version Notification for… Maoke
- Re: [Softwires] Fwd: New Version Notification for… Rémi Després
- Re: [Softwires] Fwd: New Version Notification for… Maoke
- Re: [Softwires] Fwd: New Version Notification for… Maoke
- Re: [Softwires] Fwd: New Version Notification for… Rémi Després
- Re: [Softwires] Fwd: New Version Notification for… Maoke
- Re: [Softwires] Fwd: New Version Notification for… Rémi Després
- Re: [Softwires] Fwd: New Version Notification for… Maoke
- Re: [Softwires] Fwd: New Version Notification for… Maoke
- Re: [Softwires] Fwd: New Version Notification for… Rémi Després
- Re: [Softwires] Fwd: New Version Notification for… Maoke