Hi Andrew,
When I read Warren's note Iooked at this text from section 2 which says:
- - -
The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix-
SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2
services.
o SRv6 L3 Service TLV: This TLV encodes Service SID information for
SRv6 based L3 services. It corresponds to the equivalent
functionality provided by an MPLS Label when received with a Layer
3 service route as defined in [RFC4364] [RFC4659] [RFC8950]
[RFC9136]. Some SRv6 Endpoint behaviors which MAY be encoded, but
not limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc.
o SRv6 L2 Service TLV: This TLV encodes Service SID information for
SRv6 based L2 services. It corresponds to the equivalent
functionality provided by an MPLS Label1 for Ethernet VPN (EVPN)
Route-Types as defined in [RFC7432]. Some SRv6 Endpoint behaviors
which MAY be encoded, but not limited to, are End.DX2, End.DX2V,
End.DT2U, End.DT2M etc.
When an egress PE is enabled for BGP Services over SRv6 data-plane,
it signals one or more SRv6 Service SIDs enclosed in SRv6 Service
TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs
defined in [RFC4760] [RFC4659] [RFC8950] [RFC7432] [RFC4364]
[RFC9136] where applicable as described in Section 5 and Section 6.
The support for BGP Multicast VPN (MVPN) Services [RFC6513] with SRv6
is outside the scope of this document.
- - -
This limits the overlay signalling to non global SAFIs mainly SAFI 128 and
SAFI 70.
To your note SAFI 4 is private and never exchanged in the wild. Also SAFI 2
is multicast which is out of scope of this draft.
The only thing which we need to sync on is indeed section 5.4 and use of
global IPv6 AFI 2 & SAFI 1
Many thx,
R.
On Sat, Feb 12, 2022 at 7:11 PM Andrew - IETF <andrew-i...@liquid.tech>
wrote:
> Robert,
>
>
>
> I have to say that I have very similar readings on parts of the draft.
>
>
>
> Let’s look at it –
>
>
>
> 5.1 uses the IPv4-VPN NLRI – That would seem to indicate AFI 1 / SAFI 4
>
> 5.2 – Uses AFI 2 / SAFI 4 from my reading
>
> 5.3 – According to RFC8950 – allows advertisement over SAFI 1, 2 or 4
>
> 5.4 – To my reading – very much refers to AFI 2 / SAFI 1.
>
>
>
> I would agree if this document limited itself to 5.1 and 5.2 – it doesn’t
> – and therefore I have to agree with the thoughts expressed in Warrens
> Discuss. If I am wrong about 5.3 and 5.4, let’s chat and help me
> understand this better, and then lets potentially see if we can work up
> some wording that would clarify this if that is what is required.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* iesg <iesg-boun...@ietf.org> *On Behalf Of * Robert Raszuk
> *Sent:* Saturday, February 12, 2022 8:26 PM
> *To:* Warren Kumari <war...@kumari.net>
> *Cc:* Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>;
> draft-ietf-bess-srv6-servi...@ietf.org; bess-cha...@ietf.org; The IESG <
> i...@ietf.org>; BESS <bess@ietf.org>
> *Subject:* Re: Warren Kumari's Discuss on
> draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
>
>
>
> 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 <
> nore...@ietf.org> 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.
>
>
>
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
