[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [VRRP] DISCUSS: draft-ietf-vrrp-unified-spec
Hi Pasi,
Thank you for the feedback. Putting to VRRP list for WG feedback.
Regards,
Steve
> -----Original Message-----
> From: Pasi Eronen [mailto:pasi.eronen at nokia.com]
> Sent: Thursday, November 06, 2008 11:41
> To: iesg at ietf.org
> Cc: vrrp-chairs at tools.ietf.org;
> draft-ietf-vrrp-unified-spec at tools.ietf.org
> Subject: DISCUSS: draft-ietf-vrrp-unified-spec
>
> Discuss:
> I have reviewed draft-ietf-vrrp-unified-spec-02. Overall, the
> document looks good, but I have the following concerns that
> I'd like to discuss before recommending approval of the document:
>
> 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 aFrom vrrp-bounces at ietf.org Thu Nov 6 08:55:50 2008
Return-Path: <vrrp-bounces at ietf.org>
X-Original-To: vrrp-archive at megatron.ietf.org
Delivered-To: ietfarch-vrrp-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 6D8A13A6A69;
Thu, 6 Nov 2008 08:55:50 -0800 (PST)
X-Original-To: vrrp at core3.amsl.com
Delivered-To: vrrp at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 2CEBC3A69A1;
Thu, 6 Nov 2008 08:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047,
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 gFxwFCVYpXSN; Thu, 6 Nov 2008 08:55:48 -0800 (PST)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9])
by core3.amsl.com (Postfix) with ESMTP id 4FF533A6905;
Thu, 6 Nov 2008 08:55:48 -0800 (PST)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se
[138.85.77.51])
by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id mA6GvMIN010211;
Thu, 6 Nov 2008 10:57:26 -0600
Received: from eusrcmw720.eamcs.ericsson.se ([138.85.77.20]) by
eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Thu, 6 Nov 2008 10:55:25 -0600
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 6 Nov 2008 10:55:23 -0600
Message-ID: <DF78BDF6956FDD4780D5DAD88A073CF45672B0 at eusrcmw720.eamcs.ericsson.se>
In-Reply-To: <20081106164059.3D0183A6869 at core3.amsl.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: DISCUSS: draft-ietf-vrrp-unified-spec
Thread-Index: AclALoiUl8WO7j9RTIWwxPi2wdNJxAAAc/9w
References: <20081106164059.3D0183A6869 at core3.amsl.com>
From: "Stephen Nadas" <stephen.nadas at ericsson.com>
To: "Pasi Eronen" <pasi.eronen at nokia.com>, <iesg at ietf.org>
X-OriginalArrivalTime: 06 Nov 2008 16:55:25.0759 (UTC)
FILETIME=[771A4CF0:01C94030]
Cc: vrrp-chairs at tools.ietf.org, draft-ietf-vrrp-unified-spec at tools.ietf.org,
vrrp at ietf.org
Subject: Re: [VRRP] DISCUSS: draft-ietf-vrrp-unified-spec
X-BeenThere: vrrp at 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 at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/vrrp>
List-Post: <mailto:vrrp at ietf.org>
List-Help: <mailto:vrrp-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>,
<mailto:vrrp-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: vrrp-bounces at ietf.org
Errors-To: vrrp-bounces at ietf.org
Hi Pasi,
Thank you for the feedback. Putting to VRRP list for WG feedback.
Regards,
Steve
> -----Original Message-----
> From: Pasi Eronen [mailto:pasi.eronen at nokia.com]
> Sent: Thursday, November 06, 2008 11:41
> To: iesg at ietf.org
> Cc: vrrp-chairs at tools.ietf.org;
> draft-ietf-vrrp-unified-spec at tools.ietf.org
> Subject: DISCUSS: draft-ietf-vrrp-unified-spec
>
> Discuss:
> I have reviewed draft-ietf-vrrp-unified-spec-02. Overall, the
> document looks good, but I have the following concerns that
> I'd like to discuss before recommending approval of the document:
>
> 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 enablre 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?
>
>
> An additional question about Section 7.4: I'm slightly
> confused by the text here -- does every router create its own
> link-local address (in which case failover is visible to
> hosts in this subnet), or do they share the same link-local
> address? The 1st paragraph says "They MUST NOT use the
> Virtual Router MAC address to create the Modified EUI-64
> identifiers", but the 3rd paragraph talks about "using the
> VRRP MAC in the formation of these link local addresses" --
> are these contradicting each other, or am I just
> misunderstanding how this works?
>
>
>
_______________________________________________
vrrp mailing list
vrrp at ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
ed) 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?
>
>
> An additional question about Section 7.4: I'm slightly
> confused by the text here -- does every router create its own
> link-local address (in which case failover is visible to
> hosts in this subnet), or do they share the same link-local
> address? The 1st paragraph says "They MUST NOT use the
> Virtual Router MAC address to create the Modified EUI-64
> identifiers", but the 3rd paragraph talks about "using the
> VRRP MAC in the formation of these link local addresses" --
> are these contradicting each other, or am I just
> misunderstanding how this works?
>
>
>
_______________________________________________
vrrp mailing list
vrrp at ietf.org
https://www.ietf.org/mailman/listinfo/vrrp