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

[David Mandelberg <[e-mail]>]

Looks good to me too.

On 09/19/2017 07:01 AM, Acee Lindem (acee) wrote:
> Hi Bruno, Robert,
> 
> Sounds good to me. One nit – replace “e.g. “ with “, e.g., “ in the 
> added text.
> Thanks,
> Acee
> 
> From: Bruno Decraene <[e-mail] 
> <mailto:[e-mail]>>
> Date: Tuesday, September 19, 2017 at 4:15 AM
> To: Robert Raszuk <[e-mail] <mailto:[e-mail]>>
> Cc: The IESG <[e-mail] <mailto:[e-mail]>>, David Mandelberg 
> <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] 
> <mailto:[e-mail]>" 
> <[e-mail] 
> <mailto:[e-mail]>>, 
> "[e-mail] <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>
> Subject: RE: secdir review of draft-ietf-ospf-encapsulation-cap-06
> Resent-From: <[e-mail] <mailto:[e-mail]>>
> Resent-To: Xiaohu Xu <[e-mail] <mailto:[e-mail]>>, 
> Bruno Decraene <[e-mail] 
> <mailto:[e-mail]>>, Robert Raszuk <[e-mail] 
> <mailto:[e-mail]>>, Luis Contreras 
> <[e-mail] 
> <mailto:[e-mail]>>, Luay Jalil 
> <[e-mail] <mailto:[e-mail]>>, Acee Lindem 
> <[e-mail] <mailto:[e-mail]>>, <[e-mail] 
> <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, 
> Deborah Brungard <[e-mail] <mailto:[e-mail]>>, Alia Atlas 
> <[e-mail] <mailto:[e-mail]>>, Acee Lindem 
> <[e-mail] <mailto:[e-mail]>>
> Resent-Date: Tuesday, September 19, 2017 at 4:15 AM
> 
>     *From:*[e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail]] *On Behalf Of *Robert Raszuk
> 
>     Please replace AS with Administrative Domain.
> 
>     [Bruno] I replaced AS with “OSPF domain” as indeed, AS is a BGP term
>     rather than an OSPF one. And as you note, in some cases, the AS and
>     the IGP domain may be different. Thanks.
> 
>     If I have three ASes there should be no artificial limits
>     prohibiting encap to my central collector.
> 
>     [Bruno]
> 
>     If your central collector is part of the OSPF domain of the
>     encapsulator, there is no problem.
> 
>     Otherwise, if the route to your central collector is advertised in
>     OSPF by the decapsulator, there is no problem.
> 
>     Otherwise, if the route to your central collector is advertised in
>     BGP, then draft-ietf-idr-tunnel-encaps is probably the right tool.
> 
>     --Bruno
> 
>     Thx
> 
>     R
> 
>     On Sep 19, 2017 08:18, <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>     > From: David Mandelberg [mailto:[e-mail] <mailto:[e-mail]>]
>       > Sent: Monday, September 18, 2017 9:30 PM
>     >
>       > On 09/18/2017 05:08 AM, [e-mail]
>     <mailto:[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.
> 
>     _________________________________________________________________________________________________________________________
> 
>     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.
> 


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