[VRRP] Please clear draft-ietf-vrrp-unified-spec number 2
Stephen Nadas <stephen.nadas@ericsson.com> Fri, 02 October 2009 12:17 UTC
Return-Path: <stephen.nadas@ericsson.com>
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 5A0F528C0E3 for <vrrp@core3.amsl.com>; Fri, 2 Oct 2009 05:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 q6ELfXm9AYTi for <vrrp@core3.amsl.com>; Fri, 2 Oct 2009 05:17:29 -0700 (PDT)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id BB05428C0FE for <vrrp@ietf.org>; Fri, 2 Oct 2009 05:17:29 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n92CIsQR008547; Fri, 2 Oct 2009 07:18:54 -0500
Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 07:18:26 -0500
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 07:18:25 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 2 Oct 2009 08:18:25 -0400
From: Stephen Nadas <stephen.nadas@ericsson.com>
To: Jari Arkko <jari.arkko@piuha.net>
Date: Fri, 02 Oct 2009 08:18:24 -0400
Thread-Topic: Please clear draft-ietf-vrrp-unified-spec number 2
Thread-Index: AcpDWnAmFv62voKXQlaEqk5m65iyCg==
Message-ID: <450AE4BEC513614F96969DDA34F3593497639A45@EUSAACMS0701.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_450AE4BEC513614F96969DDA34F3593497639A45EUSAACMS0701eam_"
MIME-Version: 1.0
X-OriginalArrivalTime: 02 Oct 2009 12:18:25.0502 (UTC) FILETIME=[70F9D7E0:01CA435A]
Cc: "Radia.Perlman@Sun.COM" <Radia.Perlman@Sun.COM>, "vrrp@ietf.org" <vrrp@ietf.org>
Subject: [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 12:17:31 -0000
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.
- Re: [VRRP] Please clear draft-ietf-vrrp-unified-s… Jari Arkko
- [VRRP] Please clear draft-ietf-vrrp-unified-spec … Stephen Nadas
- Re: [VRRP] Please clear draft-ietf-vrrp-unified-s… Stephen Nadas