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

From: <[email-masked]>
Date: Thu, 14 Sep 2017 18:04:02 +0000

Hi David,

Thanks for your review.

> From: David Mandelberg [mailto:[email-masked]]
 > 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.

--Bruno

_________________________________________________________________________________________________________________________

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.

---

From: David Mandelberg <[email-masked]>
Date: Thu, 14 Sep 2017 16:22:31 -0400

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

-- 
Freelance cyber security consultant, software developer, and more
https://david.mandelberg.org/

---

From: <[email-masked]>
Date: Fri, 15 Sep 2017 07:31:52 +0000

Hi David,

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

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

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

Thanks,
--Bruno

---

From: David Mandelberg <[email-masked]>
Date: Fri, 15 Sep 2017 11:56:29 -0400

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 15 Sep 2017 18:02:15 +0200

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 <[email-masked]>
wrote:

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

---

From: David Mandelberg <[email-masked]>
Date: Fri, 15 Sep 2017 12:17:34 -0400

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 15 Sep 2017 18:28:42 +0200

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 <[email-masked]>
wrote:

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

---

From: David Mandelberg <[email-masked]>
Date: Fri, 15 Sep 2017 12:36:20 -0400

Thanks!

On 09/15/2017 12:28 PM, Robert Raszuk wrote:
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     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?
> 
> 
> 
>     --

---

From: <[email-masked]>
Date: Mon, 18 Sep 2017 09:08:30 +0000

Hi David,

 > Sent: Friday, September 15, 2017 5:56 PM
> 
 > > 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

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

--Bruno

---

From: David Mandelberg <[email-masked]>
Date: Mon, 18 Sep 2017 15:29:46 -0400

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

---

From: <[email-masked]>
Date: Tue, 19 Sep 2017 07:18:42 +0000

> Sent: Monday, September 18, 2017 9:30 PM
> 
 > > 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).
 > >

I've just added the following text in the security section of my local version:
"We note that the last paragraph of <xref target="Operation"/> forbid the establishment of a tunnel toward arbitrary destinations. It prohibits a destination outside of the Autonomous System and also to other routers within the AS. This avoid that a third-party gaining access to an OSPF router be able to send the traffic to other destinations, for e.g. inspection purposes. "

Feel free to comment/propose other text.

Since I've just published -08 a few hours ago, I'll probably delay the upload of this new update.

--Bruno

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Sep 2017 09:51:46 +0200

Please replace AS with Administrative Domain.

If I have three ASes there should be no artificial limits prohibiting encap
to my central collector.

Thx
R

On Sep 19, 2017 08:18, <[email-masked]> wrote:

> "We note that the last paragraph of <xref target="Operation"/> forbid the
> establishment of a tunnel toward arbitrary destinations. It prohibits a
> destination outside of the Autonomous System and also to other routers
> within the AS. This avoid that a third-party gaining access to an OSPF
> router be able to send the traffic to other destinations, for e.g.
> inspection purposes. "
>
> ____________________________________________________________
> _____________________________________________________________
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Tue, 19 Sep 2017 08:15:08 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk

Please replace AS with Administrative Domain.
[Bruno] I replaced AS with “OSPF domain” as indeed, AS is a BGP term rather than an OSPF one. And as you note, in some cases, the AS and the IGP domain may be different. Thanks.

If I have three ASes there should be no artificial limits prohibiting encap to my central collector.
[Bruno]
If your central collector is part of the OSPF domain of the encapsulator, there is no problem.
Otherwise, if the route to your central collector is advertised in OSPF by the decapsulator, there is no problem.
Otherwise, if the route to your central collector is advertised in BGP, then draft-ietf-idr-tunnel-encaps is probably the right tool.

--Bruno

Thx
R

On Sep 19, 2017 08:18, <[email-masked]<mailto:[email-masked]>> wrote:
> From: David Mandelberg [mailto:[email-masked]<mailto:[email-masked]>]
 > On 09/18/2017 05:08 AM, [email-masked]<mailto:[email-masked]> wrote:

--Bruno

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 19 Sep 2017 11:01:43 +0000

Hi Bruno, Robert,

Sounds good to me. One nit – replace “e.g. “ with “, e.g., “ in the added text.
Thanks,
Acee

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 19, 2017 at 4:15 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>, David Mandelberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: secdir review of draft-ietf-ospf-encapsulation-cap-06
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Xiaohu Xu <[email-masked]<mailto:[email-masked]>>, Bruno Decraene <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Luis Contreras <[email-masked]<mailto:[email-masked]>>, Luay Jalil <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Deborah Brungard <[email-masked]<mailto:[email-masked]>>, Alia Atlas <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>
Resent-Date: Tuesday, September 19, 2017 at 4:15 AM

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk

--Bruno

Thx
R

--Bruno

---

From: David Mandelberg <[email-masked]>
Date: Tue, 19 Sep 2017 12:24:17 -0400

Looks good to me too.

On 09/19/2017 07:01 AM, Acee Lindem (acee) wrote:
> To: Robert Raszuk <[email-masked] <mailto:[email-masked]>>
> Cc: The IESG <[email-masked] <mailto:[email-masked]>>, David Mandelberg 
> <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] 
> <mailto:[email-masked]>" 
> <[email-masked] 
> <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> Resent-From: <[email-masked] <mailto:[email-masked]>>
> Resent-To: Xiaohu Xu <[email-masked] <mailto:[email-masked]>>, 
> Bruno Decraene <[email-masked] 
> <mailto:[email-masked]>>, Robert Raszuk <[email-masked] 
> <mailto:[email-masked]>>, Luis Contreras 
> <[email-masked] 
> <mailto:[email-masked]>>, Luay Jalil 
> <[email-masked] <mailto:[email-masked]>>, Acee Lindem 
> <[email-masked] <mailto:[email-masked]>>, <[email-masked] 
> <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, 
> Deborah Brungard <[email-masked] <mailto:[email-masked]>>, Alia Atlas 
> <[email-masked] <mailto:[email-masked]>>, Acee Lindem 
> <[email-masked] <mailto:[email-masked]>>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> 
>     [Bruno] I replaced AS with “OSPF domain” as indeed, AS is a BGP term
>     rather than an OSPF one. And as you note, in some cases, the AS and
>     the IGP domain may be different. Thanks.
> 
>     If I have three ASes there should be no artificial limits
>     prohibiting encap to my central collector.
> 
>     [Bruno]
> 
>     Otherwise, if the route to your central collector is advertised in
>     OSPF by the decapsulator, there is no problem.
> 
>     Otherwise, if the route to your central collector is advertised in
>     BGP, then draft-ietf-idr-tunnel-encaps is probably the right tool.
> 
>     --Bruno
> 
>     Thx
> 
>     R
> 
>     On Sep 19, 2017 08:18, <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     > From: David Mandelberg [mailto:[email-masked] <mailto:[email-masked]>]
>       > On 09/18/2017 05:08 AM, [email-masked]
>     <mailto:[email-masked]> wrote:
>     "We note that the last paragraph of <xref target="Operation"/>
>     forbid the establishment of a tunnel toward arbitrary destinations.
>     It prohibits a destination outside of the Autonomous System and also
>     to other routers within the AS. This avoid that a third-party
>     gaining access to an OSPF router be able to send the traffic to
>     other destinations, for e.g. inspection purposes. "
> 
>     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,
>     This message and its attachments may contain confidential or
>     privileged information that may be protected by law;
>     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.
>