Hi all,
+1 for Robert.
Yes, especially when MPLS in GRE or MPLS in UDP is deployed, packets
carrying MPLS labels can traverse all IP-reachable networks and reach
remote PEs.
BR,
Shunwan
*From:*Robert Raszuk [mailto:[email protected]]
*Sent:* Thursday, February 17, 2022 11:28 PM
*To:* Warren Kumari <[email protected]>
*Cc:* Ketan Talaulikar <[email protected]>; Andrew - IETF
<[email protected]>; Bocci, Matthew (Nokia - GB)
<[email protected]>; [email protected];
[email protected]; The IESG <[email protected]>; BESS <[email protected]>
*Subject:* Re: Warren Kumari's Discuss on
draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
Hi Warren,
I am very sorry but I see folks are completely mixing transport layer
and service layer.
In RFC4364 you can use MPLS label for service demux and IP transport to
get to remote egress PE via any IP network including Internet.
There is nothing in L3VPNs like enabling MPLS on interface as mandatory
prerequisite. Yes many folks are confused about this and I see the same
confusion here. The service plane is completely separate from transport
layer from day one.
Kind regards,
Robert
On Thu, Feb 17, 2022 at 4:14 PM Warren Kumari <[email protected]
<mailto:[email protected]>> wrote:
On Sun, Feb 13, 2022 at 11:54 PM Ketan Talaulikar
<[email protected] <mailto:[email protected]>> wrote:
Hi Warren/All,
This draft specifies broadly two types of BGP Services over SRv6:
A) VPN Services (L3VPN & EVPN) - Sec 5.1, 5.2 & 6
B) Global Internet Services - Sec 5.3, 5.4
As explained by my co-author Robert, the operations and
mechanisms for VPN services are similar to what we've had with
MPLS. I believe we are all on the same page on this one based on
the discussions between Andrew and Robert and that there is no
new concern as far as (A).
Actually, no, I don't think that we are -- if I, as an attacker,
somehow know that VPN x uses MPLS labels Y, that's interesting, but
not particularly valuable -- because of the "fail closed" nature of
MPLS (it's a different protocol, and needs explicit and intentional
action to enable on an interface) it's really hard for me to
"inject" an MPLS packet and route it into your network. With SRv6,
if the SIDs leak, I can construct a normal v6 packet and route it
towards you. Yes, handwave handwave the RFCs say that you MUST
filter at your edges and that the filtering MUST always be perfect
handwave limited domain handwave -- but it's putting a large amount
of faith in operator perfection.
Also, if I, as an attacker get access to a "server" in the provider
network (noc workstation, billing machine, random admin PC, etc),
with MPLS it's very unlikely to be part of the MPLS domain, but an
SRv6 domain is much more likely to be "squishy" and more likely to
encompass parts of the "enterprise" type systems.
W
Now (B) does bring in filtering aspects (as mentioned in the
security considerations) to ensure that the SRv6 block that is
meant for use internal to the operator's network (i.e. SR
domain) does not get leaked/advertised out from the default
table on the Internet Border Router (IBR) over to an eBGP peer.
This is similar to the precautions that operators take today to
prevent their infrastructure addresses from being leaked to the
Internet. The filters in BGP are also accompanied by ACLs at the
IBRs to prevent traffic destined for those infrastructure IPs
from entering into the operator network. This is the same in the
case of SRv6 as well.
I hope that clarifies and we can update the text to convey these
aspects better.
Thanks,
Ketan
On Sun, Feb 13, 2022 at 12:21 AM Andrew - IETF
<[email protected] <mailto:[email protected]>> wrote:
Hi Robert,
5.3 Also opens the door to SAFI 1 – since you can v6 over v4
using AFI 1 / SAFI 1 using what is defined in RFC8950, in
fact, it is explicit.
Section 5.3 is titled Global IPv4 over SRv6 core – this
correlates with the example in section 6.1 of RFC8950 –
which states:
The extensions defined in this document may be used as
discussed in
[RFC5565
<https://datatracker.ietf.org/doc/html/rfc5565>] for the
interconnection of IPv4 islands over an IPv6
backbone. In this application, Address Family Border
Routers (AFBRs;
as defined in [RFC4925
<https://datatracker.ietf.org/doc/html/rfc4925>]) advertise
IPv4 NLRI in the MP_REACH_NLRI
along with an IPv6 next hop.
The MP_REACH_NLRI is encoded with:
* AFI = 1
* SAFI = 1
* Length of Next Hop Address field = 16 (or 32)
* Next Hop Address = IPv6 address of the next hop
* NLRI = IPv4 routes
During BGP Capability Advertisement, the PE routers
would include the
following fields in the Capabilities Optional Parameter:
* Capability Code set to "Extended Next Hop Encoding"
* Capability Value containing <NLRI AFI=1, NLRI SAFI=1,
Nexthop
AFI=2>
As I say, if you were to remove the references to global and
5.3/5.4 which explicitly reference it and bring SAFI 1 into
play – there would be far less concern from my side, I can’t
speak for anyone else, but that would be my feeling
Thanks
Andrew
*From:*Robert Raszuk <[email protected]
<mailto:[email protected]>>
*Sent:* Saturday, February 12, 2022 9:37 PM
*To:* Andrew - IETF <[email protected]
<mailto:[email protected]>>
*Cc:* Warren Kumari <[email protected]
<mailto:[email protected]>>; Bocci, Matthew (Nokia - GB)
<[email protected] <mailto:[email protected]>>;
[email protected]
<mailto:[email protected]>;
[email protected] <mailto:[email protected]>; The IESG
<[email protected] <mailto:[email protected]>>; BESS <[email protected]
<mailto:[email protected]>>
*Subject:* Re: Warren Kumari's Discuss on
draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
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
<[email protected] <mailto:[email protected]>>
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 <[email protected]
<mailto:[email protected]>> *On Behalf Of *Robert Raszuk
*Sent:* Saturday, February 12, 2022 8:26 PM
*To:* Warren Kumari <[email protected]
<mailto:[email protected]>>
*Cc:* Bocci, Matthew (Nokia - GB)
<[email protected]
<mailto:[email protected]>>;
[email protected]
<mailto:[email protected]>;
[email protected] <mailto:[email protected]>; The
IESG <[email protected] <mailto:[email protected]>>; BESS
<[email protected] <mailto:[email protected]>>
*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 <[email protected] <mailto:[email protected]>>
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/
<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/
<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.
--
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
-- E. W. Dijkstra
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
