Re: [VRRP] Please clear draft-ietf-vrrp-unified-spec number 2

Jari Arkko <jari.arkko@piuha.net> Fri, 02 October 2009 17:17 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: vrrp@core3.amsl.com
Delivered-To: vrrp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15D53A69FE for <vrrp@core3.amsl.com>; Fri, 2 Oct 2009 10:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.625
X-Spam-Level:
X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 UBbFZzI3U44c for <vrrp@core3.amsl.com>; Fri, 2 Oct 2009 10:17:54 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D5FD23A67B0 for <vrrp@ietf.org>; Fri, 2 Oct 2009 10:17:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 92C84D4936; Fri, 2 Oct 2009 20:19:21 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AVCxzNvPAzJ; Fri, 2 Oct 2009 20:19:20 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B4D38D492B; Fri, 2 Oct 2009 20:19:20 +0300 (EEST)
Message-ID: <4AC63617.5010300@piuha.net>
Date: Fri, 02 Oct 2009 20:19:19 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Stephen Nadas <stephen.nadas@ericsson.com>
References: <450AE4BEC513614F96969DDA34F3593497639A45@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <450AE4BEC513614F96969DDA34F3593497639A45@EUSAACMS0701.eamcs.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 02 Oct 2009 10:27:16 -0700
Cc: "Radia.Perlman@Sun.COM" <Radia.Perlman@Sun.COM>, "vrrp@ietf.org" <vrrp@ietf.org>
Subject: Re: [VRRP] Please clear draft-ietf-vrrp-unified-spec number 2
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2009 17:17:54 -0000

Ok for me (and same for your other mails). So this is just your text 
suggestion or do you actually have a new draft version out there? I 
don't find a new draft version yet...

Jari

Stephen Nadas wrote:
> Hi Jari,
>  
> Regarding this discuss, will the below clear it (I hope so as it's 
> based on your suggestion :-)
>  
> Thanks,
> Steve
>  
> Discuss:
>  
> Thirdly, I do not understand why there is no issue, because the
> backup taking over, because then the backup has to authoratively
> sign the NAs and RAs it is sending, for the primary's address.
> If the "trust anchor and cga" mode from RFC 3971 is used, the
> private key would have to be shared, or this would not work at
> all. And private key sharing is not necessarily a good idea.
>  
> I would recommend saying this:
> - VRRP is compatible with "trust anchor" and "trust anchor or cga" modes
>   of SEND
> - The configuration needs to give the two routers the same
>   prefix delegation in the certificates
> - But still, the routers should have their own key pairs
>  
> Text added at end of section 9:
>  
>    In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND)
>    is deployed, VRRP is s compatible with the "trust anchor" and "trust
>    anchor or cga" modes of SEND [RFC3971].  The (SEND) configuration
>    needs to give the master and backup routers the same prefix
>    delegation in the certificates so that master and backup routers
>    advertize the same set of subnet prefixes.  However, the master and
>    backup routers should have their own key pairs to avoid private key
>    sharing.
>