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

[<[e-mail]>]

Hi David,

> From: David Mandelberg [mailto:[e-mail]]
 > Sent: Friday, September 15, 2017 5:56 PM
> 
 > On 09/15/2017 03:31 AM, [e-mail] wrote:
 > > Hi David,
 > >
 > >> From: David Mandelberg [mailto:[e-mail]]
 > >   > 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.

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

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

_________________________________________________________________________________________________________________________

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.