[VRRP] Clear draft-ietf-vrrp-unified-spec 6
Stephen Nadas <stephen.nadas@ericsson.com> Fri, 02 October 2009 21:52 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 5D6083A67EF for <vrrp@core3.amsl.com>; Fri, 2 Oct 2009 14:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 lwMtwwVSjLgP for <vrrp@core3.amsl.com>; Fri, 2 Oct 2009 14:52:09 -0700 (PDT)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 75F6D3A67E7 for <vrrp@ietf.org>; Fri, 2 Oct 2009 14:52:09 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n92LrWRU004165; Fri, 2 Oct 2009 16:53:35 -0500
Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 16:53:32 -0500
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 16:53:32 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 2 Oct 2009 17:53:32 -0400
From: Stephen Nadas <stephen.nadas@ericsson.com>
To: "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com>
Date: Fri, 02 Oct 2009 17:53:30 -0400
Thread-Topic: Clear draft-ietf-vrrp-unified-spec 6
Thread-Index: AcpDqsd1gdRQfOG4S5qtU4U8qxPiHg==
Message-ID: <450AE4BEC513614F96969DDA34F3593497639DC0@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 02 Oct 2009 21:53:32.0668 (UTC) FILETIME=[C8D983C0:01CA43AA]
Cc: "Radia.Perlman@Sun.COM" <Radia.Perlman@Sun.COM>, "vrrp@ietf.org" <vrrp@ietf.org>
Subject: [VRRP] Clear draft-ietf-vrrp-unified-spec 6
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 21:52:10 -0000
Hi Pasi, With respect to your 1st part of discuss (2nd part still in process): The security considerations text basically says security doesn't have to be considered here because an attacker can cause havoc with ARP anyway. I don't think this is fully accurate description. Many networks with untrusted hosts use switch security features that prevent hosts from bringing down the network with spoofed ARP packets (somewhat similar to what SAVI WG is working on). While compromising one of the switches or routers would still cause damage, compromised or malicious ordinary hosts (attached to switch ports where these features are enabled) can't do that much. The other reason for removing cryptographic authentication of VRRP messages is said to be misconfigured secrets (which obviously does cause problems -- but on the other hand, this situation should be detected very quickly). If it's indeed the case that cryptographic per-message authentication isn't a good solution to securing VRRP, at the very least the document should discuss other possible mechanisms. Perhaps e.g. filtering mechanisms in switches, configured on per-port basis, could provide some protection? Or could this somehow leverage the existing mechanisms for ARP? Does the below text capture your concerns? If not could you please suggest changes that would? VRRP for IPvX does not currently include any type of authentication. Earlier versions of the VRRP (for IPv4) specification included several types of authentication ranging from none to strong. Operational experience and further analysis determined that these did not provide sufficient security to overcome the vulnerability of misconfigured secrets causing multiple masters to be elected. Due to the nature of the VRRP protocol, even if VRRP messages are cryptographically protected, it does not prevent hostile nodes from behaving as if they are a VRRP master, creating multiple masters. Authentication of VRRP messages could have prevented a hostile node from causing all properly functioning routers from going into backup state. However, having multiple masters can cause as much disruption as no routers, which authentication cannot prevent. Also, even if a hostile nodes could not disrupt VRRP, it can disrupt ARP and create the same effect as having all routers go into backup. Some L2 switches provide the capability to filter out, e.g., ARP and/or ND messages from end hosts on a switch port basis. This mechanism could also filter VRRP messages from switch ports associated with end hosts and can be considered for deployments with untrusted hosts. Thanks, Steve
- [VRRP] Clear draft-ietf-vrrp-unified-spec 6 Stephen Nadas
- Re: [VRRP] Clear draft-ietf-vrrp-unified-spec 6 Pasi.Eronen