Re: [Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period

Robert Raszuk <robert@raszuk.net> Thu, 13 June 2019 18:26 UTC

Return-Path: <robert@raszuk.net>
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 E8281120464 for <idr@ietfa.amsl.com>; Thu, 13 Jun 2019 11:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 faeoTfRMhhkz for <idr@ietfa.amsl.com>; Thu, 13 Jun 2019 11:26:38 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F221203AA for <idr@ietf.org>; Thu, 13 Jun 2019 11:26:38 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id s22so13400549qkj.12 for <idr@ietf.org>; Thu, 13 Jun 2019 11:26:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BbUTsb88G4b0n31MjoyrBYBaewyhE1G1wXcWcKmq+U4=; b=Hd2/rL9tbq8hVWFOhpVaQcgKpDKc0PCwLSFGNvtJQqOd9DDNdWLcUQfljxlWn9gTxF emcDLweaNSCusUHCae0lMO4MSU6KteAHnsgQoudZH4C45ydupLpvxmMU99rmqYNPAbxx FU3vcU/+JrAJKSTarmwUcHKXAR6TTuEXhtn888+vGWf/CY71MQGolQBBW1D6K7WlAtti a6ckdAQu/8k86osXTA0MxJT2qMQehZAkyvKGWk9ZfJNh7CGvA5Qy30a76qajD1ceM28c yxQ7ejuV5mWTlGWgV6QGcHT7cNawUQBzu37eESnsM6VJE1zepoT6tGfX+jK3wIpCA3vV JsOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BbUTsb88G4b0n31MjoyrBYBaewyhE1G1wXcWcKmq+U4=; b=n7Vlwvu/OZOkWzclR91CTMIrnscpGtLHpa7aeHkuosH3za8/VnbeMlj8dv10yptcAa 3pKj5GcYlJrPZiQn2JauKeoA3da8cUTo7NcHmkXa3zoK2KK2U4FhVDzJD7ebQKpCZ+Sa +/Cwke4UYvs+JghpzaLoR+TtXRpTOCK1zIf4qnoT8/k2J5umtaRz2Ca3Ew9EcYvSCHjx KzxfWXIqJQ+NTi8vNfgNI0G6ZTj90Ww7QY62nSjeoTnFtYeNJRz416x/iqGlNPgvv9Un Rpz86E3B/avSsZQkIXhuLHJa6wOjOnvrI82mIf4vCrYCaNFnyBHvN33eDb+G00oz6SHW u/Fw==
X-Gm-Message-State: APjAAAXP/IxHpr/u5+rDWpfyh/8V7TYq2nyrwKgozC5wzPSUSL49l/NB 93yBYyEImwSwFgbET3N3qdWvKn6pUky194ZYEuzcGg==
X-Google-Smtp-Source: APXvYqwiWwVFE1PDpCbn3uB5xB66f5svL0OZbpo9VwsteOerWOraZxccBBYLDXgJ4Y2BrfjndxoOS5ztwqk22bChPRU=
X-Received: by 2002:a05:620a:1206:: with SMTP id u6mr71131899qkj.88.1560450397619; Thu, 13 Jun 2019 11:26:37 -0700 (PDT)
MIME-Version: 1.0
References: <A68BF050-9846-4E14-918D-297548E078A2@juniper.net>
In-Reply-To: <A68BF050-9846-4E14-918D-297548E078A2@juniper.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 13 Jun 2019 20:26:28 +0200
Message-ID: <CAOj+MMGNuseO3ppFVugLhwKQs0LT-o_t1da2SGUQWAe=MkXzoA@mail.gmail.com>
To: John Scudder <jgs@juniper.net>
Cc: "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-rfc5575bis@ietf.org" <draft-ietf-idr-rfc5575bis@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a3d951058b38abc7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/GufRQPDdtbxTJetnZtVxQuWEFF4>
Subject: Re: [Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 13 Jun 2019 18:26:47 -0000

Hi John,

RFC5575 has been written as DDoS mitigation tool and 5575bis attempts to
clarify various ambiguities of the base spec.

We as the WG have decided that numerous 5575 extensions (for example those
injected by controllers or NMS) will be specified in different documents
and not be embedded into base Flow Specification one.

With that if we agree that DDoS mitigation is still our target for the base
spec I would tent to suggest that destination field to be made mandatory
for real DDoS mitigation use case. Relaxing that could be done for other
Flow Spec use cases in their separate documents, but outside of the base
spec.

So the only change which may be needed would be add:

4.2.  NLRI Value Encoding

   The Flow Specification NLRI-type consists of several optional
   subcomponents (except Type 1 which is mandatory).

Thx,
R.







On Thu, Jun 13, 2019 at 7:42 PM John Scudder <jgs@juniper.net> wrote:

> Hi Authors and WG,
>
> I just had it brought to my attention that RFC 5575 and
> draft-ietf-idr-rfc5575bis both are underspecified with regard to the
> validation procedures. The problem is what to do if a flow-spec NLRI
> doesn't contain a destination prefix component. Section 4.2 makes it clear
> that destination prefix is optional, so it's valid for it not to be
> present. But the first set of validation steps in section 6 are written in
> terms of the destination prefix, without acknowledging it might not be
> there.
>
> This leaves a gap for an interoperability problem, where some
> implementations might choose to consider validation to have succeeded if
> the destination prefix component isn't present, and others might consider
> it to have failed.
>
> To fix this ambiguity I'd like to suggest the following change. The
> summary is we add a new rule (a), renumber the old (a) and (b), and add a
> note following.
>
> OLD:
>    A Flow Specification NLRI must be validated such that it is
>    considered feasible if and only if:
>
>       a) The originator of the Flow Specification matches the originator
>       of the best-match unicast route for the destination prefix
>       embedded in the Flow Specification.
>
>       b) There are no more specific unicast routes, when compared with
>       the flow destination prefix, that has been received from a
>       different neighboring AS than the best-match unicast route, which
>       has been determined in step a).
>
> NEW:
>    A Flow Specification NLRI must be validated such that it is
>    considered feasible if and only if:
>
>       a) A destination prefix component is embedded in the Flow
>       Specification.
>
>       b) The originator of the Flow Specification matches the originator
>       of the best-match unicast route for the destination prefix
>       embedded in the Flow Specification.
>
>       c) There are no more specific unicast routes, when compared with
>       the flow destination prefix, that has been received from a
>       different neighboring AS than the best-match unicast route, which
>       has been determined in step b).
>
>    Rule a) MAY be relaxed by configuration, permitting Flow
>    Specifications that include no destination prefix component. If such
>    is the case, rules b) and c) are moot and MUST be disregarded.
>
> We need the MAY clause since 4.2 does say destination prefix is optional,
> and also because an operator might actually want to permit this under some
> circumstances, particularly if the route is internally sourced. I'll also
> point out that another way according to the proposed rule set to have a
> flow-spec that matches every packet is to actually put /0 in the
> destination prefix, then you don't need the optional configuration
> mentioned in the MAY clause (you do need to accept default for validation
> to succeed, but that's inherent in flow-spec's design).
>
> The draft has already passed WGLC and been sent to the IESG. But given
> that it's always easier to correct problems sooner rather than later, I've
> just pulled it back to the WG. I'm hoping we can have quick consensus on
> what to do --
>
> - Adopt the fix I've suggested,
> - Adopt a different fix,
> - Determine that no fix is needed.
>
> We could also let the IESG resolve this but it doesn't seem like good WG
> hygiene.
>
> I'd like to keep the discussion tightly scoped to just the minimum
> necessary to clarify section 6.
>
> Let's have the traditional two week window for discussion, to end by June
> 28.
>
> Thanks,
>
> --John