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

<> Thu, 14 September 2017 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10FD01326FE; Thu, 14 Sep 2017 11:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QcELCuGxCz9S; Thu, 14 Sep 2017 11:04:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE6F1126BF0; Thu, 14 Sep 2017 11:04:04 -0700 (PDT)
Received: from (unknown [xx.xx.xx.9]) by (ESMTP service) with ESMTP id 8DB61120AC5; Thu, 14 Sep 2017 20:04:03 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by (ESMTP service) with ESMTP id 67CAAC0052; Thu, 14 Sep 2017 20:04:03 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0361.001; Thu, 14 Sep 2017 20:04:03 +0200
From: <>
To: David Mandelberg <>
CC: "" <>, "" <>, "" <>
Thread-Topic: secdir review of draft-ietf-ospf-encapsulation-cap-06
Thread-Index: AQHTHpv/cOgvm+rnt0qxeBuvpFWeWaK0xaZg
Date: Thu, 14 Sep 2017 18:04:02 +0000
Message-ID: <3691_1505412243_59BAC493_3691_229_1_53C29892C857584299CBF5D05346208A47872C5B@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Thu, 14 Sep 2017 18:04:06 -0000

Hi David,

Thanks for your review.

> From: David Mandelberg []
 > Sent: Saturday, August 26, 2017 8:49 PM
 > 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.
 > The summary of the review is Ready with nits.
 > This document extends OSPF for use with tunnels. As mentioned in the
 > security considerations, an attacker who can modify routing information
 > can cause packets to be misdirected or dropped. However, that seems to
 > be the general nature of routing attacks. I don't know if this document
 > makes such attacks any more likely or more severe, but it would be nice
 > to see a bit more discussion of that in the security considerations.
 > E.g., are OSPF attacks without tunneling less severe because of some
 > limitation on where packets can be forwarded, while tunneling makes it
 > easier to forward packets to anywhere on the Internet? Or is that not
 > the case? (I'm not very familiar with OSPF or with the environments it's
 > typically used in.)

OSPF is routing internal to a routing operator. Information received from internal OSPF routers are supposed to be trusted. Personally, I would find unacceptable if an attacker could modify such routing information. I don't think that this extension make it any more likely. In term of severity, I don't think that this is more severe than modifying routing information. e.g. link bandwidth in TE advertisement. Not to mention changing the network topology/graph which currently creates micro-forwarding loops in the network. The only additional consequence that I could think of, is advertising (more) tunneling instructions when the decapsulator is not capable of decapsulating the tunnel at line rate. This would overload its decapsulation processing. This is already identified in the security section of RFC5565 that we are citing. In addition, assuming that the node would not crash because of bugs, that would merely create packet drops, while there is so many ways to create ones if an attacker could modify routing information. Starting with a whole network meltdown.
In short, I don't think that this protocol extension significantly change the OSPF security considerations.



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.