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

<bruno.decraene@orange.com> Thu, 03 November 2011 08:45 UTC

Return-Path: <bruno.decraene@orange.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 63EB61F0C90 for <idr@ietfa.amsl.com>; Thu, 3 Nov 2011 01:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 nvho-rErrNx9 for <idr@ietfa.amsl.com>; Thu, 3 Nov 2011 01:45:08 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBF91F0C70 for <idr@ietf.org>; Thu, 3 Nov 2011 01:45:07 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C1AA38B80B5; Thu, 3 Nov 2011 09:46:27 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id B4DE48B801C; Thu, 3 Nov 2011 09:46:27 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 09:45:04 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 03 Nov 2011 09:45:03 +0100
Message-ID: <FE8F6A65A433A744964C65B6EDFDC24002952074@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A447FB381@EUSAACMS0701.eamcs.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations
Thread-Index: AcyUQUvR0V1Lw/DcSim4lhtSjHsEKAFVyizgABnyD6A=
References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><B17A6910EEDD1F45980687268941550FA20750@MISOUT7MSGUSR9I.ITServices.sbc.com><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21391A447FB381@EUSAACMS0701.eamcs.ericsson.se>
From: bruno.decraene@orange.com
To: jakob.heitz@ericsson.com
X-OriginalArrivalTime: 03 Nov 2011 08:45:04.0924 (UTC) FILETIME=[E20225C0:01CC9A04]
Cc: idr@ietf.org, ju1738@att.com, 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
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 08:45:08 -0000

Jakob,


>From: Jakob Heitz >Sent: Wednesday, November 02, 2011 9:06 PM
>
>On Wednesday, October 26, 2011 5:43 PM, Enke Chen <> wrote:
>
>> Hi, folks:
>>
>> I have a hard time in understanding what new problems (beyond the GR)
>> the draft try to solve :-(
>
>Me too.
>
>The persisting routers will persistently send labeled packets
>into the core. If the intended destination really has disappeared,

If by "really has disappeared", you mean the egress PE (PE2 in Robert's
picture, copied below) is down, then BGP routes whose BGP Next Hop are
PE2 are invalidated (by all ingress PE and also by the persistent RR).
No problem.
If you actually mean that PE2 is alive but has lost its BGP session to
both RR, then this is the case discussed in the security section of the
draft. If you're not happy with it, please be more specific and say why
(because " It diverts the reader's attention with talk of malicious
disturbance." is not helping in addressing your original comment).

            / PE2
 PE1 -- RR
            \ PE3



>and restarted, what is the chance that such labeled packets
>interfere with other unrelated services, just because of labels
>being reused?
>
>Quote from 3.1 of the draft:
>The persist-timer
>      should be set to a large value on the order of days to infinity.
>
>Customers rely on the separation between VPN's. The "P" means private.
>Anything that threatens that "P" should not be taken lightly.
>
>I'm starting to imagine my video stream intrespersed with dzzt, zzt
>from random packets being injected into it. How real is that?
>
>--
>Jakob Heitz.
>_______________________________________________
>Idr mailing list
>Idr@ietf.org
>https://www.ietf.org/mailman/listinfo/idr