[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