Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Robert Raszuk <[e-mail]>]

Hi Warren,

Thank you for your Discuss. But before we start discussing it perhaps it
would be good to align on what this document really defines as I am sensing
from your description there can be some disconnect (modulo some text may be
indeed misleading in the draft).

You said:

> However, we all know that BGP leaks happen -- and when they do, the SID’s
> contained in the leak will be logged by various systems and hence
available to
> the public into perpetuity.

I think the term BGP is used here a bit too broadly.

Leaks do happen but only within global AFI/SAFIs. This draft defines
extensions for L3VPN and L2VPNs SAFIs which are not used to peer outside of
a domain, collection of domains under same administration +
of course inter-as also could happen.

With that being said I do not see risk that due to leaking there could be a
situation where customer networks are exposed in any way externally -
leaving alone that to even get at the transport level to the customer
facing PE is also filtered and never allowed from outside. But this is out
of scope of this document as here the focus is not on underlay but overlay.

Now when I re-read this I see why there is a little piece perhaps
misleading. The draft makes a claim that it is applicable to RFC8950 which
defines use of NHv6 with both unicast and VPN AFs. That needs to be made
clear that it is applicable to the latter only. If other co-authors believe
this is applicable to the former your DISCUSS section would indeed be
valid.

Many thx,
R.




On Sat, Feb 12, 2022 at 12:05 AM Warren Kumari via Datatracker <
[e-mail]> wrote:

> Warren Kumari has entered the following ballot position for
> draft-ietf-bess-srv6-services-10: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> The Security Considerations section says: "The service flows between PE
> routers
> using SRv6 SIDs advertised via BGP are expected to be limited within the
> trusted SR domain (e.g., within a single AS or between multiple ASes
> within a
> single provider network).  Precaution should be taken to ensure that the
> BGP
> service information (including associated SRv6 SID) advertised via BGP
> sessions
> are limited to peers within this trusted SR domain." This is related to
> (from
> RFC8402): "Therefore, by default, the explicit routing information MUST
> NOT be
> leaked through the boundaries of the administered domain."
>
> However, we all know that BGP leaks happen -- and when they do, the SID’s
> contained in the leak will be logged by various systems and hence
> available to
> the public into perpetuity.
>
> While the document states that border filtering should protect against
> traffic
> injection, this does not cover the case of internal compromise. Sure,
> there is
> the argument that once there is an internally compromised system, all bets
> are
> off -- but with this, an attacker that knows the SIDs in e.g inject traffic
> into a VPN. This seems to me to significantly expand the attack surface to
> include the customer's networks too.
>
> Not only does an operator have to ensure that BGP leaks never occur, they
> have
> to then ensure that at no point can there be any filter lapses at any
> border
> node, and be able to guarantee the security of every device, server and
> machine
> within the domain in order for a secure posture to be maintained. Simply
> saying
> that precautions should be taken to make sure that route leak don't occur,
> when
> the consequences of doing so are a: severe and b: hard to recover from
> seems to
> not really cover it. In addition, it seems that the blast radius from a
> missing
> ACL seems much larger if it allows injections.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm still reviewing the document, but wanted to get an initial ballot in,
> so
> that we could start discussing it. Hopefully someone can help my
> understand how
> this doesn't expand the consequences of a BGP leak.
>
>
>
>