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

Robert Raszuk <robert@raszuk.net> Fri, 15 September 2017 16:02 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 3F959132F8F; Fri, 15 Sep 2017 09:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 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_LOW=-0.7, 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 BmLrc1gt0L0B; Fri, 15 Sep 2017 09:02:18 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 B8B7F1321A4; Fri, 15 Sep 2017 09:02:17 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id i189so9539522wmf.1; Fri, 15 Sep 2017 09:02:17 -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=0NhPqzsbJdBST9wLIwdKv2RAPGOgSjatE8yqUqvG19I=; b=GVSrsRsmQflwizrcclgSNA5Ufosq/oM1TA39HA2QsiCWORB/v8YXr3HI80Cgcr+r+y JzpvFAy0YnCJUyhcmEhB6gbaoHGttSQuGJFeJx0tDPr3A4bb1vvKaWbLeIOzba8gG8SL twWpNyiq01gZvZQEjJpMHNOytTNOlVBjKETNNfNSEy3a7JDHOECBB42z61ugyEfco5sf UZMXUhR9sx4woXyy5YaPbs4p0x1JLXn6bDkK5CSE00CmTBXCmKcB3Hb98wY5eSYuS5vA M7JTeyout6wM7Fm/sd4965ppvpd/h+QhHvFiFLQL7Nax64LcWUSDBeENZsuUiYONMdPb /SOA==
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=0NhPqzsbJdBST9wLIwdKv2RAPGOgSjatE8yqUqvG19I=; b=omYU0b8h/0gDb1pY8AqOZGF2HDSX1Cx6Q1sPyYCUI2U+FPoi0KyarAei6aqDCRWWtP WGgP/Vbgf537h/LPAlyx9EgALNAKk4S7+/T0FtnJ2rapbfsZZxDSe4efhEBsuQNeeoef J74ilW9j0CNXXVXHPTxoJltnBIyZUTPZAy3Qt/UtZAy+rUtpz+nTssZSsd6Xn159uUrk /Oh8MfebqZ93K8cK1KEYlDb0bhoyhORfZj1TLMKWiOn2+yWNb8Y+w7cLOLZsu7TNXdN+ y/OXBV3SJHNO8nGHYnx6sUvwKxAk5c3vFzqX669eSc36t0Sai8Nf+PGuXOOkvDAoDNXj oyJQ==
X-Gm-Message-State: AHPjjUiZzhVhdyYFH+Kcug3h3fES8N3HRD7egN7573XtovB5Vz5XmMs5 8eKRpCCW0/eVRQb+b17U1KPP/0aQX1N+E1sQugeN7g==
X-Google-Smtp-Source: AOwi7QBZGCGExrpJOKybikidTWWm8fod7uIpKyys+vGnXEVBzGS9k0OwPbF00mZaPv4jlTsWkwK8uNW6jpJ2EN3Z4Z8=
X-Received: by 10.28.55.209 with SMTP id e200mr3191134wma.72.1505491335773; Fri, 15 Sep 2017 09:02:15 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.151.75 with HTTP; Fri, 15 Sep 2017 09:02:15 -0700 (PDT)
In-Reply-To: <656e7eb8-1bbe-5f9c-e3b6-f0bbc23737db@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>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 15 Sep 2017 18:02:15 +0200
X-Google-Sender-Auth: F_w9r6veEdQy5XIUHxV3qLH-TfI
Message-ID: <CA+b+ERmxR8z1nCfhQwfj9U9jBxuP63XjLMD_kCsySUxoQvGgQg@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="001a114436a848016805593c84a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/BfpiUZ4wLn5cLy0C_vgQca0rOAo>
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:02:20 -0000

David,

But how would an external attacker inject this information into OSPF ?

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).

Thx,
R.

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

> On 09/15/2017 03:31 AM, bruno.decraene@orange.com wrote:
>
>> Hi David,
>>
>> From: David Mandelberg [mailto:david@mandelberg.org]
>>>
>>   > However, what about confidentiality? Does the extension make it easier
>>   > for an attacker to read packets they wouldn't otherwise be able to
>> read?
>>   > (I'm not at all convinced the extension does have a problem there. I
>>   > just think it's plausible enough that it would nice to see an
>>   > explanation of why it's not a problem.)
>>
>> Regarding confidentiality, I can think of 3 things:
>> a) This extension can introduce packet encapsulation. This does not
>> affect whether encapsulated packet was encrypted or whether the transport
>> infrastructure provide encryption (e.g. MACSEC)
>> b) Although this is not currently the case, this extension could be
>> extended to advertise tunnel with encryption capability. In this case, the
>> attacker could change the tunnel properties to remove the encryption
>> c) Specific tunnels could be advertised in order to route packet over a
>> specific link that an attacker is monitoring.
>>
>> Do you think that some of these points would be worse mentioning? If so I
>> could write some text to cover those.
>>
>
> I don't think (a) affects security at all, and I think (b) is probably out
> of scope for this document. For (b), I think the hypothetical document
> describing the encryption capability would have some work to do explaining
> how it's secure, but I don't see any reason to do that work in this
> document.
>
> (c) is the one that I think is worth looking into. E.g., does this new
> extension make it easier for an attacker to route a packet across AS
> boundaries, by setting a tunnel endpoint outside of the OSPF-routed network?
>
>
> --
> Freelance cyber security consultant, software developer, and more
> https://david.mandelberg.org/
>