Re: [secdir] secdir review of draft-ietf-ospf-encapsulation-cap-06

Robert Raszuk <robert@raszuk.net> Fri, 15 September 2017 16:28 UTC

Return-Path: <rraszuk@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 3C96213209C; Fri, 15 Sep 2017 09:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 66oC8-6B93_K; Fri, 15 Sep 2017 09:28:45 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 7A1F3126BF3; Fri, 15 Sep 2017 09:28:45 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id u96so2237197wrb.6; Fri, 15 Sep 2017 09:28:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RpNW4K19YcubgLkFFHAF/RayvD+CXiuTF6s+cvfHuL0=; b=sqr/iyL/3My7Sav/LZIURQulj9sCivzIxpl8oxEWhb/rkmDMpMwHuPbJzOSFPGB5AH YR+28VgXfRP3Ht3aTuw9Z51k6+Yw6oNgFCWUM5oJ+7Jmh1S96Jy6lZDB2f9vfeoSdsh5 +ZcS6XbZkfqK3rC/G4gF8lfmdZimt68NinL1SlBCDKuJzz0OIUwx3KkUhmjaoyHdUGYJ dMW5p4FPTCwr74T11BgmH0mJmuVKHyCxBevxQXB2dV8NgFeDPzqmVpYVkjCoEdKTcoTd Xs2oyEmUhibg5EEywQPwnTVi9Hq+gzHfi4vspHfWTGWcqPm4HyXvwepSfdnxDyJeM9V8 s9bA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RpNW4K19YcubgLkFFHAF/RayvD+CXiuTF6s+cvfHuL0=; b=BI0LJZzaDykqSWLGBLPBrbVR2gw3beaerCTUoMNjRDdRw4zz3dW3VxFMp33OTG2nWy 9L15nnURRdGbvA75cQZ3xgcnb82ccd1GTzvu32E9tMEcQ+E+vohVEKX3BzDtfPTluVc1 lDl4tUSN81arXAnU7Jn4EMaqBNJG89/2CGD9+vssAfNAJh4QlKtMOfXPyOXsgj03S7MR 90f7UjlLuYkwUiFjgnRvAYY53ElTLXEi1WjxP1PZ2KgaIY51WdMIzReuy4XD+o3ss1gE xL/dPkQ/RBJLI3qS4tvKpqS1fxr8l28QsKJax1gAkZzZbZd/9jX/RVz12kVFYWXN5nQ0 SMsQ==
X-Gm-Message-State: AHPjjUjHbbHrlqHNYuERB5vwnuyT7i5AR/pCsYKdM8h0AiBk97uJQWH+ N3UiRt+RzUvAkziPURDs+j+8vg/hKk+Fh6I61fQ=
X-Google-Smtp-Source: ADKCNb60uwgFa2qay730HO6uesz0oURk0S1zTsUW+1b4cMI2I2mRZbbZ/NnGIFCKKmBmDGPyZdc/fGTM1Q5JvsEG+5c=
X-Received: by 10.223.164.206 with SMTP id h14mr21184147wrb.25.1505492923589; Fri, 15 Sep 2017 09:28:43 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.151.75 with HTTP; Fri, 15 Sep 2017 09:28:42 -0700 (PDT)
In-Reply-To: <a922cb18-93f0-94ef-fa9a-59d7565fc836@mandelberg.org>
References: <475c78dc-c872-8795-2d99-81b28df97aed@mandelberg.org> <3691_1505412243_59BAC493_3691_229_1_53C29892C857584299CBF5D05346208A47872C5B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <ae79dc6a-488a-2772-eca4-c325ea462a5f@mandelberg.org> <2597_1505460712_59BB81E8_2597_399_1_53C29892C857584299CBF5D05346208A4787384B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <656e7eb8-1bbe-5f9c-e3b6-f0bbc23737db@mandelberg.org> <CA+b+ERmxR8z1nCfhQwfj9U9jBxuP63XjLMD_kCsySUxoQvGgQg@mail.gmail.com> <a922cb18-93f0-94ef-fa9a-59d7565fc836@mandelberg.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 15 Sep 2017 18:28:42 +0200
X-Google-Sender-Auth: RGDzIsqwIzhlwucCH9pk18kvgS0
Message-ID: <CA+b+ER=OfhDrEbCr2ewn8PVNcgbOJEJPkOYv4bPsw5WpGLZNjg@mail.gmail.com>
To: David Mandelberg <david@mandelberg.org>
Cc: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ospf-encapsulation-cap.all@ietf.org" <draft-ietf-ospf-encapsulation-cap.all@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f16a2ec2d1005593ce2bc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_qE4ahcVIElnu0XuDMDdtypYjP0>
Subject: Re: [secdir] secdir review of draft-ietf-ospf-encapsulation-cap-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 15 Sep 2017 16:28:47 -0000

Hi David,

This draft inherits RFC 5565 security considerations so I was hoping this
would be sufficient. However I have no objection to add extra text directly
to this section 8 to recommend filtering/policy when flooded information is
passed to data plane explicitly listing the allowed range of encapsulation
destinations.

Thx,
R.


On Fri, Sep 15, 2017 at 6:17 PM, David Mandelberg <david@mandelberg.org>
wrote:

> On 09/15/2017 12:02 PM, Robert Raszuk wrote:
>
>> David,
>>
>> But how would an external attacker inject this information into OSPF ?
>>
>
> By (partially) compromising a router, for example. I know an attacker with
> that capability can already do a lot of bad stuff, but it's not clear to me
> whether or not this extension gives them any additional capabilities.
>
>
> Also note that this information is opaque to OSPF itself and it is highly
>> recommended that set of policy rules (protecting from misuse or even
>> accidental mistakes) to be applied on it when reaching the destination code
>> (here encapsulation and forwarding subsystem).
>>
>
> That sounds like a simple and secure way to address my concerns. If the
> document already contains text recommending that local policy be used to
> prevent forwarding outside of the authorized network, then apologies for
> missing/forgetting it. If not, would you mind adding something to the
> security considerations about it?
>
>
>
> --
> Freelance cyber security consultant, software developer, and more
> https://david.mandelberg.org/
>