IETF Logo Mail Archive

Re: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification

Christoph Loibl <c@tix.at> Wed, 24 August 2016 10:11 UTC

Return-Path: <c@tix.at>
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 EDF9C12D8A0 for <idr@ietfa.amsl.com>; Wed, 24 Aug 2016 03:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvE-R65uSCiD for <idr@ietfa.amsl.com>; Wed, 24 Aug 2016 03:11:51 -0700 (PDT)
Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7047312B034 for <idr@ietf.org>; Wed, 24 Aug 2016 03:11:51 -0700 (PDT)
Received: from [92.60.6.198] (helo=[10.55.3.175]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1bcV2x-0003Ob-U1; Wed, 24 Aug 2016 12:04:36 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9A670E5F-F2AD-469E-81EE-980AA5B9668B"; protocol="application/pgp-signature"; micalg="pgp-sha1"
X-Pgp-Agent: GPGMail 2.6b2
From: Christoph Loibl <c@tix.at>
In-Reply-To: <CA+b+ERk+N6Cgu-wOrHU9JPyAGrqRgfDTGJwb3BaP+yKrKeBm=g@mail.gmail.com>
Date: Wed, 24 Aug 2016 12:11:42 +0200
Message-Id: <E6D0AE02-C678-4420-9E19-AE26E705201E@tix.at>
References: <65345B6C-D24F-4F32-BF3C-E9343A7C61E1@tix.at> <CA+b+ERk+N6Cgu-wOrHU9JPyAGrqRgfDTGJwb3BaP+yKrKeBm=g@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/u-xeb1UpWQbiSHv-Du2DnHWfqOw>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 24 Aug 2016 10:11:54 -0000

Dear Robert and James,

Thank you for your comments and support on our document.

I completely understand that the verification described in the RFC 5575 is has certain limitations. Most current installations (at least that I know of) are intra-AS _only_ and verification is completely disabled in that case. I think that a relaxed / different validation than defined in RFC 5575 makes perfectly sense in many ways.

However, the primary intention of our draft is to clarify aspects that are somehow ambiguous in RFC 5575. We tried to introduce only minimal changes to the RFC (wherever possible) and fill gaps wherever clear definitions were missing to allow a consistent implementation.

Section 5 (revalidation) actually does not really introduce any different behaviour to RFC 5575 it is basically a more verbose rewrite. The reason why we still put into the draft is the following:

During DDoS mitigations it is perfectly feasible that announcements of prefixes change. Traffic steering/engineering may require to isolate traffic via more-specific routes on certain AS-borders, IPv4 routes may simply change during that process. For example: In our lab we saw routers announcing the flow-spec NLRI before announcing the actual IPv4 prefix during such route changes. So the flow-spec verification failed. However, just 10ms later the IPv4 prefix was announced to that particular neighbour (the flow-spec NLRI was still not taken into account, because no revalidation took place). If there is no revalidation of the flow-spec NLRI we end up with a completely unpredictable verification that is based on the arrival time of the two different NLRI announcements (IPv4 vs Flowspec) (some kind of race condition).

We may still decide to have a different verification mechanism in place (as proposed by both of you) but the key here is, that it should always result in a consistent/predictable view over the entire participating networks. In my opinion the time of arrival of announcements should not have any impact on the verification state of the rules.

Cheers,
Christoph

--
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

v2.23.0 | Report a Bug | By Email