Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations

Eric Rosen <erosen@cisco.com> Thu, 03 November 2011 16:06 UTC

Return-Path: <erosen@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86661F0C9F for <idr@ietfa.amsl.com>; Thu, 3 Nov 2011 09:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.479
X-Spam-Level:
X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUE1TOtUPqzh for <idr@ietfa.amsl.com>; Thu, 3 Nov 2011 09:06:38 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2651F0C81 for <idr@ietf.org>; Thu, 3 Nov 2011 09:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1477; q=dns/txt; s=iport; t=1320336398; x=1321545998; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=CbZe5nrPQkYCPqIkgBaoP8tspgvHU2QX+8dnLHF6qkM=; b=L7jV6RqxQtyZxPW9lTesvf32TcfCCZh8aDbelcjuUcycE8kqfLG8zK2f 5iYVf2BsHjzAlpDNPkRMU0R0Uo3oTSuDhda45R/ioN5UGntaM1jSorB58 G/kEBPpL3ykgrVRK9xE5oeqMma/ZqFy9s4PoTZMxH9DqmFFvgq0bY24YT Y=;
X-IronPort-AV: E=Sophos;i="4.69,450,1315180800"; d="scan'208";a="12167400"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 03 Nov 2011 16:06:38 +0000
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA3G6bci007768; Thu, 3 Nov 2011 16:06:37 GMT
Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id pA3G6aKB021346; Thu, 3 Nov 2011 12:06:36 -0400
To: Jakob Heitz <jakob.heitz@ericsson.com>
In-reply-to: Your message of Wed, 02 Nov 2011 23:51:19 -0400. <7309FCBCAE981B43ABBE69B31C8D21391A447FB512@EUSAACMS0701.eamcs.ericsson.se>
Date: Thu, 03 Nov 2011 12:06:36 -0400
Message-ID: <21345.1320336396@erosen-linux>
From: Eric Rosen <erosen@cisco.com>
Cc: "idr@ietf.org List" <idr@ietf.org>, "erosen@cisco.com" <erosen@cisco.com>, "UTTARO, JAMES" <ju1738@att.com>, "robert@raszuk.net" <robert@raszuk.net>
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: erosen@cisco.com
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2011 16:06:38 -0000

> I was wondering if stray packets could cause disruptions of other kinds.

If PE2 connects to two sites of VPN1, then after PE2 restarts, proper VPN
service between those two sites can be established without the aid of the
RR.  However, if those sites are now getting stray packets from VPN2 (via
PE1), it does seem possible that these packets will disrupt service in
VPN1.  In such a case, the "persistence" strategy disrupts a service that
would otherwise have been fine.  This may or may not be deemed acceptable by
a SP, but probably should be discussed in the draft.

> as a customer of a VPN service, I would not like the possibility of my
> packets being sprayed into other VPNs.

This is the issue that the Security Considerations attempts to address by
pointing out that there is no way to cause this spraying maliciously, and
hence no way for someone to actually exploit the situation.  The assumption
is that a bit of accidental spraying is not actually going to result in
damages, and is unlikely to even be noticed.

Well, it is unlikely to be noticed unless the customer does a traceroute,
and the ICMP error messages somehow make it back to the customer (via the
Internet, say).  

Whether damages will result may depend on whether someone with poor ethics
just happens to be running a LAN analyzer at an opportune moment, and just
happens to see a packet from the other VPN that just happens to have some
useful information in it.