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

<> Fri, 15 September 2017 07:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BF081321A4; Fri, 15 Sep 2017 00:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Status: No, score=-2.618 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OHSl0GKbXESi; Fri, 15 Sep 2017 00:31:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D29D132031; Fri, 15 Sep 2017 00:31:54 -0700 (PDT)
Received: from (unknown [xx.xx.xx.66]) by (ESMTP service) with ESMTP id 75AB740AC9; Fri, 15 Sep 2017 09:31:52 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by (ESMTP service) with ESMTP id 55A00120055; Fri, 15 Sep 2017 09:31:52 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0361.001; Fri, 15 Sep 2017 09:31:52 +0200
From: <>
To: David Mandelberg <>
CC: "" <>, "" <>, "" <>
Thread-Topic: secdir review of draft-ietf-ospf-encapsulation-cap-06
Thread-Index: AQHTHpv/cOgvm+rnt0qxeBuvpFWeWaK0xaZggAAJ/YCAANdoUA==
Date: Fri, 15 Sep 2017 07:31:52 +0000
Message-ID: <2597_1505460712_59BB81E8_2597_399_1_53C29892C857584299CBF5D05346208A4787384B@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <> <3691_1505412243_59BAC493_3691_229_1_53C29892C857584299CBF5D05346208A47872C5B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <>
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: Fri, 15 Sep 2017 07:31:56 -0000

Hi David,

> From: David Mandelberg []
 > On 09/14/2017 02:04 PM, wrote:
 > > 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.
 > Your points are all about how this extension does not affect security
 > considerations around the availability of the network, and I agree.

Yes, I confess that network availability is usually my main concern.

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

 > --
 > Freelance cyber security consultant, software developer, and more


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.