Re: [secdir] Secdir review of draft-ietf-idr-bgp-flowspec-oid-13

Magnus Nyström <magnusn@gmail.com> Mon, 03 May 2021 19:39 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289083A0B8B; Mon, 3 May 2021 12:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=gmail.com
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 HIi_2J0zQdzB; Mon, 3 May 2021 12:38:55 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 15A403A0B88; Mon, 3 May 2021 12:38:54 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id t21so5093375iob.2; Mon, 03 May 2021 12:38:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tTnpSz6trkJg0oZleNS6vrGc9GILDghoJzSpizOT0uo=; b=Yriy7gPH02Rbe8bQQN7Dp9bwcb0d0v4SC76IHR2WMqpf8xz+JaLwpcGxu59VIyMWr0 np0eUbR+LxmGoBnQAJd8pUTDs5aqlQLhaPyQg2NaYS0m27U6+WbtHG7OAWb5Ukf6RJp0 TyCWrjsFJ469c2WGlL/LCT67QOevPvrd9mnBPAw7MKkRm7bmJIk0xaBV0ILA4+54K1NL 4caNDHkA6dyX+eRPUeaLelDCYkMPk+r5LcXdFky9sW37PMFiXuClBHstti6wmlPEniC6 l1DrIs7r1TAkuZmiMF8wlZgw8x4JPHY7ph0jI0VIX75E6pG0yVhB5ip7UwDAwxPIraiQ ApsA==
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=tTnpSz6trkJg0oZleNS6vrGc9GILDghoJzSpizOT0uo=; b=mx6oWzR6levj6Pa5kxA/vhIWe/0E2DWPb4J4vXQhpJkj77t1YgXWksyeQwjsAp040g iFlwutSt+sr5NDCXeey+IRw40mtmbMWYMW9/c28dtjNQhbjLZ8YsLhbe6uZ2yv2cmzj3 13igk5gnW2wnSwt6qux8d6JkYnFAx+lx8vyodaWlT8CJJ0i9poYFxZgOwC7wkMOqurEj yhz6euyMNS0XIahH/DbE0/E1cOHkrVE2xq4JiFcojnA5EtDKDkm0UHk24+UTvar3ThVM YG/kp9XWEY369qcCHLNOki1zyAYRXa88jUqrrUm9YlGxOj4XsvKGqjflopBbZ/UWZAdN hwqg==
X-Gm-Message-State: AOAM530LFt80owdrWHffEYDiIE5ep0Jnq+QtoJ0WF6R7eyTbGvJp9Kle RJnBR230dn3zE2hjkpqFMncEENWckaZ4Ywz/U/PCJ0WUDdI=
X-Google-Smtp-Source: ABdhPJzn42EGVFDsbATXe/kMckW3ZwVKM15xZv8R9TIsj2Ym6Ok93t99U0/Y4yQfmrPRzC02i5Q86lzeI63iTp6ljoI=
X-Received: by 2002:a6b:7f4a:: with SMTP id m10mr16164712ioq.70.1620070733578; Mon, 03 May 2021 12:38:53 -0700 (PDT)
MIME-Version: 1.0
References: <CADajj4ZQnWkjKdWpBgsB0oyX8_Kzj6HOL-Vkm=TrByBQMEJfPw@mail.gmail.com> <CADajj4bCTF5EeF6DZkCHpP0_GTnUYQtqa0OE3qf3Z5_AmKWfyA@mail.gmail.com> <CADajj4YxgdNXkWX7dLP0nBDWXLSKFa8M_KWWCPCgfCibYtWkAw@mail.gmail.com> <CADajj4Yw13QWbSqF_hd+P_fcNA4_YvdwqF=OgJ4pdS_1vrWphA@mail.gmail.com> <CADajj4Zw+Js8neUujMbekReVdMMFcz46NDwdHsMdWXob6Upc_w@mail.gmail.com> <CADajj4aoBaSYTFFnvAjcL7mTnfoUJOWzvve=NRhgB3qe5X8uWQ@mail.gmail.com> <CADajj4ZTBoCHo2=RJhYFNMi+5L5JJwc_EqBkeyYUUfYsVk-vVw@mail.gmail.com> <CADajj4aN=cr-sxjMrmiSxsptwpOZWcH73dWhrtPrruahEQcNJg@mail.gmail.com> <DM6PR11MB3194503DF53A14C12FC749E4CD5B9@DM6PR11MB3194.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB3194503DF53A14C12FC749E4CD5B9@DM6PR11MB3194.namprd11.prod.outlook.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Date: Mon, 3 May 2021 12:38:42 -0700
Message-ID: <CADajj4bSyqcfGU7JoXz73mgGV+N71gkb2O060Kk2672JcE6VGg@mail.gmail.com>
To: "Juan Alcaide (jalcaide)" <jalcaide@cisco.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-idr-bgp-flowspec-oid@ietf.org" <draft-ietf-idr-bgp-flowspec-oid@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000096097a05c1721cf6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/WeerKXG0VtYzgwtlOb7ndyg6Yx8>
Subject: Re: [secdir] Secdir review of draft-ietf-idr-bgp-flowspec-oid-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2021 19:39:00 -0000

Thanks Juan.
For the editorial ones, agree on the first one and I think the second you
could change to "with this memo, becomes optional." or similar.
For the new text, perhaps I am misunderstanding something, but this
sentence:

Note that identifying those peers that are route servers may suppose an
operational challenge. If the condition of the peer is unknown, the rule
SHOULD not be enforced.

Is it correctly understood, that you're saying that if a validator is
unable to determine if the peer is a route server, they should not enforce
the rule? If so, doesn't that mean "failing open, i.e., opening themselves
to risk? Sorry if I misunderstand.



On Mon, May 3, 2021 at 3:36 AM Juan Alcaide (jalcaide) <jalcaide@cisco.com>
wrote:

> Thanks for your comments, Magnus
>
>
>
> Inline..
>
>
>
> *From:* Magnus Nyström <magnusn@gmail.com>
> *Sent:* Monday, May 3, 2021 6:44 AM
> *To:* secdir@ietf.org; draft-ietf-idr-bgp-flowspec-oid@ietf.org
> *Subject:* Secdir review of draft-ietf-idr-bgp-flowspec-oid-13
>
>
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
>
>
> This document describes "a modification to the validation procedure
> defined for the dissemination
>
> of BGP Flow Specifications." More specifically. the memo describes a
> mechanism which relaxes  the existing validation rule that requires Flow
> Specifications to be originating from the originator of the best-match
> unicast route, and now allows such specifications to be originated within
> the same AS as the validator. As a result. the Security Considerations
> section does call out: "The original AS_PATH validation rule ([RFC4271]
> section 6.3 <https://tools.ietf.org/html/rfc4271#section-6.3>) becomes
> hereby optional (section 4.2
> <https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-13#section-4.2>).
> If that original rule is actually not enforced it may introduce some
> security risks. A peer (or a client of a route server peer) in AS X could
> advertise a rogue Flow Specification route...." and "If t[the originator of
> a rule] is known for a fact not to be a route server, that optional rule
> SHOULD be enforced for Flow Specification routes."
>
>
>
> It is not clear to me how a validator would now "for a fact" that a peer
> isn't a route server, and thus that it would have to enforce the
> now-optional path validation rule. It seems some clarity on this would be
> good such that implementations have less of a risk of accepting flow
> specifications from unauthorized parties, even if they are on the same AS.
>
>
>
> [JUAN]: This paragraph was not intended to pressure the operator to know
> if the peer was a route server, it was just a ‘if’. Note it’s the same case
> for RFC4271 :
>
>
>
> If the UPDATE message is received from an external peer, the local
>
>    system MAY check whether the leftmost (with respect to the position
>
>    of octets in the protocol message) AS in the AS_PATH attribute is
>
>    equal to the autonomous system number of the peer that sent the
>
>    message.
>
>
>
>
>
> Note that the same challenge of identifying route servers applies for
> other address-families.
>
> Note also that the route-server itself may enforce the rule.
>
>
>
> What about for clarity:
>
>
>
>    The original AS_PATH validation rule ([RFC4271] section 6.3) remains
> hereby still optional
>
>    (section 4.2) for Flow Specification Address Family (changes introduced
> in [RFC5575] are cancelled).
>
>    If that original rule is not enforced for Flow Specification it may
> introduce some new security risks.
>
>    A peer (or a client of a route server peer) in AS X could advertise a
> rogue Flow
>
>    Specification route whose first AS in AS_PATH was Y (assume Y is the
>
>    first AS in the AS_PATH of the best-match unicast route).  This risk
>
>    is impossible to prevent if the Flow Specification route is received
>
>    from a route server peer.  If that peer is known for a fact not to be
>
>    a route server, that optional rule SHOULD be enforced for Flow
>
>    Specification routes. Note that identifying those peers that are route
> servers may suppose an
>
>    operational challenge. If the condition of the peer is unknown, the
> rule SHOULD not be
>
>    enforced.
>
>
>
>    A route server itself may be in a good position to enforce the AS_PATH
> validation rule described
>
>   in the previous paragraph. If a route server knowns it’s not peering
> with any other route server,
>
>    it can enforce the AS_PATH validation rule across all its peers. If, in
> addition to that,
>
>    the route server is trusted, the security threat described above
> disappears.
>
>
>
>
>
>
>
> Anybody feel free to reword the two paragraphs above if it helps them for
> clarity.
>
>
>
>
>
>
>
> Editorial:
>
>    - "Let's consider the particular case where the Flow Specification is
>    originated in any location within the same autonomous system than the
>    speaker performing the validation (for example by a centralized BGP route
>    controller), and the best-match unicast route is originated in another
>    autonomous system." - should the word "than" be replaced with "that" here?
>
> [JUAN]: Thanks for pointing that out. A few googling tells me the even
> better grammatical choice would be ‘same as’ in this case. I’ll be using
> ‘same as’ unless  you disagree.
>
>
>
>    - In the security considerations section, "becomes hereby optional"
>    could probably be simplified to "becomes optional" or similar, and
>    "actually" could be removed.
>
> [JUAN]:  Hmmm, I thought that it was important to emphasize it becomes
> optional because of **this** draft redefinition of rules. Don’t you think
> it’s important? (whatever wording you want to use). Regardless, refer to my
> new reworded 2 paragraphs above for that section .
>
>
>
>
>
>
>
> Thanks,
>
> -- Magnus
>
>
>


-- 
-- Magnus