IETF Logo Mail Archive

Re: Consensus call on adopting <draft-krishnan-6man-rs-mark-08.txt>

Philip Homburg <pch-6man@u-1.phicoh.com> Sat, 23 October 2010 08:40 UTC

Return-Path: <pch-b6B5344D9@u-1.phicoh.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4672D3A6803 for <ipv6@core3.amsl.com>; Sat, 23 Oct 2010 01:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.403
X-Spam-Level:
X-Spam-Status: No, score=-4.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, GB_I_LETTER=-2]
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 dZKogJc754rV for <ipv6@core3.amsl.com>; Sat, 23 Oct 2010 01:40:42 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by core3.amsl.com (Postfix) with ESMTP id 868233A67D7 for <ipv6@ietf.org>; Sat, 23 Oct 2010 01:40:40 -0700 (PDT)
Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1P9ZgA-0001fnC; Sat, 23 Oct 2010 10:42 +0200
Message-Id: <m1P9ZgA-0001fnC@stereo.hq.phicoh.net>
To: "Laganier, Julien" <julienl@qualcomm.com>
Subject: Re: Consensus call on adopting <draft-krishnan-6man-rs-mark-08.txt>
From: Philip Homburg <pch-6man@u-1.phicoh.com>
Sender: pch-b6B5344D9@u-1.phicoh.com
References: <3F7E0126-76FB-43BA-B25F-1EE226FA73AA@gmail.com> <79ECC38B-B7AD-47B1-B6A4-E0B4F75B91F1@gmail.com> <m21v7icp8p.wl%randy@psg.com> <m1P9IGH-0001fnC@stereo.hq.phicoh.net> <4CC19ACF.5070706@ericsson.com> <m1P9IZF-0001gMC@stereo.hq.phicoh.net> <4CC1A3A5.9040209@ericsson.com> <m1P9J7Y-0001VwC@stereo.hq.phicoh.net> <4CC1A846.4030605@ericsson.com> <m1P9KDC-0001iFC@stereo.hq.phicoh.net> <BF345F63074F8040B58C00A186FCA57F29F6C36D06@NALASEXMB04.na.qualcomm.com>
In-reply-to: Your message of "Fri, 22 Oct 2010 10:25:45 -0700 ." <BF345F63074F8040B58C00A186FCA57F29F6C36D06@NALASEXMB04.na.qualcomm.com>
Date: Sat, 23 Oct 2010 10:42:13 +0200
Cc: IPv6 WG Mailing List <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Oct 2010 08:40:46 -0000

In your letter dated Fri, 22 Oct 2010 10:25:45 -0700 you wrote:
>Philip Homburg wrote:
>> In your letter dated Fri, 22 Oct 2010 11:05:42 -0400 you wrote:
>> I wonder what to make of that. If the SEND protected RS messages can be
>> replaced with AN-initiated (unprotected) RS messages, then what purpose
>> does protecting those messages serve in the SEND framework?
>
>The customer host will receive a SEND protected RA, which makes it possible=
> to validate that it comes from a legitimate router (via certificates valid=
>ation) and is not being replayed (via timestamps.)

This implies that the end-device has to be able to match RS messages using 
timestamp, i.e. its clock has to be sufficiantly accurate (to within
5 minutes, according to the SEND RFC) to do that or (in the case of
failure) you would get hard to diagnose problems. An end-device that
requires its own nonce would fail similarly.

I think the draft needs more text about the interaction with SEND in the
case of failure.

v2.23.0 | Report a Bug | By Email