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

David Mandelberg <> Mon, 18 September 2017 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F4CE1321D8 for <>; Mon, 18 Sep 2017 12:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GUEgPFahXkw8 for <>; Mon, 18 Sep 2017 12:29:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E10F132320 for <>; Mon, 18 Sep 2017 12:29:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1505762990; bh=qnzyJBtc6VFTSIHTvWHOW6a7L9Ha2/RZ2CerMDzwkzY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=QS6Ej17ybnswe3lv1ax2Yxf3OWjl3dOYRQDFNA/0GOS4eYgNFtXp9ovTBRm/7FedekPhYSw7oEtf8sSUfg0ArLcHjncKj0DinmvwqsG7QZ7EvicuLbAFqgxrudMD+ZHlYbc1jBsmYhx3RwiCZY4chec/On78yAPEHARMaD4YS1/I0sjqnZa41Nxa7GuKRlBmmLTPPdSTfEwiTiBgOXV8D4LCe4CvoFJMrlNUql+3k+SIpI8XT2ifjoG+udRyYMvaEHcm+706J9ZiSg8LRAkbMyHj7NS3OfpVgXzp1awQXjZtp/ChW147qRbJGdFmh1LQNjck0d9Qek+u//dU0zCzZQ==
Received: from [] by with NNFMP; 18 Sep 2017 19:29:50 -0000
Received: from [] by with NNFMP; 18 Sep 2017 19:29:50 -0000
Received: from [] by with NNFMP; 18 Sep 2017 19:29:49 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: x1NOEQ8VM1nnK1A6S59rBIYHsjGaWhs76lJ_hHJrkq50AXA _pBw.9aLnzGKyL8w77ymyhUK0XwSpJvGghQzJBlGaaXryhTMglvDfo77LRO4 ixOhPlkinvPVy0DiVw33FTU5hr43kFWGhOvMilm9F3TTQ65hbf72Po2Gz8WX CnghzQxZhsw0gOjfBaSUh1gkKYqL1ii9SuWEJlVhhMY.FunqxvN5KMAdQG7p gUNda3rVQRGZ47GOdvu.5MwmOtwk52_GkS3rsfDecpsAQlm4afEUH6NmHf99 11KHtpteGPhuI3pDFtkJmt.yRgU7p8bT2nfARNT5zlSM40jC0YKtikxq9wmj XIM.TtK3TQCr8aB5Ox6quN.amTv4MdSVM54wckNIgPCUsut.zvWwbjXZAC0X K8A0qnRDaImHNkLNhEQjCiPX9YUePDPQ20xvc4NkmiTEOXiaFplkJ5GFINwB rpPD0tvppei.4qWWxqI11DgdxIf2nylMVPWvWVtbYyXUV_Q--
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from [] (DD-WRT []) by (Postfix) with ESMTPSA id D2F011C60A5; Mon, 18 Sep 2017 15:29:48 -0400 (EDT)
Cc: "" <>, "" <>, "" <>
References: <> <3691_1505412243_59BAC493_3691_229_1_53C29892C857584299CBF5D05346208A47872C5B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <> <2597_1505460712_59BB81E8_2597_399_1_53C29892C857584299CBF5D05346208A4787384B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <> <12465_1505725711_59BF8D0F_12465_296_1_53C29892C857584299CBF5D05346208A478787B1@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: David Mandelberg <>
Message-ID: <>
Date: Mon, 18 Sep 2017 15:29:46 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <12465_1505725711_59BF8D0F_12465_296_1_53C29892C857584299CBF5D05346208A478787B1@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-ospf-encapsulation-cap-06
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Sep 2017 19:29:53 -0000

On 09/18/2017 05:08 AM, wrote:
>   > (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?
> No. The following text already prohibits even more than this:
> "  A tunnel MUST NOT be
>        used if there is no route toward the IP address specified in the
>        Endpoint Sub-TLV (See <xref target="EndpointTLV"/>) or if the route is
>        not advertised by the router advertising this Tunnel Sub-TLV."
> - By definition, this Tunnel Sub-TLV is advertised in OSPF i.e. from within the AS.
> - The text also prohibits setting a tunnel endpoint to another router within the AS.
> That being said, within the AS, the point "c" still applies.
> However, thinking twice, the probability is even more limited. Indeed, one can only advertise a tunnel to itself. Assuming that the third party can't control the whole routing topology (i.e. routing advertisement from most core routers), it cannot control the path followed by the tunnel. Hence it would need to have monitoring capabilities on specific links that it cannot choose. (the link on the path to itself).
> Plus this risk is not new, as the third party could already advertise the destination IP address of the packets (or of the BGP Next-hop of the BGP route matching the packet destination), without using any tunnel.
> In conclusion, although I could be wrong, I'm not seeing such new risk. (again, assuming that a third party can modify the OSPF routing is a big assumption).
> But the discussion was useful, thanks for the comments.

That explanation is great, thank you. I hadn't realized the implications 
of the paragraph you quoted, when I initially read it. I'm convinced 
that there isn't a security issue here, but it would be nice to see your 
explanation in the document itself, if it's not already obvious to 
anybody who knows OSPF better than I do.

Freelance cyber security consultant, software developer, and more