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
- [VRRP] Clear draft-ietf-vrrp-unified-spec 6 Stephen Nadas
- Re: [VRRP] Clear draft-ietf-vrrp-unified-spec 6 Pasi.Eronen