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

[<[e-mail]>]

Hi David,

Thanks for your review.

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