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

[David Mandelberg <[e-mail]>]

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.

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

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