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

[David Mandelberg <[e-mail]>]

On 09/18/2017 05:08 AM, [e-mail] wrote:
>   > (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.

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.

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