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

[Robert Raszuk <[e-mail]>]

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, <[e-mail]> wrote:

> > From: David Mandelberg [mailto:[e-mail]]
>  > Sent: Monday, September 18, 2017 9:30 PM
> >
>  > 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.
>
> 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
>
>
>  > --
>  > 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.
>
>