Re: [RTG-DIR] Rtgdir last call review of draft-ietf-idr-bgpls-srv6-ext-12

[Alvaro Retana <[e-mail]>]

Stewart:

Hi!  Thanks for the review!

The risk of propagating information beyond where it should be is not new to
BGP or BGP-LS. :-(  This fact is mentioned in the Security Considerations
of rfc7752 (BGP-LS).

The review ends by saying that "a more complete review of the security
model is needed before this specification is finalised."  Which security
model are you referring to?  This document is an application of BGP-LS --
is that what you mean?  If so, please take a look at rfc7752bis [1] as any
issues with BGP-LS should be addressed there.

This document contains this text in the Security Considerations:

   BGP-LS SRv6 extensions enable traffic engineering use-cases within
   the Segment Routing domain.  SR operates within a trusted domain
   [RFC8402] and its security considerations also apply to BGP-LS
   sessions when carrying SR information.  The SR traffic engineering
   policies using the SIDs advertised via BGP-LS are expected to be used
   entirely within this trusted SR domain (e.g., between multiple AS or
   IGP domains within a single provider network).  Therefore, precaution
   is necessary to ensure that the link-state information (including
   SRv6 information) advertised via BGP-LS sessions is limited to
   consumers in a secure manner within this trusted SR domain.  BGP
   peering sessions for address-families other than Link-State may be
   set up to routers outside the SR domain.  The isolation of BGP-LS
   peering sessions is RECOMMENDED to ensure that BGP-LS topology
   information (including the newly added SR information) is not
   advertised to an external BGP peering session outside the SR domain.


I believe it complements this text from rfc7752bis:

   Additionally, it may be considered that the export of link-state and
   TE information as described in this document constitutes a risk to
   confidentiality of mission-critical or commercially sensitive
   information about the network.  BGP peerings are not automatic and
   require configuration; thus, it is the responsibility of the network
   operator to ensure that only trusted BGP Speakers are configured to
   receive such information.  Similar security considerations also arise
   on the interface between BGP Speaker and BGP-LS Consumers but their
   discussion is outside the scope of this document.

What else is this document missing?


Thanks!

Alvaro.

[1] https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/

On November 28, 2022 at 2:32:19 AM, Stewart Bryant via Datatracker (
[e-mail]) wrote:

Reviewer: Stewart Bryant
Review result: Has Issues

I apologies for the lateness of this last call review.

The routing technology in this specification seems fine, however I do have
concerns over the network security.

>From the text in the introduction is says: "On similar lines, introducing
the
SRv6 related information in BGP-LS allows consumer applications that
require
topological visibility to also receive the SRv6 SIDs from nodes across an
IGP
domain or even across Autonomous Systems (AS), as required. This allows
applications to leverage the SRv6 capabilities for network programming."

Then in the security section it says "SR operates within a trusted domain
[RFC8402] and its security considerations also apply to BGP-LS sessions
when
carrying SR information."

I am concerned that the exposure of sensitive network information outside
the
network as proposed here represents a significant security risk. I am also
concerned that the increased (practically unconstrained) exposure to the
threat
of hostile actors.

The "trusted domain" concept which is fundamental to SRv6 is fragile at
best.
The scope of the domain and the method of policing are not well described,
and
unlike MPLS which successfully operates that model, SRv6 does not have the
advantage of being able to automatically classify external traffic as being
of
an alien type. With this specification the domain is expanded from the
network
itself to some subset of the applications using the network. It is
difficult to
see how the scope and size of the threat to the network is contained in
this
operational model and I do not see text that help the operator in that
regard.
Applications significantly increase the size of the code base and number of
organizations that can introduce a threat, and by their nature expand the
geographic area of risk in an unconstrained way, perhaps to the full
Internet.

I believe that a more complete review of the security model is needed
before
this specification is finalised.