Re: [VRRP] Clear draft-ietf-vrrp-unified-spec 6

<Pasi.Eronen@nokia.com> Fri, 16 October 2009 07:26 UTC

Return-Path: <Pasi.Eronen@nokia.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 D2ABA3A6A40 for <vrrp@core3.amsl.com>; Fri, 16 Oct 2009 00:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Level:
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 0EODQQxHRUd4 for <vrrp@core3.amsl.com>; Fri, 16 Oct 2009 00:26:52 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8F3C13A6A3D for <vrrp@ietf.org>; Fri, 16 Oct 2009 00:26:51 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9G7QgK3023409; Fri, 16 Oct 2009 10:26:44 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 10:26:42 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 10:26:41 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 16 Oct 2009 09:26:40 +0200
From: Pasi.Eronen@nokia.com
To: stephen.nadas@ericsson.com
Date: Fri, 16 Oct 2009 09:26:40 +0200
Thread-Topic: Clear draft-ietf-vrrp-unified-spec 6
Thread-Index: AcpDqsd1gdRQfOG4S5qtU4U8qxPiHgKhyJ/w
Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09A444B7@NOK-EUMSG-01.mgdnok.nokia.com>
References: <450AE4BEC513614F96969DDA34F3593497639DC0@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <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: 16 Oct 2009 07:26:41.0727 (UTC) FILETIME=[01B23CF0:01CA4E32]
X-Nokia-AV: Clean
X-Mailman-Approved-At: Fri, 16 Oct 2009 00:46:21 -0700
Cc: Radia.Perlman@Sun.COM, vrrp@ietf.org
Subject: Re: [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, 16 Oct 2009 07:26:52 -0000

Hi Stephen,

Yes, the proposed text would address the 1st part of my discuss.

Best regards,
Pasi

> -----Original Message-----
> From: ext Stephen Nadas [mailto:stephen.nadas@ericsson.com]
> Sent: 03 October, 2009 00:54
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: adrian.farrel@huawei.com; Radia.Perlman@Sun.COM; Mukesh Gupta;
> vrrp@ietf.org
> Subject: Clear draft-ietf-vrrp-unified-spec 6
> 
> 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